A fishbone diagram, also called an Ishikawa or cause and effect diagram, maps the causes of a problem onto a fish skeleton: the problem at the head, general causes on the main bones, and detailed causes branching off each one. This template is a blank skeleton with four cause branches and nested sub-cause labels, plus a reference Ishikawa example. Teams use it for root cause analysis in retrospectives and post-incident reviews.
Both are root cause analysis tools, but they move in different directions. A fishbone diagram is breadth-first: it spreads every plausible cause across categories like method, machine, and people, so nothing gets ignored because the loudest theory arrived first. The 5 Whys is depth-first: one symptom, asked why repeatedly until the chain bottoms out. Use them together: fishbone to map the territory, then 5 Whys to dig where the team votes.
A fishbone diagram is a cause and effect diagram shaped like a fish skeleton: the problem sits at the head, major cause categories form the large bones, and specific causes and sub-causes branch off each one. Kaoru Ishikawa popularized it in 1960s Japanese quality control, which is why it's also called an Ishikawa diagram. Teams use it to structure root cause analysis.
The 6 Ms are the classic cause categories from manufacturing: Machine (equipment), Method (process), Material, Manpower (people), Measurement, and Mother Nature (environment). They're a starting point, not a rule. Service teams often swap in the 4 S categories (surroundings, suppliers, systems, skills), and software teams usually do fine with process, people, tooling, and environment. Pick categories that fit the problem.
A fishbone diagram goes broad; the 5 Whys goes deep. The fishbone lays out many possible causes in parallel across categories, which suits messy problems with several contributing factors. The 5 Whys drills a single cause chain by asking why five times. They work best together: brainstorm the fishbone first, then run 5 Whys on the one or two causes the team votes most likely.
The same diagram travels under four names: fishbone diagram (for the shape), Ishikawa diagram (for Kaoru Ishikawa, the quality pioneer who popularized it), cause and effect diagram (the formal name standards bodies use), and occasionally herringbone diagram. They're interchangeable. Whatever you call it, the structure is identical: an effect at the head and layered causes along the bones.
Reach for a fishbone when a problem has more than one plausible cause and the team keeps arguing about which: a quality defect, a recurring process failure, a surprise outage. It works before solutions, not after; the point is to map causation while it's still an open question. Product teams also use it in retrospectives to unpack what went wrong without pointing at people.