Situation

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:

1. Are we having challenges with the practice because we’re doing it poorly? Answer: No. We’re not the cause of this.
2. Is there something else in the organization that is causing us this problem? Answer: Yes. How can we influence this then?

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:

1. It pushes back work that we had promised and doing so may have consequences to other teams
2. Delivery may be affected
3. The team may have to work harder to meet goals. Doing this on a long term basis is not sustainable
4. It may lower focus of the team
5. It may lower morale of the team where they don’t try to complete the sprint given they are interrupted and think if management doesn’t care why should they.

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.