Navigating Agile Sprints in an Ocean Full of Interruptions

As they say, "....history will repeat itself". In this case, they're right!

We speak with teams all the time who have difficulty maintaining proper course with their software development Sprints.

Unplanned interruptions

The most common complaint? Unplanned interruptions. The impact? Your velocity, of course!

Do any of these sound familiar?:

"I was in the middle of my Sprint and the operations team needed my help troubleshooting a production issue."

"I couldn't finish those two tasks because I had to push an emergency patch into production."

"I'm way behind with this Sprint because we've had 3 required product planning meetings this week."

These are just a few examples of what we hear whenever we ask a customer:

"Why was there an interruption in your Sprint?"

This isn't the opera folks. People aren't going to excuse themselves for interrupting. Life happens, business happens, and the show must go on. Unplanned interruptions will undoubtedly take place within every Sprint. It's not a matter of "if", it really boils down to "how often" and "how long" each Sprint? This is "Business As Usual" (BAU) and make no mistake, if you are not planning for these events, you will continue to experience soured Sprints.

When working with our customers, one of the first thing I ask is for them to provide me with the hours of interruption for the last 2-3 Sprints. I've yet to meet a customer who has this information formally logged. They usually have a good guess, but no specific data they can point to or provide me with which I can use to assess the factual impact. Why is that important? Well, because it WILL happen again. If we record the time spent on BAU events each Sprint, we then have the ability to see trends and calculate averages. Most importantly, we can protect our future Sprints by factoring in the interruptions.

What I really mean is this. To properly plan our Sprints in environments where we can't insulate ourselves from these events, we must reduce our overall commitment by the average hours spent on BAU events. After instituting measurements, I've worked with teams where 45% of their total team effort is spent supporting BAU. Yet these teams continue to plan without these factored in, and therefore they continually set incorrect expectations and fail their Sprints.

What's the best way to record?

At Appfire, we're fortunate because all of our customers leverage Atlassian products, so it's quite easy for us to introduce mechanisms to help them capture and record information associated with these events. We typically instrument this with a combination of JIRA and GreenHopper. In a pinch, it's also pretty simple to find a common wall that's central to your team and during an on-going Sprint, you can simply post an oversize sticky to the wall for each interruption. All you really need for data points are these:

• Date/Time - To gauge frequency
• Who - This is very helpful for trending. It will help uncover if there are common users/groups who are interrupting more than others.
• What - A very quick summary of the actual interruption. Again, this helps highlight patterns in types of disruptions.
• Impact - How many minutes, hours, and/or days were associated with the disruption.
• Members Involved - Just a list of the team members who were pulled in to respond to the interruption.

That's it! It's quick. It's painless, and it's extremely effective!

What if we buffer too much for BAU?

When implementing this for our customers, we're often asked what people should do if they have buffered for BAU on a Sprint, but there are zero actual interruptions? Well, if there's a trend, if you've recorded as I suggest above then I would make the case that there will almost always be interruptions. If however, your environment has blotches of interruptions and you're now factoring BAU into every Sprint, then I would suggest you take any extra time at the end of your Sprint to: (a) work on outstanding defects, (b) work on any Spike Stories ahead of the next sprint, or (c) implement an improvement highlighted during one of your retrospectives. If planning has already completed on your next Sprint and your team is ready to begin, you could always get a jump on that next Sprint ... but I wouldn't count on it. ;)

Are you accounting for BAU?  If not, full right rudder and brace for impact!!