(I’m talking about your team!)
“It is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able to best adapt and adjust to the changing environment in which it finds itself.”
-> Leon Megginson’s Interpretation of Darwin’s “On the Origin of Species”
Agile is all the rage these days, and at the forefront of Agile Software is Scrum. In it’s perfect form, we deliver valuable software every sprint and the customer is happy! Or so goes the fantasy.
There are many reasons we fail in delivering our intended value at the end of a sprint but, in this article, I’m dealing with the one issue that affects every scrum team. And if you’re being honest with yourself, this includes your team. I’m talking about Interruptions!
Who am I?
I’m a Software Development Manager who took several teams from waterfall through scrum-butt to being effective Agile Teams. I’ve been doing scrum for about 7 years and I am a certified Scrum Master, Scrum Product Owner, Scrum Software Developer and Certified Agile Leader all from the Scrum Alliance.
Interruptions
Let me just start with the plain fact that every scrum team experiences interruptions during just about ever sprint. Whether the Product Owner changes their direction mid sprint, there is a catastrophic build disaster, support requests come in, or simply sick time from team members. Our best intentions to complete the work we accepted at the beginning of the Sprint is foiled by some unforeseen interruptions. I know of some waterfall teams that refuse to convert to Agile because they have to deal with too many support requests to finish anything in 2 weeks. So, I know this is a real “issue.”
In the Novel, “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” (by Gene Kim, Kevin Behr, and George Spafford), they put forth the idea that all IT work can be broken down to just 4 types of work:
- Business work (external)
- Internal
- Changes
- Unplanned work
Notice the last item. Anyone who has tried to accomplish even the simplest of daily tasks has had the experience of an interruption of the dreaded “unplanned.” If you have small children at home, you know almost all tasks that get done fall into the unplanned category! Think about it. We know the interruption will happen. We know that our capacity will be affected and yet, seemingly, we never PLAN for it.
The Perfect Storm
One team I have became the perfect team to learn and adapt to unplanned work. Why was this team seemingly different than the others? Quite simply this team appeared to be a hy-bred team; one that is tasked with Software Development AND level 3 support. The Development part was easy. It fit the Scrum values very well. On the other hand the Level 3 support clearly did not. It’s never planned work, it’s never work that can’t wait by putting it in the backlog, and it may require outside resources to help provide a fix. And to make matters harder to plan for, our customer support team who handled level 1 and level 2 support, was a talented group that would reach out to us only when they were stumped with an issue. We may go a month between any request for level 3 support. Which is why just Kan-Ban was not going to work as there isn’t always enough Kan to Ban. ;)
The Planned “Unplanned”
Okay sure, easier said than done, right? I mean each interruption is unique and every sprint is different. How would one actually PLAN for this? Sprint one, you can’t know what to plan for but you can start to build it in. Here’s how it can work:
Say you have a Product Owner (i.e., the VP of the company) who likes to make their request the most important request (after all, they are the VP, right?). She also loves that you’re doing Scrum (mainly because it’s all the rage) but, 4 days in to the sprint with the plan she agreed to do, she comes in and pulls off the DB expert, Sally, to help with a REALLY important customer issue.
Here’s how to work this:
- After a few sprints, you will have some data that shows how often your sprints are interrupted, whether it’s missed points, or carried over stories. For this example, let’s go with the 80/20 rule let’s say 20% of the sprints don’t go as planned. (i.e., typically the team can get done 100 story points (nice round number-> your mileage may very) but sometimes it falls about 20 points short (on average).
- Now, next sprint, plan on taking on 20% LESS at the beginning of the sprint. Of course now the VP complains out loud that you are sandbagging, right? Here’s where it gets tricky from a PURE scrum, point of view.
- When the interruption comes in on day 4, gather the team, write a story for the interruption, point it, and add it to the current sprint.
Whoa! I can hear you yelling at me through your screen: “Agile says: nothing can change once we start the sprint!!” And I totally agree; but we didn’t change anything. It’s a subtle nuance to the sprint but all we did was say we are still taking on 100 points, 20 of which at the start of the sprint, is “unknown” in it’s content but KNOWN in it’s planning of doing it. Whatever “it” is going to be. If it makes you feel better, add a 20 point story called Interruptions. “As a developer, I’d like to plan on some time to deal with Customer Support.” Actually, I’m kidding. Don’t do that! Save the story for the real interruption. It’s important to do step 3 (point it, add it) because:
- The issue/interruption is properly captured and time charged against it for historical and velocity purposes.
- The number of times that seemingly really important interruption gets interrupted is high. That is, you don’t even get to start the story. For example, the meeting was called off, or not enough data was collected to fix the issue, whatever. The key is now it can go back in the backlog for a future sprint where you are planning on doing it.
Wait, if the Product Owner really wanted this story, they would have written it, right? Maybe. Maybe not. OR this might just be a bug that would not involve the Product Owner. The key is track it (point it, add it).
The Tale of 2 Backlogs
Back to the 80/20 rule. How do we tackle the issue of that 20% of “planned unplanned” if nothing shows up to interrupt the sprint. My team works from two backlogs; The 1st is the normal product back log and the 2nd is the “technical debt” back log. This back log is maintained and prioritized by the team, not the Product Owner. In fact the Product Owner need not know about it at all if you don’t want them to. In Jira, it’s not easy to have one sprint pull from two backlogs so we just put it in it’s own category called Tech Debt. That way it’s easy to filter it out (or in) by category.
Tips
A couple of quick tips:
- Avoid the single person expert getting called out to help. We do this giving the interruption to the Team, not the person. The Team will decide who will do what tasks. Have the person singled out, to tell the interrupter “I’ll submit this to the team so, we can address this immediately and with the best possible resources.” I’ve never gotten push back from this statement. Who’s going to argue with “the team is on it!”?
- The sooner your teams become cross functional, the easier this works. I know the DB expert, for example, is the only person to fix the issue but don’t fall into that trap. Have the DB expert walk the new guy through the steps he’d take, gather the key data points, etc. After that, pull in the DB expert to fix or finish what the new guy is not capable of. That does two things. One, it frees up the DB expert to continue on what they need to get done for the sprint and two, it spreads out the knowledge for next time a similar issue comes up. Next time 2 people can address the interruption.
In conclusion
Plan, for your unplanned work and your team will be happier (no one likes to be interrupted!) and measure the unplanned work with the normal scrum tools like stories and points (point it, add it).
Agile is all about subtle nuances. This is just one example and your mileage may vary but, I hope you can put this in your tool set to make your teams more efficient. Let me know your thoughts and success stories!
