Interruptions are something that every team has to deal with and, if not managed appropriately, they can potentially have a detrimental affect on their ability to deliver. In a recent post on the Agile Advice blog, Mishkin Berteig described seven options that teams could consider to deal with interruptions when using Scrum or iterative Agile approaches.
- Follow Scrum Strictly
- Allocate a Portion of Time to Interruptions
- Visible Negotiation of Change
- Separate Team for Interruptions
- Extremely Short Cycles
- Status Quo / Suffering
- Commitment Velocity
In the Scrum Guide, Ken Schwaber and Jeff Sutherland clearly state that to be successful teams need to follow Scrum strictly.
Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
Therefore, Mishkin states this as an opening option for teams that are practicing Scrum.
The Scrum approach is based on the basic philosophy that Scrum is a system to expose the problems and obstacles in the organization... Fix the behavior that causes so many interruptions, don’t find a way to accommodate interruptions.
However, many Agile teams practice a hybrid approach and the article gives guidance that teams can use a percentage of time or team of resources to deal with interruptions.
...There are two ways to allocate this time: everyone on the team gives a certain amount of time each day to handling interruptions OR one or two people on the team are committed full-time for a cycle to handling interruptions... Generally, the best use of this extra time is to work on resolving the root causes of interruptions.
Another option Mishkin outlines in the article is visibly negotiating the change, with something he refers to as the "“fluorescent note card” method.
...any time a stakeholder comes to the team with an interruption request,...write the request on a bright colored note card so that it is easy to distinguish it from the other tasks the team is working on in their current cycle. The requesting stakeholder then has to negotiate with any other stakeholders... about what work to remove from the iteration in order to make room for the new work.
This option is very similar to the XP approach to dealing with interruptions, as James Shore and Shane Warden outline in The Art of Agile Development: Iteration Planning.
In other words, if you're adding a two-point story to the plan, a two-point story needs to come out of the plan. In addition, you may only replace stories that you haven't started yet.
The most comprehensive option according to Mishkin is the commitment velocity measurement, which he explains as the "minimum historical slope" of a team burndown. His explanation is that the team should continue to drop its expected velocity every iteration to meet the actual number of points they achieved in the last iteration (rather than an average).
...as the team uses this tool of Commitment Velocity for more and more Sprints, eventually their ability to keep their commitments, even with interruptions, will become closer and closer to 100% certain.
Other alternatives include extremely short cycles, which is covered comprehensively in this presentation on InfoQ from the Agile 2008 conference, and, although not recommended by the author, suffering with the status quo.
...it is important that if you choose to continue with your status quo, that you make the trade-off transparent. Tell everyone on your teams exactly why you are making the trade-off and what is the expected benefit of doing so.
Approaches for handling interruptions is something that the Agile community has been talking about for a number of years and InfoQ has a number of articles from 2008 and earlier that detail some further options and alternatives such as Interruption Driven Development, Responding to Urgent Requests and Handling Interruptions on an Agile Project.
The effect of interruptions on a team is perhaps most appropriately summed up by Mark Levison in his recent Scrum Master Tales series.
People outside of the development group don’t appreciate the cost of interrupting the team. In particular they don’t understand the costs of context switching (allow 20-30 minutes to recover if working on a complex task).
Does your team use one of these approaches for handling interruptions, or do you find other techniques such as Kanban more effective?
