Highlights from ”Past the Tipping Point: The Persistence of Firefighting in Product Development” by Nelson Repenning, Paulo Gonçalves, and Laura Black.

Putting out fires is not improvement. Finding a point out of control, finding the special cause and removing it, is only putting the process back to where it was in the first place. It is not improvement of the process.

—W Edwards Deming

Unplanned allocation of resources to fix problems can switch the entire company to epidemical firefighting and organizational pathology. Even a temporary increase in workload can initiate the firefighting dynamic and cause a permanent decline in system performance and health.

Firefighting:

• snaps into place when pushed beyond the tipping point or threshold;
• drives out disciplined and more structured (development) processes, becoming the (development) process instead;
• can significantly degrade an organization’s ability to create high quality products in a stable, predictable, sustainable and resilient way;
• is a self-reinforcing syndrome with a tipping point, and is, therefore, fragile;
• is hard to recognize (its symptoms), causing corrective action to be taken too late;
• comes very naturally.

Likely goals:

• be an innovative, competitive, stable, predictable, sustainable and resilient organization;
• stay clear of the tipping point when you are on its productive and innovative side;
• get close to the tipping point a.s.a.p. when you are in firefighting mode, and then nimbly nudge it over.

To avoid firefighting to become a company-wide disease:

• discourage, ignore or penalize heroism and heroic behavior;
• use a boom buffer with a clear policy and managerial impact when excepted;
• keep current tools and technology, avoiding time needed to invest in learning them that (temporary) lowers productivity;
• have a laser focus on top quality for product, process and people as lower quality will push the organization into the death spiral of declining competitiveness, reduce revenue and future innovation;
• do root cause analysis and resolution of the top problems—just postponing problematic projects does not prevent the spreading of firefighting, it just pushes them downstream to bite you next year, and probably harder;
• perform aggregate resource planning to prevent fires;
• reduce the number of parallel products or projects—so bring focus;
• avoid full utilization of human assets, cherish slack resources as a buffer against uncertainties instead;
• aggressively cancel failing projects early;
• revisit the product plan instead of trying to catch up;
• do not rent or steal people from or lend people to other parts of the organization as it might start a fire;
• reduce workload effectively to stabilize the system, e.g. by skipping a model year altogether;
• do fewer projects and cancel more (did I say that already?);
• put a strict (Work In Progress or WIP) limit on many or all parts of the value stream, and use those to maximize flow;
• undercommit and overperform;
• uphold a strict policy of only accepting finished, done work, and mercilessly reject any unfinished work and loose ends;
• perform thorough up-front work;
• make policies and admission criteria to pull something into the next step crystal clear, as this will:
  • increase the likelihood that the item will get done in time;
  • reduce or avoid the need to cancel it later;
  • make owners face strong incentives to invest in the early phase activities and develop clever ways to demonstrate the efficacy of a proposed product far in advance of its detailed design.

All this resonates with agile, scrum, lean, and kanban.

---

A solution to stalled