How to do a Ishikawa Diagram in Software Development

How can we use the Ishikawa (Fishbone) Diagram in Software
Development. Here´s a summary.

Ishikawa-by-nathalie

The Ishikawa diagram

Fish Bone Analysis For Root Cause Analysis in Software Testing

Very nice paper giving hands-on and step by step advice on how to do a root cause analysis using the Ishikawa diagram.

When to use Ishikawa diagram

  • Focus attention on one specific issue or problem
  • Focus the team on the causes, not the symptoms

Step by Step Guide to do an Ishikawa Analysis

Step 1 – Define Topic

  • Identify and clearly define the outcome or effect to be analyzed
  • An effect may be positive (an objective) or negative (a problem)
    Focussing on a …
    … positive effect —> focuses on a desired outcome —> fosters pride and ownership over productive areas
    … negative effect —> can sidetrack the team into justifying why the problem occurred and placing blame

Step 2 – Draw the Fish

  • Draw the fishbone and create the effect box

Step 3 – Major Branches

  • Identify the main causes contributing to the effect being studied —> major branches

Step 4 – Sub-Brances

  • For each major branch, identify other specific factors which may be the causes of the effect

Step 5 – 5 Why´s

  • Identify more levels of causes using the 5 Why´s

Step 6 – Conclusion

Analyze the diagram:

  • Use a Pareto Chart to prioritise potential causes.
  • Look at the “balance”, repetition of causes, potential for consolidaton, quantification of effects.

Source: Fish Bone Analysis For Root Cause Analysis in Software Testing

Ishikawa Diagram in Software Development

How can we use the Ishikawa diagram in IT or Software Development? Here are a few resources than can help.

Examples

Ishikawa-example

Source: Fishbone diagram for software defects

ishikawa-low-developer-velocity

server-procurement-takes-too-long

Source: How to apply cause and effect diagrams in IT and Software Development

Generic Branches

This article explains how the generic main branches (that we usually find in description)can be interpreted in a software project context: Method, Man, Management, Measurement, Material, Machine

ishikawa-generic-brances

Source: Ishikawa or Fishbone Diagram

Branches for Software Development

The generic branches will sometimes to fit our purposes. This articles suggests using specific sets for software development projects:

Varian 1:

On IT projects these are good starting points for causes (MVPS):

  • Material (includes hardware and software)
  • Vendors (such as hardware/software vendors)
  • People (your team members, coworkers and other stakeholders)
  • Systems (used to control and manage IT functions)

Variant 2:

For software development projects, this set of common causes is solid foundation to investigate (MCPS):

  • Method (include software development life-cycle, QA process, agile methodology, SCRUM methodology, Waterfall)
  • Code (the source code and related artifacts such as packages and libraries and frameworks)
  • People (your team members, coworkers and other stakeholders)
  • Systems (the systems used for development, releases, deployments, testing)

Source: How to apply cause and effect diagrams in IT and Software Development

Ishikawa for Risk Analysis

The Ishikawa diagram can also be used for risk assessment for example by Testing Experts or QA members.

We can use this tool to explore risks as well. We will explore what happens (cause) and how it will impact (effect) our project and product. In this regard this tool works also as a proactive exploration rather than the typical use of tracing problems that are already visible.

Source: Ishikawa (Fishbone) Diagrams And Risk Management

ishikawa-riks-example

Source: Risk Assessment Using a Fishbone Diagram


See also: More Agile Testing by Janet Gregory and Lisa Cripsin

More

Synonyms: Cause and Effect Diagrams, Fishbone Diagrams, Ishikawa Diagrams, Herringbone Diagrams, and Fishikawa Diagrams

This blog is a digital memory for me. I store nuggets of information, ideas and resources on these pages so that I can access and share them easily at any time, from everywhere. I always felt a strong passion for continuous improvement and that is why I am now super happy to be a professional Scrum Master. Scrum, Kanban, Agile Project Management, Coaching, Learning and Self Management are my passions and that is also what my blog is about ...