Fishbone (Ishikawa) Retrospective

Trace a team problem back to its root causes

Try this retrospective live

System

What technology, software, or tools might be affecting our team's performance or outcomes?

Our deployment pipeline often fails during peak hours
The testing environment doesn't match production settings
Integration between our task tracking and git tools is unreliable
Process

What workflows or sequences of activities are causing delays or inefficiencies in our work?

Code review process takes too long with multiple back-and-forth cycles
No clear definition of done for user stories
Sprint planning meetings regularly exceed scheduled time
Forms

What issues with our templates or documentation could be impacting clarity or accuracy?

User story template lacks acceptance criteria section
Incident report form doesn't capture root cause effectively
Documentation is scattered across multiple platforms
People

What factors related to individual or team skills, communication, or roles are affecting our success?

Team lacks expertise in new technology stack
Communication gaps between remote and office team members
Unclear roles and responsibilities in cross-functional projects
Policies

What guidelines or rules might be misaligned with our actual practices or creating challenges?

Security policies make local development difficult
Change management process is too rigid for quick fixes
Vacation policy creates resource constraints
Place

What aspects of our physical or virtual workspace might be impacting our collaboration or productivity?

Poor internet connectivity in remote work locations
Lack of quiet spaces for focused work
Virtual collaboration tools don't support our needs well

What is the Fishbone (Ishikawa) Retrospective?

The Fishbone (Ishikawa) Retrospective helps your team find the root causes of a problem instead of treating its symptoms. It's built on the cause-and-effect diagram that Kaoru Ishikawa popularized in the 1960s, which lays out possible causes in a shape that looks like a fish skeleton. In this template your team works through six cause categories: System, Process, Forms, People, Policies and Place. Going category by category makes people look past the first explanation that comes to mind, so causes outside anyone's own area still get raised. It's most useful for problems with several contributing factors, where one obvious fix hasn't worked. Sorting causes into categories shows how they connect, and that points you to the change that will make the biggest difference. A fishbone diagram (also called an Ishikawa diagram or a cause-and-effect diagram; all three names mean the same tool) puts the problem at the "head" of the fish and draws the major cause categories as bones branching off the spine. In its original manufacturing and quality-management form, those categories are the "6 Ms": Manpower (people), Method (process), Machine (equipment), Material (inputs), Measurement (data and metrics) and Mother Nature (the surrounding environment). The team brainstorms possible causes under each bone, then keeps asking "why?" to follow each branch down to its root cause. This template's categories adapt the 6 Ms for software and knowledge-work teams. The technique is the same; only the labels change to fit the work you do. If the problem at the head of the fish is "releases keep slipping," a People cause might be "key reviewer is a bottleneck," a Process cause might be "no definition of done," and a System cause might be "flaky CI pipeline." Mapping causes this way stops your team fixing a symptom and missing what's actually driving it.

Fishbone retrospective format

System

What technology, software, or tools might be affecting our team's performance or outcomes?

Look at your technical infrastructure, software tools and the points where systems connect. Ask about obvious technical faults and also the quieter ways systems interact that slow the work down.

Process

What workflows or sequences of activities are causing delays or inefficiencies in our work?

Look for bottlenecks, duplicated steps and gaps in your workflows. Asking about specific steps in how the work gets done helps the team separate process problems from other causes.

Forms

What issues with our templates or documentation could be impacting clarity or accuracy?

Look at your templates and documentation. Can people find what they need, is it complete, and does it do its job? Include informal documents as well as formal ones.

People

What factors related to individual or team skills, communication, or roles are affecting our success?

Talk about skills, communication and roles while keeping the discussion blame-free. Focus on the conditions around people, like unclear roles or knowledge silos, not on criticizing individuals.

Policies

What guidelines or rules might be misaligned with our actual practices or creating challenges?

Look at the written and unwritten rules that affect the work. Ask whether each policy still supports how the team works today or gets in the way.

Place

What aspects of our physical or virtual workspace might be impacting our collaboration or productivity?

Consider the physical and virtual workspace, including your tools, the office layout and how well remote collaboration works.

When to use this retrospective

  • When a problem probably has more than one cause
  • After a significant issue that needs a structured look before anyone proposes a fix
  • When the team keeps fixing symptoms and the problem keeps coming back
  • In project post-mortems or incident reviews, to stop the same failure happening again

Suggested icebreaker questions

  • If our team were a machine, what part would need the most maintenance right now?
  • What's the most surprising solution you've discovered to a recurring problem?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Write a clear problem statement at the head of the fish before anyone adds a cause
  • Make sure everyone adds causes to every category, including the ones outside their own role
  • Hold off on solutions until the causes are mapped
  • Use the Five Whys inside each category to dig past the first answer
  • Record every cause, even ones that seem minor at first
  • Allow 90–120 minutes so you can cover all six categories properly

Frequently asked questions

What are the 6 Ms of a fishbone diagram?
They're the classic cause categories on a fishbone (Ishikawa) diagram in manufacturing and quality management: Manpower (people), Method (process), Machine (equipment and tools), Material (inputs), Measurement (data and metrics) and Mother Nature (the environment). Each M becomes a bone off the spine, and the team brainstorms causes under each one. This template adapts the idea for software and knowledge-work teams with System, Process, Forms, People, Policies and Place.
What is the difference between a fishbone and an Ishikawa diagram?
There's no difference. Fishbone diagram, Ishikawa diagram and cause-and-effect diagram are three names for the same tool. "Fishbone" comes from its shape, and "Ishikawa" from Kaoru Ishikawa, the Japanese quality-control expert who popularized it in the 1960s.
How do you do root cause analysis with a fishbone diagram?
Write the problem at the head of the fish and draw the cause categories as bones off the spine. Brainstorm causes under each one, then keep asking "why?" until you reach a root cause, not a symptom. Pick the root causes that are most likely and have the biggest effect, and turn those into actions.
Who invented the Ishikawa diagram?
It's named after Kaoru Ishikawa, a Japanese organizational theorist and pioneer of quality management, who popularized it in the 1960s. It's still a standard tool in root cause analysis and manufacturing quality work.

Related templates

Four Ls Retrospective

Reflect on what your team Liked, Learned, Lacked and Longed for

What? So What? Now What? Retrospective

Go from what happened to what you'll do next.

Agile Retrospective

Four questions to review your last sprint and plan changes.

Start Stop Retrospective

Two questions: what to start, and what to stop

Ready to run this retrospective?Try this retrospective live