Don't Interrupt An Interrupt

If you're in the middle of handling an interrupt to keep the project from getting stuck, and a new urgent need arises, then continue handling the current issue before moving on to the new one. undefined

To be applied before

 * Interrupts Unjam Blocking and Someone Always Makes Progress are inputs for Don't Interrupt An Interrupt.

Contents of following sections belong to the original Organizational Patterns website and have been divided into following parts: Context, Problem, Solution, Discussion.

Context
...you’ve applied Interrupts Unjam Blocking, but notice that the organization is now thrashing, particularly in the end game or under heavy churn.

Problem
It’s important to balance a desire that Someone Always Makes Progress with the thrashing that can accompany short-term priority calls. One worker will inevitably be blocked on you—you can’t do both things at once. Complete, omniscient foresight and scheduling are unreasonable to expect.

Solution
If a developer is already working in “interrupt mode” on a critical issue, don’t put that work aside until it is complete or until that issue itself becomes hopelessly tangled.

Discussion
This prevents endless churn that can result from too much context switching. It helps ensure that Someone Always Makes Progress. And it provides some “back pressure” in the process that can help temper irresponsibly quick reversals of position in the front-end.

This is a simple, though somewhat arbitrary, rule to keep scheduling from becoming an elaborate ceremony.

This relates to the “red zone” from Linda McLyman’s analysis of the Satir change model [Satir1991], that suggests that if a foreign element (problem) arrives before the organization starts to learn its way out of the last foreign element, recovery is difficult.