Fishbone (Ishikawa) diagram

What it is

The fishbone diagram was invented by Kaoru Ishikawa at Kawasaki Heavy Industries in the 1960s as part of Japan’s post-war quality-control movement. It was codified in English in Ishikawa’s Guide to Quality Control (Asian Productivity Organization, 1976 translation), which remains the canonical source. Ishikawa was one of the seven original quality gurus whose work shaped Total Quality Management — the diagram is one of his “seven basic tools of quality” alongside histograms, Pareto charts and control charts.

The original industrial usage organized causes into the 4 M’s — Method, Machine, Material, Manpower. Later practitioners added two more — Measurement and Milieu (the environment) — giving the commonly-taught 6 M’s. These categories aren’t sacred. They’re scaffolding that nudges the team to think broadly enough that they don’t converge on the first plausible cause before the others have a chance to surface.

For software-delivery teams, the 6 M’s don’t map cleanly. We use this set instead:

The categories matter less than the discipline of spreading attention across at least four or five of them before concluding. A fishbone whose only populated branch is Tools is telling you the team didn’t look hard enough at the others.

When to use it

Use a fishbone when:

• The problem has multiple contributing factors and picking one feels arbitrary. Recurring incidents, chronic performance issues, persistent planning misses — these almost always have distributed causes.
• You ran 5 Whys and the action item didn’t fully land. That’s a signal the cause tree had branches you didn’t explore.
• The team holds different hypotheses about the cause. Fishbone lets each hypothesis land on the board next to the others, so the comparison is visual rather than rhetorical.
• You’re investigating a recurring symptom. One-off incidents can be linear; recurring ones are almost always the result of several factors reinforcing each other.

Don’t use a fishbone when:

• The cause chain is clearly linear — X happened because Y, and Y happened because Z. Fishbone is overkill; 5 Whys is faster and produces the same answer.
• The team is still arguing about what actually happened. Fishbone assumes the head of the fish (the problem statement) is agreed. If people can’t agree on the symptom, observe first — Gemba walk or journey mapping — then come back to fishbone.
• You need a quantified ranking. Fishbone surfaces possibilities; it doesn’t weight them. After the fishbone, combine with Pareto analysis if you have data, or a 2×2 matrix if you don’t.

The rework workshop chooses between 5 Whys and fishbone based on the shape of the symptom — a clean linear chain gets 5 Whys; a distributed pattern with multiple contributors gets fishbone. The two methods complement each other; they’re not in competition.

How to run it

Total time: 15–30 minutes, depending on team size and how dense the diagram gets.

Setup (2 min). Draw a horizontal arrow across the board pointing right, ending at a box that contains the problem statement. The box is the fish’s head; the arrow is the spine. State the problem in a single specific sentence. “Deployment failures keep recurring” is fine. “Our deploys are bad” isn’t — there’s nothing to cause-analyze.

Decide categories (2 min). Pick four to six categories for the major diagonal branches. For software teams the default is People, Process, Tools, Data, Environment, External. Deviate when the problem suggests a better set — a team investigating a UX issue might want Interaction, Copy, Visuals, Navigation, Performance instead. The goal is coverage, not adherence to a specific list.

Silent brainstorm (5–8 min). Each participant writes possible causes on stickies, one per sticky, silently. Silent start is again doing the work of the “1” in 1-2-4-All — preventing the loudest voice from anchoring the diagram before the quiet ones write anything.

Share and place (8–12 min). Each person reads their stickies aloud as they place them on the appropriate branch. If a cause feels like it belongs in two categories, don’t debate — just place it in one, or duplicate it. The categories are scaffolding, not adjudication.

Ask why within each branch (5–8 min, optional). For dense branches, do a mini-5-Whys on the top contributor. “Why does CI take 40 minutes? The test suite takes 30. Why? We don’t parallelize. Why? Nobody owns the test infrastructure.” The fishbone can host multiple short why-chains — that’s the point. You’re not choosing one line; you’re exploring several.

Mark the vital few (3 min). Ask the team to dot-vote (three dots per person) on the causes that feel highest-leverage. The two or three causes with the most dots become the action candidates. Those are what you go work on — the rest of the diagram is context.

Worked example

A team runs a rework workshop and, rather than a single linear chain, the story of their recurring deployment failures has contributors showing up in five of the six categories. They run a fishbone:

What the team does with this. Dot-voting surfaces two clusters: no rollback rehearsal (Process) and staging configuration drift (Environment) each get four of the six votes. Those become the action items. The team doesn’t try to fix everything on the diagram — that would be a losing battle. They pick the two with the highest-leverage and accept that the others are either downstream effects of those two (rollback rehearsal addresses the on-call-overload contributor indirectly) or worth tracking but not acting on this sprint.

Why the fishbone was the right tool here. A 5 Whys would have chased one branch — most likely CI reports green on flaky tests or no rollback rehearsal, depending on who held the pen — and the action would have addressed only one of the five contributing factors. Deployments would still have been breaking for reasons not touched by that action. The team would have concluded “5 Whys didn’t work” when in fact the problem wasn’t a 5 Whys problem to begin with.

Common failure modes

• One fat branch, five empty ones. The team populated Tools with fifteen stickies and put one thing in People, one in Environment, and nothing elsewhere. Symptom: the team is most comfortable blaming their toolchain. Fix: the facilitator explicitly names each empty branch and runs a focused silent-write on it — “two minutes on People, just People, stickies down.” Then repeat for each underpopulated branch. Real fishbones usually have content in at least four of six categories.
• Stickies are restatements of the problem. “Deploy fails” on the Process branch isn’t a cause — it’s the problem relabeled. Symptom: the stickies aren’t causal statements, they’re symptoms. Fix: require every sticky to be phrased as “because X” or “X is happening.” If it isn’t, it’s not a cause.
• Debating categorization instead of investigating causes. Two participants spend five minutes arguing whether “CI is slow” is a Tools issue or a Process issue. Symptom: wasted time on labels. Fix: the facilitator places the sticky arbitrarily and moves on. Categories are scaffolding. What matters is that the cause is on the board.
• Confusing fishbone with root-cause analysis. Fishbone surfaces contributing factors. It doesn’t reach a single root cause — it reaches several. Symptom: the team is frustrated that the fishbone didn’t produce one answer. Fix: reset expectations. The output of a fishbone is a prioritized shortlist of action candidates, not a single root cause. If you genuinely need a single root cause, run 5 Whys on the top dot-voted candidate.
• Acting on every sticky. The team leaves the workshop with a list of eighteen action items. Symptom: the team mistook the fishbone for a to-do list. Fix: dot-vote ruthlessly. The vital few matter; the trivial many are context. If your action list is longer than three items from a single fishbone, you haven’t prioritized.

References

In the playbook

• Rework workshop — fishbone is the alternative root-cause technique for distributed-cause cases; 5 Whys is used when the chain is linear.
• 5 Whys — the linear-chain cousin; often runs inside a fishbone branch on the highest-voted cause.
• A3 problem solving — Section 4 (Root Cause Analysis) of an A3 often summarizes a fishbone rather than a 5 Whys when the causes are distributed.
• My formula for running a successful workshop — the meta-framework every workshop in the Guides section follows.

External references

• Kaoru Ishikawa, Guide to Quality Control (Asian Productivity Organization, 1976 English translation; Japanese editions from 1968 onward) — the canonical source. Describes the diagram alongside Ishikawa’s other “seven basic tools of quality.”
• Kaoru Ishikawa, What Is Total Quality Control? The Japanese Way (Prentice Hall, 1985) — broader context for where the fishbone sits within Japanese quality management.
• American Society for Quality, Fishbone (Ishikawa) diagram — practical facilitator reference.
• Lean Enterprise Institute, Cause-and-effect diagram — the Lean community’s reference entry.
• Tague, The Quality Toolbox (ASQ Quality Press, 2005) — the most practical single-volume reference for fishbone and its companion tools.