Support Angel for handling external disruptors during the sprint

In the real world, there will always be bugs, defects, and unexpected issues with usability as you release a new increment after each sprint. In my post on 3 and 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 the company’s 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 most important characterises of the Developers is self-management which I talked about it 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, 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 a primary point of contact with the support team, which 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 is managing 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 and 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 productivity of the team.

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 size of the support angel capacity should be decided. However, this strategy will potentially lead to some 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 of each organization. In tough situations, following this approach will help you see more clearly and help you 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?