Firefighting

Some teams made a plan every week and went months without finishing one. Of five items agreed on Monday, two got started; the rest of the week went to a payment that stopped working, a screen that suddenly got slow, and a customer request that had to be patched immediately. Friday always ended with the same sentence: it was a busy week, a lot of urgent things came in.

After a few months of that explanation, teams start looking for the cause in a person. Someone is bad at managing their time, or can't stay focused. What was actually happening is that the team's situation produced the same result every week regardless of who sat in the chair, but with no name for that situation the nearest person became the cause.

Firefighting is the name for the state. It doesn't refer to running toward the fire — it refers to being so busy running that nobody does the work that keeps fires from starting. Once the state had a name, retrospectives could ask why so much unplanned work arrives instead of asking whose fault the missed plan was.

Firefighting feeds itself once it starts. The way one problem gets patched creates the next problem, and patching that one consumes the time that would have prevented it.

The loop has four beats.

1. Rushed work ships. Under deadline pressure, the first things cut are tests and code review — work whose absence isn't visible this week. The accumulation of that postponed cleanup is technical debt, and the interest starts arriving next month.
2. It comes back as a problem. An event that affects the running service is an incident, and rushed code produces them more often. Short of an outage, it produces support tickets and one-off exceptions to handle.
3. The response is rushed too. A hotfix is a deploy that patches only the broken part and goes out immediately. With no time to find the cause, the symptom gets covered, and the cover becomes next week's material.
4. Planned work slips. Items committed for this sprint roll into the next cycle, and the amount that rolled over turns the following date into pressure again. From here the loop returns to step one.

Nothing in the loop requires anyone to behave badly. Each step is the sensible local choice: shipping on the date that was promised, patching the outage that customers can see, moving the unfinished item to next week. The loop is what those four reasonable choices add up to.

After a few laps, planning itself stops meaning anything. When half of every weekly plan gets erased, nobody plans seriously, and a carelessly made plan makes the next cycle's estimates worse than the last. That effect outlasts the lost prevention time.

People usually reach for the word with one goal: pulling a conversation about individual effort back toward structure. It lands in three places.

First, naming a cause in a retrospective. "This person keeps missing the plan" and "this team is stuck firefighting" lead to different next steps. The first points at replacing whoever owns the work; the second points at reducing what arrives.

Second, planning the next cycle. Once firefighting is confirmed, the plan stops being filled to the top. If unplanned work ate 40 percent of the last three cycles, this cycle commits to 60 percent of capacity. A plan that finally gets met is the precondition for estimates that start being right. Teams resist this because the reserved capacity looks like idle time on paper, and it is the first thing a stakeholder asks about.

Third, deciding what to actually fix. Logging unplanned work shows where the fires start. If 18 of last quarter's 30 emergencies came from billing, the decision becomes spending a whole cycle cleaning up billing rather than adding people. A WIP limit, a cap on how many items can be in progress at once, often comes up alongside it. One person holding three things finishes none of them, and everything unfinished becomes next week's urgent item.

"Almost nothing we planned got done this quarter. It was all firefighting."

A report that the time was spent, just entirely on work that wasn't in the plan.

"Adding people right now just gives us more firefighting. We have to stop what's coming in first."

Arguing against a proposal to increase headcount.

"I'm holding back 30 percent of this cycle for firefighting."

Treating unplanned work as certain and reserving room for it in advance.

At Pagedeck, Theo first used the word after three cycles in a row where half the plan got done. The first explanation in the retrospective was that estimates were optimistic, so the next cycle committed to less. The shortened cycle came out the same.

So Theo spent one cycle logging every piece of unplanned work: 22 items, nine days in total. In a cycle where two people work ten days each, nine days is close to half. Fourteen of the 22 traced back to a notifications feature rushed out two months earlier. Mia dropped every new feature from the next cycle and spent the whole thing rebuilding notifications. The cycle after that had four unplanned items and a day and a half.

What Theo said in the retrospective was that skipping that one cycle would have cost roughly four days every cycle indefinitely. Without that arithmetic, cleanup always loses. A new feature is visible the week it ships, and a fire that didn't happen is visible to nobody.

Firefighting often reads as a sign of hard work. The person handling the fires genuinely was the busiest person that week, so the impression makes sense. But what comes out of it is mostly restoration — the product ends where it started. Once busyness and progress are counted as the same thing, teams praise whoever puts out fires and overlook whoever kept one from starting, and then nobody takes the prevention work.

The other mistake is treating it as unavoidable for any product with real users. That's half right: users generate tickets and outages, always. The difference is between a team that measured how much and a team that didn't. Unplanned work at 10 percent of the time is operations; at 40 percent it's a state. Without a measurement, a 40 percent state gets accepted as the way things are for years. The measurement doesn't need tooling either — a shared note where anyone adds a line for work that wasn't on the plan gets a team to a usable number in three cycles.