Five Whys
Five Whys is a technique, not a retrospective. Twenty minutes inside a retro, on one specific incident — not the whole meeting.
A root-cause technique from Sakichi Toyoda and the Toyota Production System: ask why until you reach a cause you can act on. Five is convention, not gospel — Toyoda himself never said exactly five. Use it inside a retrospective to dig into one specific incident; don't run it as your whole retro.
When to use
Inside a retrospective, after the team has identified a specific mechanical-cause incident worth investigating — the build broke, the deploy failed, the migration corrupted a table. Don't run it as a whole meeting. Don't run it on incidents where there's a person at the end of the chain — Five Whys with a person at the end is a blame exercise dressed up as analysis. For complex incidents with multiple contributing causes, run Fishbone instead.
How it runs
Pick one incident
One. Specific. Time-bounded. 'The deploy failed at 14:32' not 'deploys are flaky.' If you can't state the incident in one sentence, you're not ready to run Five Whys yet.
State the problem clearly
Write the incident as a single declarative statement. Everybody in the room agrees on the wording before you start asking why; otherwise you'll get five whys answering five different questions.
Ask why, write the answer, repeat
Each answer becomes the next 'why.' Stop when you reach a cause that's mechanical and actionable — not when you've hit five. Three is fine; seven is fine; the count isn't the point.
Replace 'why' with 'how' if it goes near a person
Allspaw's 'Infinite Hows' rule: if the chain reaches a human decision, switch from why to how. Why leads to blame; how leads to learning. 'Why did Maya merge it?' becomes 'How did the merge get past the checks Maya was working with?'
Commit to one fix
The output is one change to the system that prevents the same chain. Not three. One. Owner, deadline, written down before you leave the meeting.
Why it works
Repeated 'why' resists the team's first answer — which is almost always too shallow to act on. Each follow-up forces a layer deeper. The technique works on mechanical-cause incidents (a thing broke; what made it break) and fails on sociotechnical incidents (a thing broke because of how multiple people, processes, and tools interacted). The five-times convention is psychological — far enough that you'll get past the surface answer, short enough that the team won't lose patience.
Variations
- Three Whys for a smaller incident or a tighter time budget. The number is convention, not method.
- Pair it with Fishbone — Five Whys to surface candidate root causes, Fishbone to organise contributing factors. Most software incidents need the second.
- Run it as a written exercise async — one person drafts the chain, the team comments. Surfaces disagreement on causes that a live discussion would smooth over.
Facilitator notes
Watch for blame creeping into the chain. The classic failure mode is a why-chain that ends at a person — 'Maya merged the bad commit.' That's the technique pointing at a human and calling it root cause. Switch to 'how' the moment the chain approaches a person; the goal is the system that allowed the merge, not the person who clicked the button.
Pitfalls
- Treating it as a full retrospective. Five Whys is a 20-minute technique inside a retro, not the meeting itself.
- Stopping at five because five is in the name. Stop when you've reached a mechanical cause you can act on. That's three sometimes, eight other times.
- Why-chains that end at a person. That's a blame exercise. Switch to 'how' before the chain reaches a human.
- Running it on multi-cause incidents. Most software bugs have many contributing causes — Fishbone is the right tool for those.
Remote tips
A linear why-chain shows up well on a shared doc — a stacked list with each 'why' indented under the previous answer reads better than any visual diagram remotely. Type the chain as the team builds it; the written log is the artefact that survives the call.
Example outputs
- Incident: production deploy failed at 14:32 on Tuesday.
- Why? The migration timed out. Why? It locked a table for 90 seconds. Why? The query scanned the whole table. Why? Missing index on a foreign key. Why? The migration generator skips index creation on FKs.
- Fix: change the migration generator default to create FK indexes. Owner: platform team. Deadline: end of next sprint.
FAQ
- Five Whys or Fishbone?
- Five Whys when the cause is likely a single chain — a mechanical failure that traces back through one path. Fishbone when there are likely many contributing causes, which is most software incidents. Five Whys gives you a chain; Fishbone gives you a map. If you ran Five Whys and the chain branched at every step, you needed Fishbone.
- Can I run Five Whys as my whole retrospective?
- No. Five Whys is a 20-minute technique inside a retro, focused on one specific incident. If you ran Five Whys for an hour, you ran the wrong meeting. Use SSC or Sailboat for the retrospective itself, then drop into Five Whys when the team has identified an incident worth digging into.
- What if the chain ends at a person?
- Switch from 'why' to 'how' before that. John Allspaw's 'Infinite Hows' (Kitchen Soap, 2014) is the canonical critique: 'why' leads to blame, 'how' leads to learning. 'Why did Maya merge it?' is a blame question; 'How did the merge get past the checks?' is the systems question you're actually after.