All posts by mikecivic2003

About mikecivic2003

I am a Blogger

Is it possible for Support and Maintenance to Become Agile?

Uncategorized

Agile methodology has gone from being a manifesto to an industry standard. Most of the product majors are adopting it, which promises to resolve multiple grievances that Waterfall is supposed to have created. The short, time-bound sprints with predefined goals and the overall style that Agile purports have even caught the fancy of project implementation. Hence many software-implementing organizations are engaging with their customers using project plans based on the Agile methodology.

The methodology has a unique impact on project planning and execution right from the requirement-gathering process. This article presents the impacts and challenges of the new norm, specifically for software product organizations with products that have been on the market for more than a decade (and hence are mature) and are market leaders in their domains.

A typical product life cycle goes from requirement gathering (from customer, market, or the competition) to development, quality assurance, release, and support. As a product matures, new features and enhancements are ìdeltaî enhancements. However, at the same time, a large section of engineering is dedicated to supporting and resolving customer issues. A whole machinery of customer support, project management, engineering, and release management is dedicated to support existing customers during implementation, post-implementation support, and upgrades.

For such mature organizations, Waterfall methodology was the way of life for all new enhancements. Bug or patch fixing was driven purely based on customer escalations and the patch-fix cycle.

However, with Agile becoming the norm, not only development teams but support teams are adopting its practices. I have had the opportunity to be aligned with support functions, in the capacity of product owner, in two different companies who are market leaders in enterprise applications and network management, respectively.

The “new normal” is bringing multiple changes to these support teams. As would be the case in most support teams, they’re used to fixing bugs based on inflow, capacity, and escalated customer priority or severity. Though customer issue severity still has to remain the driving force for the bug-fixing process, adopting Agile methods brings multiple new facets to this process.

Some of the key changes and challenges that I have observed during Agile adoption for these teams include:

  • Sprint backlog. Creating and signing up to a sprint backlog was completely a new dimension for the support and maintenance teams. Basically, it required the teams to review all the bugs/issues (which now made up the product backlog) and work with the product owners to scrub and story-point these so that the Scrum team could plan which bugs (stories) they would target in ongoing and future sprints. The team, which in the past expected the manager or team lead to assign the bugs, was now expected to review, measure, and story-point the bugs, and then sign up to fixing them within a stipulated sprint period.
  • Volatility of support. Support and maintenance teams don’t work on a ìwish listî but have a ìburningî issue backlog. This made sprint planning, and sticking to the plan, a challenge in itself, because an escalated customer issue was always threatening to disrupt the sprint and hog the Scrum teamís time and resources.
  • Scrum team dynamics. Aligning engineering, quality assurance groups, customer service (first level of support) teams, and product owners in single teams was a logistics and availability challenge, especially when the ratio of QA and product ownersí resources was skewed (which it usually is).
  • Managing customer expectations. Most customer support services have SLAs (service level agreements), which govern a TAT (turnaround time) for response and resolution. The first response requires analysis and engagement of first-level support and engineering support teams. With the sprint backlog becoming the working ìlistî for the engineering support teams, the first-level teams had to revisit their approach to meeting customer SLAs.
  • Release and build process. The PMO (project management office) also was required to align to the new process and enable the support teams to check in codes and verify them within the sprint. This mandated governance to discipline what is almost a daily build process is at the other end of the spectrum from the Waterfall method, where the builds are created only at the end of the development cycle.

What I observed was that, as the teams aligned to these changes, they did appreciate the benefits of going Agile. The key benefits included:

  • Scrubbing the defects. Sprint planning required the team to commit to the plan for the sprint. The support development team scrubbed the backlog, reviewed it, assigned story points to it, and signed up for achieving resolution within the sprint. This entailed that the ScrumMaster, along with his or her team, reviewed the entire set of bugs and fixes that the product owner had created. Unlike taking bugs as they come or as the team fixes them, this approach enabled the team to review the bugs together in a structured way and assign story points based on their complexity.
  • Time-bound sprints. As mandated by Agile, a sprint should be time-bound and not last beyond three to four weeks. In support/maintenance teams, this is a new concept, since it requires bugs to be fixed and verified by QA team members within the sprint, and for bugs and fixes to be closed in that sprint period lest they spill over and thus lower the velocity shown in the burn-down chart. The time-bound activity brought a sense of urgency and goal-setting that otherwise has been difficult to implement in the support scenario.
  • QA and development team collaboration. In the typical Waterfall method, the development folks complete the coding and hand over the build for QA activities. Agile make this process more like a small squirt than a waterfall. It requires the development team to get the code QA-verified within the sprint, thereby enabling healthy team dynamics.
  • Visibility. The Agile process entails that management is involved in team activities. The participation of senior management in the sprint planning and sprint retrospective meetings enabled the support teams to achieve more visibility on management radar, which otherwise rarely happens unless escalations reach the top echelons. In my experience, Agile enables the ScrumMaster to project the teamís achievements in more structured and time-bound way, bringing management’s attention and focus to the support teams’ successes.

To conclude, Agile might not be a direct fit with the customer-support process, but it is indeed a powerful methodology that can enable managers to improve team morale, productivity, and process to achieve enhanced customer satisfaction and employee commitment.

Blackberry Priv have release a November beta update to beta testers AAH505

Uncategorized

Today’s update brings news that AAH505, our candidate to be the official November security patch update, is now available to beta participants on all devices (except Verizon variants) to begin testing. Depending on the build you’re coming from, this will either be a relatively small patch download or a very large full download. If you don’t see the update available, open up the phone dialer and punch in *#*#CHECKIN#*#*then check for updates again.

If you’re a Priv owner and taking part in the beta program, you should be seeing it arrive. Click and check your update if you haven’t see it.