Fishbone Diagram

Ruth Hadari
Ruth Hadari
Agile Advocate, Engineering Ops Expert
Posted on
Apr 29, 2022
Updated on
Mar 16, 2023
Table of Content

It’s easy to get lost in the details of what you do. You might be so focused on individual tasks that you forget how they all fit together. To help you focus on the big picture, you can use the fishbone diagram, a simple tool that can help keep you focused and on track with following through on your goals.

In this article, we’ll explore what a fishbone diagram is and how it can help your Agile software development team.

What Is a Fishbone Diagram?

A fishbone diagram is also known as a cause-and-effect diagram or an Ishikawa diagram. Its name comes from its resemblance to a fish skeleton. The “head” of the fish is the problem that you’re trying to solve, while the “bones” are potential causes for that problem.

You can use a fishbone diagram when you’re trying to figure out why something went wrong or when you want to prevent future problems. It’s especially useful for complex issues with many possible causes.

In the Ishikawa diagram, each bone represents a different area or topic for analysis. The bones are then divided into smaller branches, called “leverage points,” where causes are identified for problems within those branches.

It might seem like this would be more complicated than just looking at the problem head-on: instead of identifying just one cause for the problem, you’re looking at multiple causes within different areas. However, this approach can actually simplify the problem-solving process.

What makes a good fishbone diagram?

A good fishbone diagram will be:

  • Comprehensive: A good fishbone diagram should cover all potential causes for the problem at hand. It can be used to brainstorm potential causes and then whittle them down to the most likely ones.
  • Inclusive: All team members should feel like they’ve had a chance to contribute. This means that you need to have a good mix of people from different departments with different areas of expertise.
  • Organized: The layout of a fishbone diagram is typically organized in a way that makes sense, with related causes grouped together. This makes it easy to see how different factors might be linked to the problem at hand.

Start by gathering your team together and brainstorming the different areas that could be causing problems. Once you have a satisfactory list, you can start to fill in the details for each field.

Be sure to encourage everyone to contribute, even if they don’t think their ideas are “good enough.” The goal here is to generate as many potential solutions as possible. Then, you can sort through them to find the best ones.

When you’re ready to start filling in the diagram, there are a few things to keep in mind:

1. Start with the problem

The head of the fish should be the problem that you’re trying to solve. This is what all the bones or causes will branch off from and is the first thing you should identify in the diagram.

What is it that’s not working the way it should? Once you have a good understanding of the issue, you can start looking for potential causes.

2. Identify the main categories

The next step is to identify the main categories that could be causing problems. These are typically people, processes, and technology. Doing this lets you see the big picture so you can have a good understanding of the issue at hand. Afterward, you can start looking for potential causes and break them down into specific actionable concerns.

When making your fishbone diagram, it's essential to start with the right categories so that all issues can be identified and properly addressed.

For example, if your team is looking to refine your marketing objectives, you can use the 4 P’s of marketing: product, price, place, and promotion. Alternatively, if you’re evaluating your company’s organizational design and overall well-being, your categories can be structure, strategy, systems, skills, style, staff, and shared values — also known as the McKinsey 7’s.

3. Break each category down into specific causes

Once you have a good understanding of the issue, you can start looking for specific causes. For each category, ask “Why is this happening?” and “What could be causing this?” This will help you dig deeper and get to the root of the problem.

Be sure to leave enough room to add more details as you go. This is a living document that will change and evolve as you learn more about the problem.

Fishbone Diagram Example

How to analyze your fishbone diagram

After you’ve brainstormed all the potential causes, it’s time to start analyzing them.

How to detect problems/bottlenecks?

Bottlenecks are areas that lack information or resources, which can slow down the process or prevent progress altogether. When looking at your fishbone diagram, pay attention to areas where there are a lot of causes clustered together. This could be an indication of a bottleneck.

To identify problems or bottlenecks, look for branches that:

  • Are longer than others 
  • Have more “leverage points” (places where you can identify potential causes)
  • Are thicker or darker than other branches

How to see where to increase workload?

If you are having trouble seeing where to increase your workload, look for the bones that have the most arrows pointing at them. These are issues that need the most attention. Then, evaluate the severity of each problem and prioritize them accordingly.

Don't forget to create a plan of action to address the root causes you have identified. This should include specific steps to eliminate or reduce the impact of these causes. Assign someone to be responsible for each step, and make sure to track progress.

Final Thoughts

The fishbone diagram is a powerful tool that can help you identify the root cause of a problem. It’s a great way to brainstorm and see where you need to do more research and action. When using this tool, be sure to keep an open mind and consider all the possible issues.

Incorporate these tips on using a fishbone diagram with GoRetro. GoRetro is an Agile retrospective tool that aids in the identification of development process pain points. Use this together with your team to hold regular retrospectives, help the team identify process improvements, and track progress over time.

About the author

Ruth Hadari
Agile Advocate, Engineering Ops Expert

Highly experienced in leading multi-organizational teams, groups, in-shore as well as off-shore. The go-to person who is able to simplify the complex. An agile advocate, experienced in all common methodologies. Responsible for the entire software development lifecycle process from development, QA, DevOps, Automation to delivery including overall planning, direction, coordination, execution, implementation, control and completion. Drives execution, and communicates on status, risks, metrics, risk-mitigation and processes across R&D.

Related Posts

Contact Us
Thank you! Your message has been sent!
Oops! Something went wrong while submitting the form.

Join thousands of companies

Start for free - update any time
Joining as an organisation? Contact sales