As a consultant, one of the top questions I get from my clients is: “How do we deal with Production Support issues in Agile when our Scrum Team supports both the product and its development?” There are a few ways to handle these issues. I’m not advocating that one method is better than another; I’m just providing a list of options to consider:
Make sure you have a Triage and Severity System
Before you go any further, create a process to triage reported bugs or defects. Rate each issue by its severity. Here are some general definitions you can use as a starting point:
Critical – impacts ability to operate; business essentially ceases
High – the issue impacts many customers and prevents them from doing all their work
Medium – fewer people are impacted, and there is a manual workaround
Low – usually trivial problems that are cosmetic
Most organizations can’t tolerate critical bugs in production for long – it usually means their business is offline and no longer operating. In a situation like this, it is a 9-1-1 problem requiring immediate attention. When these things crop up, all other work should stop and every effort deployed to solve the problem.
Pass off product support issues to a Support Team
If your organization is lucky enough to have an independent production Support Team, you could pass off any support issues to that group.
The advantage of doing this is that you would no longer have interruptions to your planned Sprint work.
The disadvantage is that the support team is probably not as familiar with the product as the Scrum Team, and the resolution of issues will take longer. Also, the support team may be unable to fix the problem, which will escalate to your team anyway.
Leave contingent capacity available during each Sprint
If there’s no option but for your Scrum Team to support any production problems, then another option is to leave a percentage of capacity open to deal with these issues during each Sprint.
When you do Sprint Planning, ensure you don’t fill up the team’s capacity. You should reserve enough time to deal with most typical production issues. You can use historical data to predict what amount of time to commit.
Rotate team members as the designed support person
No one likes to be the one who has to deal with all the problems. In the interest of fairness, it may be best to “share the love” with the team by designating one person per Sprint, whose job is to deal with any production issues.
By rotating through the team members, each will develop more problem-solving skills, and no one person will always get stuck doing the “grunt work.”
For non-critical bugs, add them to the Product Backlog
If your customers find defects in production that aren’t vital to the organization’s operations (meaning they are not “critical” or “high” in severity), then add them to the Product Backlog.
By capturing bugs in the Product Backlog, the Product Owner can evaluate them for inclusion in future iterations. Most of the time, these things can wait and may (or may not) be taken care of later.
Swarm on Production Problems
When production support issues occur, it usually means “all hands on deck” to fix the problem; the team works collaboratively to analyze and resolve the issue as quickly as possible.
Swarming means that all resources tackle the highest-priority problem immediately, and all other work ceases until the defect is corrected and deployed to your customers.
Usually, when such issues occur, there is a negative consequence in that the team may not complete all originally planned Sprint work. Fortunately, given that stakeholders are aware of what happened, they are usually very understanding and forgiving when this happens.
Final Thoughts
This blog covered several ways Scrum Teams can address production support problems. These things are often unpredictable, but when they happen, they can severely impact your customers, reputation, and ability to operate. Any one or more of these possible solutions may work for you. Experiment until you find the best solution for your organization.
Now, over to you! Have you had to deal with production support issues with your Scrum Team? Did they employ any of the above ideas, or did they handle things differently? If so, I am curious to know how, so please share your solutions with me in the comments below!