Failure Demand¶
Definition¶
Failure demand is work generated because something else failed — a bug, an outage, a broken integration — as opposed to planned work generated by genuine new value. It is distinct from a legitimate strategic pivot (also "unplanned" in the sense of not being on last week's plan, but a deliberate response to new information). Failure demand steals capacity involuntarily: it forces people off high-priority planned work with no notice and no choice, and every hour it consumes is an hour of predictability lost, not just an hour of output lost.
In the Book¶
Section 1.3 opens with a scenario: an executive contracts a third party to build an integration and promises "zero impact" to her product teams; the offshore team underestimates user growth, the database overloads, pages an on-call engineer, and two hours of firefighting later, the original high-priority work resumes late — right before a meeting. DeGrandis is careful to distinguish this failure demand from necessary re-planning ("let's stop marketing to everyone and just focus on large enterprises"), citing the Agile value of responding to change over following a plan — not all unplanned work is bad. She cites the 2016 State of DevOps Report finding that high-performing teams spend 28% more time on planned work than low performers, framing the ratio of planned-to-unplanned work as a quality signal, not just a scheduling one.
The book ties failure demand directly back to the WIP ringleader: unplanned work piles new WIP on top of whatever was already in progress, so the two thieves compound each other into a "twisted, codependent liaison." Her prescribed countermeasure is not better forecasting but visibility — putting failure demand on the same kanban board as planned work so its volume, rather than being absorbed silently by whoever is on call, becomes an argument for reserving capacity for it up front.
Why It Matters¶
Separating failure demand from genuine strategic change gives an organization a metric it can actually act on: rising failure demand is a symptom of upstream quality or dependency problems, and reducing it (fixing root causes) pays off twice — once in the incident itself, once in the planned work it stops crowding out. It generalizes to any system where an agent must reserve slack for demand it did not choose and cannot decline.