Interruptions in Scrum

You are the Scrum Master of a team that is doing scrum. Things have been going fairly well. This time of year is tricky for your business. Its when all your customers need to go through audits and thus they require a lot of support from your team. Its crucial to the business that these customers are supported but the knock on effect is that not much committed sprint work is being done. The team is feeling frustrated that they have to drop work to focus on support the whole time. They are also feeling pressured to meet their commitment and do all the support work.

Well the good news is that many (if not all) teams have faced this problem at some point. It’s the nature of the software game. Perhaps it’s a big release mid year, perhaps it’s the looming Y2K fixes ☺.

As a coach I like to focus on the inspect & adapt cycle, and help my teams use that to improve their situations. The first thing I would suggest is to change nothing. Rather lets make sure we are not making assumptions because of frustrations.

First talk to the team.

Let the team know that for this sprint you are going to focus on what the interruptions are and how long they take. In the retrospective the team will analyze the interruptions and we will see how we can minimize their impact on the team.

Then make every interruption visible.
I ask the team to note every interruption on a bright pink sticky note on their task board. (Any color that will stand out from all others on their board will work). They need to put their name and the approximate duration of the interruption on the sticky as well.

Reminders in standup.
Add a question to your daily standup to remind people about interruptions. Anything that takes more than 15 minutes should go up on the task board.

Inspect & Adapt.
During your retrospective analyze all the interruption stickies. Group them. Some might be related to bugs, some to data conversion, some to a legacy product… Know do a root cause analysis technique on these groupings.

This is crucial. If you simply apply a band-aid to the problem it will come back time and time again. You really need to get to some root causes and then select an action. Yes, just 1. As the scrum master you might take some other actions and escalate them higher up or to other departments, but the team should just take 1 action that is within their control.

Be open to new ideas but also don’t make radical changes too quickly. Sometimes the answer is to reduce your sprint length, or to not use scrum!

The next sprint.
The action from your retrospective should be taken into your next sprint and be the highest priority for the team. It is important that you continue to monitor interruptions for this sprint and the next few, to see if your action is making a difference.

In most teams I’ve noticed the interruptions stickies drastically reduce in the 2nd sprint, mostly because individuals change their behavior. They become more aware of interruptions and start to deal with them differently. Most teams start to adopt practices that will improve the situation for the next time this ‘overload’ of interruptions is expected.

Teams can continue to use this technique daily and should the number of pink stickies look like they are growing they can use that as an indicator to inspect and adapt.

Here are some other techniques for dealing with interruptions:

• http://agilitrix.com/2010/05/no-interruptions-in-scrum-is-an-anti-pattern/
• http://www.agileadvice.com/tag/interruptions/
• http://www.scrumcrazy.com/How+should+I+handle+production+support+on+a+Scrum+Team%3F