Don't Interrupt An Interrupt ★

The original interruption device.

...you've applied InterruptsUnjamBlocking, but notice that the organization is now thrashing, particularly in the end game or under heavy churn.

✥ ✥ ✥

It's important to balance a desire that SomeoneAlwaysMakesProgress 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.

Therefore:

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.

✥ ✥ ✥

This prevents endless churn that can result from too much context switching. It helps ensure that SomeoneAlwaysMakesProgress. 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 [BibRef-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.