There will always be bugs, defects, and unexpected issues with usability in the real world as you release a new increment after each sprint. In my post on 3and 17 Oct 2020, I talked about Is handling urgent change requests being a problem for you? and Modifying sprint backlog during the planned sprint. This time I will talk about how to protect the Scrum team from external disruptors during the sprint.
Problem description
One of the most important responsibilities of the ScrumMaster is protecting the Scrum team by shielding it from external disruptors. On the other hand, the Product Owner is responsible about what would conflict with the sprint, or what might have to wait until the next sprint.
In the past, in addition to software development, developers were also responsible for responding to production requests. Although today companies have concluded that it is better to have a separate support team to support the product, in the actual work environment, there are cases where the support team is unable to respond to the situation and the Developers must take action.
In general, two types of issues occur in production:
1-Deterministic
These sort of production requests are a bug in the code, and they need a code fix. Prioritizing the elimination of such bugs in terms of importance, impact on other parts of the product, and its goals is one of the Product Owner responsibilities.
2-Non-Deterministic
These are usually incidents that have nothing to do with product code, for instance, network timeout issue.
Depending on the urgency of support requests, they may even put the team’s commitment to risk. When part of the team must handle urgencies, some situations may put in danger the sprint goal, which will lead the Product Owner to cancel the sprint. But is there any other way of handling urgent production requests?
Solution
The solution to the problem lies in the core nature of the Developers. One of the Developers’ most important characterises is self-management, which I talked about in my last post.
Scrum Guide insists that the product owner must decide on support requests, then check If the issue, or even a defect, is not completely necessary for the customer to deliver value, it can be better done by adding it to the Product Backlog and asking the Developers to fix it in a later Sprint as a user story.
However, there is no doubt about the PO responsibility, and the Developers can also mitigate interruption. One of the strategies I have personally experienced success is introducing a member of the Developers each sprint as primary contact with the support team. I will call this person Support Angel (You can choose any other name you want). This is one of the beauties of self-management of developers in the Scrum.
Support Angel manages support requests, shielding the rest of the team from disruptions, and would involve others on the Developers if needed. In each sprint, it is necessary to rotate support angel so that the same members handling support requests are not necessarily the same. This increases developers’ awareness of the product based on the support requests. Besides, by this strategy, the Scrum team has this chance to Control problems related to production support and monitor their effect on the team’s productivity.
To get the best result from this solution, developers should add to the Sprint backlog a support angel capacity (for example 40%) support task for each Sprint. Depending on team size, prioritisation, and planned commitment of the support tasks, the support angel capacity’s size should be decided. However, this strategy will potentially lead to incorrect velocity numbers for the Developers, If the entire support angel capacity buffer is not used during the sprint.
On the other hand, although this approach enables developers to proceed and eliminate external disruptors during the sprint, it does not affect the Product Owner responsibility on the Product backlog.
Over the years, I have found that Scrum needs some justification for each organization. In tough situations, following this approach will help you see more clearly and transition from a reactive mode to a more proactive one.
Please share your thoughts in the comments below, and how do you handle external disruptors during the sprint?
Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
This post is also available in Medium; please click here.
Leave A Comment