Interruptions are a part of life, even on good Agile teams. You’ve made plans, now they have to change. Again. So, until the sources of interruptions can be plugged indefinitely (which will take some time and work), the team needs a way to handle interruptions while also delivering predictability against the backlog of new features. The goal is maintain predictability in a rapidly changing work environment where interruptions are planned for and can therefore be addressed in a timely manner.
Here are four simple ways to handle interruptions that can actually make a team more resilient to change (with hand-drawn visuals by yours truly).
Pattern 1: Roll With It
We know support and fix requests come in sporadically. Such work comes in every month or two so a special policy for handling it is not needed.
Plan as if there will not be support and fix work. When some comes in, adjust the plan to accommodate it. Drop one or two planned pieces of work to handle the speed bump of fix work, so you can limit your work in progress (WIP) and focus on getting work done. Tell stakeholders immediately what is happening and why. Remind them that, to accommodate this unplanned-for work, you had to remove lesser-priority stories from the Sprint.
Since the interruptions are not that often, we don’t have to change our work process. We simply have to be transparent about the effects of interruptions when they do happen.
Pattern 2: Budget Capacity
The team regularly has support, fix or other interruptive work. It’s expected but the team doesn’t know enough to make a specific plan.
Make an assessment, maybe just a feel or guess based on shared history of how much time is spent each week on such work. Calculate the percent of time spent on such work. Budget that percent of Story Point Velocity (or just hours) for such work. New work is planned for the remaining capacity.
We have a time set aside for the unknown work we know is coming. That way the new work plans can be executed. And, if no interruptions happen, we can do even more than planned!
Pattern 3: Firefighters
The team consistently has “non-new” work to do. Every Sprint or week, without fail, there are enhancements, fixes or service requests that are going to come in.
One or two people on the team each Sprint (or couple of weeks) are designated as “firefighters.” They do not do new work unless there are no interruption requests. The current plan for the next couple of weeks takes into account that these two people are NOT working on new stuff. The firefighter positions rotate every two weeks so the same two people are not stuck doing the fix and support work all the time.
The plan can be met by the people working on the new stories. The firefighters are dedicated to handling interruptions and get to learn new areas of the product. And if there are no interruptions, the firefighters can help get more new work done than planned!
Pattern 4: Special Teams
Some gnarly problems come in from time to time. These are often so big, so unknown that they are a project all on its own that can threaten to steal everyone away from new work.
Find a spot in your plan where you can stop to re-plan. Finish out the week or two weeks and then re-plan. Peel off a few people who are experts in the problem area and know the technology well. These few people form a Special Team who are 100% dedicated to the big problem. The rest of the team can make plans without them, proceeding with new work.
The current plan for a week or two is not overly disrupted. Then the problem will have the full focus of dedicated people. New work proceeds at a slower pace until the Special Team members come back, but at least it proceeds.