Interruptions by management happen for any number of reasons. Sometimes they are impetuous but not always. There is often a real need for interrupting the team. One based on the target of greater business value realization. This may be fixing a severity one error or a new opportunity that has arisen in the market.
Regardless of the reason, interruptions cause problems. One of the reasons for this is that management often thinks a one-day interruption only slows down the team by a day. But there is a cost to the interruption that is often much more the delay itself. Putting work down and then bringing it back to mind often causes a ripple effect many times the cost of the initial delay.
Although sometimes these interruptions consider this and should be done, very often they shouldn’t.
Let’s use the four step process here:
Objectives of the practice
The objective of not being interrupted has several aspects to it. Interruptions have a lot of negative consequences that we should avoid. These include:
How to do the practice better
One way to help stop interuptions may be to make make management aware of the cost fo the interruption. As obvious as it seems to the development team, management may not really get the cost of the interruptions. Most team members won’t have the courage to say no to someone who has authority over them. Some deverlopers even like the urgency caused by the interruption, even if it’s not healthy.
At a minimum, the team should make the cost of the interruption visible. This alone may stop many interruptions. Two stories are required to do this. The first story is for the interruption itself, while the second one is for the additional cost of the interruption. If you’re tracking velocity people outside of the team may be very surprised to see how much of the velocity is being caused by interruptions.
The intention is to compare the value of the interruption (how pushing it onto the teams achieves a certain value) against the cost of the interruption (both the added work and the delay of what had been planned for). Interruptions should only occur when the benefit is greater than the real cost.
Of course, making the cost of the interruptions visible is no guarantee they’ll stop. Look at What to Say When Someone Just Doesn’t Get It.
Alternatives to the practice
Make the work being done interruptable
Interruptions are often driven by a true business need, in full awareness of the extra cost. In this case, we may want management to interrupt us – when the financial opportunity presents itself. So, let’s go through our questions. The purpose of this practice is to not interrupt our workflow. The principles we’re following is to not have too much work in process. The laws underneath this are that these interruptions and too much WIP will cause additional work for us. The other way to achieve this is to use small stories, manage the WIP inside our sprint and use automated testing so as to require management to have a delay of only a couple of days before we can start the new work with all of our other work being completed.
The main cost of interruption is not the pushing items on our sprint backlog down, it is the cost of the interruption of the work taking place. Inserting new work above something in the sprint backlog that hasn’t been started is not nearly as costly as inserting something into the sprint while we are working on stories and having us work on too many things or having to set aside some partially completed stories to the next sprint.
How to test if an alternative is better
If interruptions that are not validated by overall improvement in cost of delay decrease, then you’ve made an improvement. Or, if the cost of the interruptions goes down, you’ve made an improvement.