Agile & Production Support..

In one of my current consulting assignments, I was popped up with the question on introduction of Agile for production Support teams... This got me thinking, we might be successful in creating a sprint backlog for the team, but what if there is a priority defect and it just needs a fix, It's a clear showstopper for complete system.

Agile, is to deal with project complexities, like volatility, estimation, prioritization. How do we track and prioritize these support activities? How do we handle emergencies? Who performs production support?

Some key challenges that I could envisage are:

Sprint backlog: Creating and signing up to a sprint backlog requires the teams to review all the bugs/issues and work with the product owners to vegetate and plan 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.

Unpredictability: Support and maintenance teams don't work on a backlog necessarily. This made sprint planning, and sticking to the plan, a challenge in itself, because an escalated customer issue is always threatening to the sprint and take over the Scrum team time and resources.

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 being worked by the support teams, the scope of having waste was always high. Since teams had to meet SLA, something had to be dropped off from backlog.

Release and build process: With severity 1 production tickets, build or release process has to be broken to accommodate hot fix.

It is little tricky, but by adding extra degree of complexity I am sure agile will be able to handle it.

Scrubbing the production issues: 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.

Smaller Sprints: Shorter the sprint, the smaller the potential impact of any above mentioned situation.

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 enable the support teams to achieve more visibility on management radar, which otherwise rarely happens unless escalations reach the top.

This approach not only gives us the greater probability of doing things right but also shows the team is up for the difficult decisions during its expedition towards agile way of working.

Agile, is to deal with project complexities, like volatility, estimation, prioritization. How do we track and prioritize these support activities? How do we handle emergencies? Who performs production support?

Some key challenges that I could envisage are:

Sprint backlog: Creating and signing up to a sprint backlog requires the teams to review all the bugs/issues and work with the product owners to vegetate and plan 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.

Unpredictability: Support and maintenance teams don't work on a backlog necessarily. This made sprint planning, and sticking to the plan, a challenge in itself, because an escalated customer issue is always threatening to the sprint and take over the Scrum team time and resources.

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 being worked by the support teams, the scope of having waste was always high. Since teams had to meet SLA, something had to be dropped off from backlog.

Release and build process: With severity 1 production tickets, build or release process has to be broken to accommodate hot fix.

It is little tricky, but by adding extra degree of complexity I am sure agile will be able to handle it.

Scrubbing the production issues: 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.

Smaller Sprints: Shorter the sprint, the smaller the potential impact of any above mentioned situation.

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 enable the support teams to achieve more visibility on management radar, which otherwise rarely happens unless escalations reach the top.

This approach not only gives us the greater probability of doing things right but also shows the team is up for the difficult decisions during its expedition towards agile way of working.