Fishbone (Ishikawa) Retrospective

Run a fishbone (Ishikawa) diagram to find the root causes of team challenges using the proven cause-and-effect method.

Use this template in TeamRetro

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 is a structured problem-solving approach that helps teams identify and understand the root causes of challenges or issues. Developed by Kaoru Ishikawa in the 1960s, this technique visualizes cause-and-effect relationships in a format resembling a fish skeleton. During the retrospective, teams explore six key dimensions that might contribute to their challenges: Systems, Processes, Forms, People, Policies, and Place. This comprehensive analysis ensures no potential factor is overlooked, leading to more effective solutions. This method is particularly valuable for teams dealing with complex problems where multiple factors may be at play. By organizing potential causes into distinct categories, teams can better understand the relationships between different issues and develop targeted improvements. A fishbone diagram (also called an Ishikawa diagram or a cause-and-effect diagram — the three names refer to the same tool) works by writing the problem at the "head" of the fish and drawing the major cause categories as bones branching off the spine. In its original manufacturing and quality-management form, those categories are the classic "6 Ms": Manpower (people), Method (process), Machine (equipment), Material (inputs), Measurement (data and metrics), and Mother Nature (the surrounding environment). Teams brainstorm possible causes under each bone, then keep asking "why?" to trace each branch down to its root cause rather than stopping at the visible symptom. The categories in this TeamRetro template — System, Process, Forms, People, Policies, and Place — are a team-process adaptation of the same 6 Ms method, retuned for software and knowledge-work teams rather than a factory floor. The technique is identical; only the category labels change to fit the kind of work you do. For example, 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 a team fixing symptoms and missing the underlying driver.

Fishbone Retrospective Format

System

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

Guide the team in examining technical infrastructure, software tools, and systems integration points. Encourage participants to think about both obvious technical issues and subtle system interactions that might impact their work.

Process

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

Focus on identifying bottlenecks, redundancies, or gaps in workflows. Help the team distinguish between process issues and other factors by asking about specific steps in their work procedures.

Forms

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

Examine documentation quality, accessibility, and completeness. Consider both formal and informal documentation, and how well it serves its intended purpose.

People

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

Address team dynamics and individual contributions while maintaining a blame-free environment. Focus on systemic issues rather than personal criticism.

Policies

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

Explore both formal and informal policies that impact work. Consider whether policies support or hinder current team needs and practices.

Place

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

Consider both physical and virtual work environments. Include factors like tools, workspace layout, and remote collaboration capabilities.

When to use this retrospective

  • When facing complex problems that may have multiple root causes or contributing factors
  • After identifying a significant issue or challenge that requires systematic analysis
  • When the team needs to move beyond symptoms to understand underlying causes
  • During project post-mortems or incident reviews to prevent future problems

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?

Ideas and tips for your retrospective meeting

  • Start with the effect or problem statement clearly defined at the 'head' of the fish
  • Encourage equal participation from all team members across all categories
  • Focus on identifying causes rather than jumping to solutions too quickly
  • Use the 'Five Whys' technique within each category to dig deeper into root causes
  • Document all insights, even if they don't initially seem significant
  • Schedule enough time (90-120 minutes) to explore all categories thoroughly

Frequently asked questions

What are the 6 Ms of a fishbone diagram?
The 6 Ms are the classic cause categories used on a fishbone (Ishikawa) diagram in quality management and manufacturing: Manpower (the people involved), Method (the process or workflow), Machine (equipment and tools), Material (inputs and supplies), Measurement (the data and metrics used), and Mother Nature (the surrounding environment). Each "M" becomes a bone branching off the spine of the fish, and the team brainstorms possible causes under each one. This TeamRetro template adapts the same six-category idea for software and knowledge-work teams using the labels System, Process, Forms, People, Policies, and Place.
What is the difference between a fishbone and an Ishikawa diagram?
There is no difference — they are two names for the same tool, along with a third name, the "cause-and-effect diagram." It is called a fishbone diagram because the finished drawing resembles a fish skeleton, and an Ishikawa diagram after Kaoru Ishikawa, the Japanese quality-control expert who popularised it in the 1960s.
How do you do root cause analysis with a fishbone diagram?
Write the problem at the head of the fish, then draw the major cause categories (such as the 6 Ms, or this template's System, Process, Forms, People, Policies, and Place) as bones off the spine. Brainstorm possible causes under each category, then for each one keep asking "why?" until you reach a root cause rather than a symptom. Finally, identify which root causes are most likely and most impactful, and turn those into actions. The diagram's value is that it forces the team to look across every category instead of fixating on the first cause that comes to mind.
Who invented the Ishikawa diagram?
The diagram is named after Kaoru Ishikawa, a Japanese organisational theorist and pioneer of quality management, who developed and popularised it in the 1960s as part of the quality-control movement. It remains a standard tool in root-cause analysis, manufacturing, and continuous-improvement work today.

Related templates

Four Ls Retrospective

A structured reflection using Liked, Learned, Lacked, and Longed for categories to analyze sprint performance

What? So What? Now What? Retrospective

A structured reflection framework for systematic problem analysis and action planning

Agile Retrospective

A structured way to reflect on the past sprint and identify improvements.

Start Stop Retrospective

Retrospective Idea - A focused retrospective for clear, actionable team improvements