Practice: Handling External Interruptions

Why to Do This Practice

Interruptions by management happen for any number of reasons. Sometimes they are impetuous but not always. There is often a business need to interrupt 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 than 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.

Who Does This Practice

Here are the roles involved in this practice:

Product owner
Team lead
Team members

What to Do

Approach

Use a simple set of diagnostic questions to consider.

Is the interruption being caused because we did not ask for the information up front? Update the “definition of ready” kit so this will not happen again.

Are we having challenges with the practice because we’re doing it poorly? If not, then we are not the cause of this.

Is there something else in the organization that is causing us this problem? If yes, then how can we influence this then?

Discussion

The objective of not being interrupted has several aspects to it. Interruptions have a lot of negative consequences that we should avoid. These include:

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

How to Do the Practice Better

Cost of Interruptions

One way to help stop interruptions may be to make management aware of the cost of 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 developers 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.

Red Card

A common technique is to give management a small number of “red cards” which they can raise when they absolutely must interrupt for an urgent need. For management, the rule is that they get a small set and agree to use them sparingly. For the team, the rule is that when a red card is raised, then everyone who can help to address the issue agrees to swarm on the issue to get it resolved and then go back to their work. Multi-tasking is not allowed.

Make the Work Being Done Interruptible

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 principle we are 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 to require management to have a delay of only a couple of days before we can start the new work with all the 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.

Outcomes

Addressing interruptions has several benefits.

Addressing urgent business needs in a timely fashion
Process improvement
Better definition of ready for next time
Better understanding by management of the cost of interruption
Less chaos and better morale