Interrupts Unjam Blocking

If you need to schedule urgent development activities according to some reasonable priority scheme, then use an interrupt scheme to keep individual problems from blocking the entire project.undefined

To be applied before

 * Programming Episode, Someone Always Makes Progress and Work Flows Inward are inputs for Interrupts Unjam Blocking.
 * Team Per Task is refined by Interrupts Unjam Blocking.

To be applied after

 * Interrupts Unjam Blocking is refined by Don't Interrupt An Interrupt.

Alternatives

 * Interrupts Unjam Blocking is an alternative to Informal Labor Plan.

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

Context
... you are fine-tuning scheduling in a high productivity design/implementation process or low-latency service process. The scheduling problem is to be addressed on a small scale (i.e., this is not scheduling entire departments, but the work of cooperating individuals). You want to use Informal Labor Plan, but need additional criteria for individuals and small groups to plan their schedules. Local decisions may lack the scope necessary to avoid duplication of work, missed opportunities, and other silliness.

Problem
A comprehensive scheduling plan is difficult if not impossible; yet, without some kind of plan, it becomes easy to fall into thrashing.

The events and tasks in a process are too complex to schedule development activities as a time-linear sequence.

Complete scheduling insight is impossible. Even if it were possible to capture the entire picture of the project for an instant, it would change very quickly. The dynamics of project development mean that the best we can hope for is a high-level, approximate schedule.

The programmers with the longest development schedules will benefit if more of others’ code is done before they try integrating or testing later code, and their interval can’t otherwise be shortened (see Code Ownership).

Solution
If a role is about to block on a critical resource, interrupt the role that provides that resource so they stop what they’re doing to keep you unblocked.

The nature of the critical resource can vary. It may be a software module that is in the critical path. It could be the latest software integration. It is often critical knowledge, without which one cannot move forward. Whatever the resource is, the approach is to interrupt the provider of the resource.

Discussion
If the overhead is small enough, it doesn’t affect throughput. It will always improve local latency.

The process should have a higher throughput, again, at the expense of higher coupling. Coupling may have already been facilitated by earlier patterns, such as Work Flows Inward, Move Responsibilities, Responsibilities Engage, Hallway Chatter, and Coupling Decreases Latency.

The intent is that this pattern will apply most frequently between cooperating developers working on a single project. This is supported empirically from a high productivity process in AT&T. There are strong software engineering (operating system) principles as well.

It may be useful to prioritize interrupts, and service the ones that would optimize the productivity of the organization as a whole. That is, it is better to unblock 4 people who are currently blocked than to unblock a single squeaky wheel. The decision-making process should be fast: Most of the time, it should be distributed. Where arbitration is needed, apply Patron Role. The simplest resolution is the pattern Don't Interrupt An Interrupt.

The Patron Role and manager role can help the team audit the project for blocked progress, but should defer to the developers (or other directly impacted roles) to resolve the blockage when ever possible. Management intervention can be effective, but may risk good will within the project.

Joe Maranzano notes a corollary to this pattern is another pattern: Don’t put too many critical tasks on one person (which is related to Moderate Truck Number and Distribute Work Evenly).

This pattern is much less effective if the provider of the resource is not in the same project as you are. In that case, the provider has little incentive to service your interrupt, and you risk alienating the provider if you engage in incessant pestering. This problem can be mitigated by adopting a policy of reciprocity, fair and proactive exchange of value among partners. [Dikel2001].