Organization of Production Support

I can’t recall any company we’ve worked with that has been 100% satisfied with how it organizes production support. Companies try some or all of these patterns:

• The people who built a system provide all production support.

• A separate team provides all production support.

• A separate team provides first- and second-level support; the engineering organization supports third-level issues.

The last approach is most common, and it is approached in multiple ways. One way is that third-level support is provided by a separate support team (which is more technical than the first- and second-level support team). That team’s primary responsibility is production support. Another way that third-level support is provided is by staff who originally built the system, even though they have mostly transitioned to working on other systems.

Within development teams that are handling escalated support issues as a secondary responsibility (that is, they are supporting systems they worked on previously), support is organized in a variety of ways:

• Escalated support issues are allocated to each team member on a round-robin basis as they arrive.

• Escalated support issues are all handled by one team member; that responsibility rotates daily or weekly.

• Escalated support issues are assigned to the team member most qualified to resolve the issue.

Most companies try several of these patterns over time and conclude that none is completely free of problems. The goal is to find the dog with the fewest fleas rather than hoping to find a perfect solution.

Production support on Scrum teams

In terms of production support issues that are specific to Agile development, the challenge is handling support issues without disrupting Scrum’s sprints. Teams need to anticipate and plan for the time they will spend on escalated support issues. Here are some guidelines:

• Plan support time into sprints. If production support takes 20% of a team’s ongoing effort, sprint planning should assume only 80% time is available for sprint-related work.

• Set a policy for the kind of work that is allowed to interrupt a sprint. Differentiate between regular work that can go into the product backlog for a future sprint vs. issues that are both urgent enough and important enough to intrude on the sprint. A specific definition is most useful, such as “Priority 1, Severity 1, SLA-related defects are allowed to take precedence over the sprint goal.”

• Use retrospectives to refine production support planning. Velocity-based sprint planning and sprint retrospectives can help a team measure the amount of time that should be allowed for this work each sprint. As the team reviews challenges it encountered in meeting its sprint goal, it should review the amount of time allocated for production support vs. the amount of time actually spent and make future plans accordingly.

• Allow the production support structure to vary from team to team. Different teams will have different numbers of issues escalated to them, the new work they’re doing will vary in priority and urgency, and team members will have different levels of experience and ability to handle support issues with prior systems. All these factors suggest that different teams will best handle support issues in different ways.