Current Episode

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.

Nobody likes getting interrupted. I certainly don’t. But sometimes, it seems to be just a way of life. You’re working along with your team, and somebody comes in with something that has to be done right away. Sound familiar? Maybe someone’s got a pet project they’re trying to pull you on to or maybe something just happened to your production. Maybe there’s a server down and your team is needed to fix the problem. Well, today’s question comes by way of Frank. And Frank is running into this problem, it seems, relatively often. Let’s give a listen to his question and see if I can help.

Frank: Hey, Adam. This is Frank. I love your podcast. Thanks for all the useful info. My team is constantly getting interrupted with urgent requests. It is super disruptive, but it seems like we don’t have a choice. We just have to deal with the issues. Do you have any recommendations for dealing with these emergencies that show up in the middle of a sprint? Anyway, thanks again for your help.

Adam: Frank, that sounds so frustrating. You mentioned constant and disruptive. It doesn’t sound like these things are just happening occasionally and don’t have much impact. It sounds like they’re really painful. So when I run into this problem — and to be fair, it seems like every team I coach that is initially picking up Scrum runs into this issue, so you’re not alone, you’re not alone in this situation — the first thing I would do is look at the nature of these interruptions. Are they really emergencies? Are they really things that need to be dealt with immediately? Often, it seems like organizations are just really used to being super reactive. And I would question the nature of these “emergencies.”

Now, if your server is down and you’re losing a million dollars a minute, it would be pretty ridiculous to say, “Hey, thanks for telling us the server’s down, but we’re doing the Scrum thing, so we’ll talk to you at the end of the sprint. You got to wait a week and a half.” That wouldn’t be very reasonable. So if it truly is “the world is on fire and we have to fix it,” that’s one situation. But I think most of the time, the situation is that somebody, maybe somebody of high organizational authority, has decided that the thing that is going on or the thing they thought of is super, super important and needs to be worked on right away. If it’s something like your [inaudible 0:02:56] keeps you breaking, well I would spend some time breaking down some technical debt every sprint that would get stuffed into our product backlog that would help us take care of those emergencies or interruptions.

If it’s the case that people are just interrupting us because they had a great idea that needs to be worked on right away or the direction of the product keeps changing sprint to sprint to sprint, we’re being really reactive as an organization, then I think it’s very useful to have some coaching conversations. As a Scrum Master with the organization, as a Product Owner with the organization, to find out why we can’t plan stuff in our product backlog for the next sprint or two. If you have a one- or two-week long sprint, it’s really not that much time. And if stuff is trying to get changed up every sprint, I would say that we’re just not doing fantastic planning.

Now we don’t want to plan too much because we’re taking an agile approach, but we certainly should know where we’re going. We should certainly have a good idea, on average, of what we’re doing for the next sprint or two. Responding to change doesn’t mean that we just get to respond to change all the freaking time. That doesn’t make a lot of sense. It’s hard for your team. As you’ve said, it’s disruptive. It’s constant. I imagine that’s very frustrating.

And so I would have those conversations and find out where those requests are coming from and see if maybe our Product Owner could spend more time with the folks requesting these emergency features or changes or whatnot. It’s quite possible that your Product Owner just doesn’t have enough time to be a really good Product Owner. If your Product Owner is spending their time being a Product Owner for four different products, and they’re a super important person in the rest of the organization, and they really don’t have very much time to spend on any one of the four product backlogs, I suspect these sorts of interruptions will happen all the time, because that person was set up to fail. They can’t possibly spend 60%, 70% of their time getting features and requirements in order for future sprints for their team. And so when their team starts working on stuff, and then they realize it wasn’t quite the right stuff, they go and try to change it. Really frustrating. So I would look at where the requests are coming from, and if there’s any way that we can plan a little bit better.

Now let me talk about what to do if we have these production issues or emergencies you need to deal with mid-sprint. Part of it, I’ve already mentioned, which is take a look at them, and if every sprint you have a bunch of these, maybe there’s something wrong with your code base. It seems like you should tighten that up, you should spend some money every sprint fixing that situation, because it’s not going to get better on its own. In fact, it will just get worse.

The second thing you could do is one of these two approaches. Now I’m going to mention two approaches, the first of which I don’t like one bit, but I think a lot of teams use it and use it pretty successfully. My personal experience has been it’s not very successful and I’ll tell you why in a moment. And then I’ll tell you my second approach which I prefer for dealing with these “The world’s on fire, we need to deal with it now” situations.

The first approach is to figure out, hey, every spring we have 20% of our sprint that gets taken up by these emergencies. Some teams decide they will set a buffer and when they’re planning their sprint, they’ll leave that 20% free for these emergencies. Now, as I said, some teams like this a lot. I have found that it doesn’t work very well. And I think there’s two reasons. The first reason is you’re giving permission to the organization, and to your emergencies, of taking over 20% of your sprint. Again, if this is happening regularly because you have a bunch of tech debt, you should probably pay that down so it doesn’t keep costing you money, costing you time, and costing you frustration. Context switching is expensive and not particularly fun, I suspect. So the first reason I don’t like it is that really gives permission for you to be a bit sloppy.

The second reason I don’t like it is that if the organization knows that you have this 20% buffer, they’ll start trying to cram stuff into it. Then you’ll quickly find out, like most of my teams who’ve tried this find out, that 20% grows to 50% or 60% plus the other 80% you already committed to for your sprint, and you have now overtaxed your team, and sustainable pace is a thing of the past. So I don’t really love that approach. But again, I know some folks have used it and say it works well. You could try it.

But I like this other approach much better. I would look for what that request is, that emergency, whatever needs to be dealt with right then, and I would get the requester and the Product Owner, and the Scrum team and Scrum Master together , and I would have the team estimate the work involved in doing this, using whatever method they currently use to estimate their work. Then I would say, “Hey Product Owner, which one of these things that we committed to for this sprint, that equals roughly the same estimate as this thing we just estimated that’s an emergency, would you like to trade?”

The reason I like this is that there’s some pain involved. Your Product Owner has to decide something that they probably planned for an upcoming release that isn’t going to happen because of this new thing or this emergency. And I also like it because it doesn’t overtax the team. The team gets to estimate the thing and then swap it out for something which is roughly the same size. So it protects the team’s sustainable pace, it makes it a bit painful, and I think because of the bit of pain, you, as a team and an organization, can figure out how to reduce this moving forward. It puts the pain back on the organization to say, “Hey, we’re not planning very well,” or “Hey, our code base isn’t fantastic,” or whatever the situation is. You could actually get to the root of what this was, and you could probably attach a price to it.

You could say, “Hey, I’m the Product Owner for this product, and we’ve had to swap out things, over the last 3 months, 12 times, and it cost us these features which had an estimated value to our customers of X.” It can make a really strong business case for, perhaps, spending money to pay down the technical debt or spending money to get a full time Product Owner that could actually spend time on their product backlog. It could make some good business cases there that I think would be useful.

So that’s my favorite approach by far. But I wouldn’t just use the first approach or the buffer, or the second approach of trading like for like before I try to figure out why we’re always getting interrupted and trying to get that reduced.

Hey, Frank, I hope that was a useful answer for you. I know it can be super frustrating and it might take some time to help your organization realize there’s a better way than interrupting your team. For submitting your question and getting it answered on the show, you’ll get a deck of my Agile Antipattern Cards.

If anybody else out there would like to get a free deck of my Agile Antipattern Cards, you’re welcome to go submit a question at GetAgileAnswers.com. Right there on the home page, there is a little widget where you can record a question, just like Frank did, and maybe I’ll answer it on a future show. If I do, you’ll get a deck of my Agile Antipattern Cards. If you’d like to find out more about Agile Antipattern Cards that I keep mentioning, you can go check them out at my website, that’s Weisbart, W-E-I-S-B-A-R-T.com. And at weisbart.com, there’s a bunch of stuff like the Scrum Kickoff Planner, Agile Antipattern Cards, Retrospective Cookies, a bunch of fun stuff there.

I’m @weisbart on Twitter, that’s @-W-E-I-S-B-A-R-T. We’d love to catch up with you there. And if you’d like to submit a question for the show that’s not recorded, if you don’t want to use your voice, you can always submit it via an email from GetAgileAnswers.com as well.

Until next time, stay agile. Never change.