In an ideal world, a Scrum team should be dedicated and exposed as little as possible to external disturbances. But in most cases, teams must focus on developing new software and support earlier versions of the software application in production. In fact, support requests can disrupt the sprint. Depending on the urgency of these requests, they may even jeopardize the team’s commitment. When part of the team must handle urgencies, some situations may require to reduce the scope of the commitment or even to stop the sprint. But is there any other way?
For many teams, it is frustrating to never be able to achieve their commitment for the sprint because of support requests. Why commit when the team is sure to be disturbed? Commitment is meaningless and the team is committed to do its best rather than deliver results. How can we make the unpredictable predictable?
Here are a few strategies that will allow you to see more clearly and to better manage these types of situations:
1) As a PO, be firm about what can disturb the sprint or what will have to wait until the next sprint. Manage clients’ expectations.
2) As a team member, keep your good habits when support requests are processed. It’s not because there is an urgent problem in production that you need to skip steps contained in the Definition of Done, not thoroughly testing and then correcting directly in production. On the contrary, it is in urgent and stressful situations that the risk of error increases. The Scrum Master is responsible for ensuring that the team id cool headed and sticks to the routine of rigor and quality established sprint after sprint.
3) Allocate a bank of time for urgencies during the sprint (e.g. 20%). Follow the time used for these urgencies over the sprints to see if the time allocated is sufficient. Adapt the bank accordingly. But if the support continues to hold too high a percentage for you, other more important strategies should be considered.
4) Dedicate one or more members of the team for application support. These members protect the rest of the team from disturbances by handling support requests, and their support-related tasks are not accounted for in the commitment of the team. If during a sprint, the number of support requests is lower than expected, the involvement of these members in the team’s commitment or in the development of new features is considered a bonus. It is possible to be rotating roles so that it is not always the same members handling support requests.
5) Create a support team separate from the development team. If the effort justifies it, a dedicated team responsible for application support could be created. Since applications are not predictable, another Agile approach like Kanban or Agile Lean could be used. For the development team, the Scrum approach is still the most appropriate and will now be more effective as the team will be less disturbed. Similarly, rotation of the development and support team after a few sprints could help diversify the experience while limiting the impact on velocity.
Nevertheless, it remains that devoting too much effort to manage support is very expensive and could be avoided by: preventing and resolving this problem at the source by an early emphasis on the quality of the solution, technical excellence, and simplicity in design, while maintaining a sustainable pace and avoiding accumulation of the technical debt.
In a nutshell, implementing some of these strategies can help you see more clearly in difficult situations and help you move from a reactive mode to a more proactive one.
Of course, the strategies mentioned above don’t apply to all contexts and they may need to be adapted to your reality as well as to the size and expertise of your teams.
In your context, what strategies are you using?
No Comment