Today I have learned about Ishikawa diagram (AKA fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa). And I started to wonder whether it makes sense to use it to diagnose the issues related to the production of software. (I will not explain Ishikawa diagram in this post, so please have a look at Wikipedia description if it does not ring any bells for you).

I wanted to try it myself, so I choose an arbitrary (but quite common) problem – “low quality of software” – and tried to use Ishikawa diagram to find the causes.

I have to say that I’ve enjoyed this little experiment. At first I thought that I will have to modify the original categories, but after a while it occurred to me, that no major changes, but rather a refactoring of names is required (the descriptions were copied from Wikipedia article):

• People Anyone involved with the process – no need to change, there are many people-related problems in IT.
• Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws – I think the “Process” term is better suited for software development.
• Machines: Any equipment, computers, tools, etc. required to accomplish the job– I would suggest to use the “Tools” term which includes both the hardware (devs machines, CI server) and software (i.e. IDE)
• Environment: The conditions, such as location, time, temperature, and culture in which the process operates – maybe not so important in case of software development than in factories, but also worth analyzing. No name change here.
• Materials: Raw materials, parts, pens, paper, etc. used to produce the final product – this made me think for few seconds. Then I realized that the material we work is, is simply the software. I have left the “Materials” term unchanged, but other names (e.g. Application or System) would be also fine.
• Measurements: Data generated from the process that are used to evaluate its quality – hmmm…, I think that would be various metrics like code coverage etc.

So the starting point is this:

(HINT: click to enlarge)

I spent like 10 minutes drawing a diagram for a hypothetical team (definitely NOT the one I currently work with!). And this is the result.

DISCLAIMER: I do not claim this diagram to be complete, or very smart, or that it solves any real issue. This was only my attempt to see how this tool – Ishikawa diagram – could be used. Got it?

BTW. I have used XMind (free version) to prepare the diagrams. In reality that would be probably pen & paper (a very large paper!).

Here is an “overview” (with only first-level causes visible):

The beauty of electronic version is that you can hide some parts of the picture and analyze a selected branch or two. Below an example example of single category analysis in all its glory:

As you can see you go as deep as it is required to find the causes which cause other causes 🙂 “5 whys” is the technique you would probably use for this.

The whole picture could look like this (it doesn’t matter that you can’t read the small fonts, really):

Now the team could look at all the issues described and decide which of them are of the main importance (“root causes”) and should be fixed.

Yes, I like it

Ok, to conclude, I would say that I like the idea of using Ishikawa diagram for finding the major problems of software development. I could imagine a team working with this diagram.
The fact that you have 6 different categories there would make team consider a vast range of factors, which could result in finding not-so-obvious stuff. Having so many perspectives makes it harder to stop right after finding the first possible cause (e.g. someone says “it is all because testers are lazy!” and the rest agrees and the discussion is over).

So now it looks like I’m now in a “solution-looking-for-a-problem” situation. I have this nice tool (Ishikawa diagram), I have an idea what problem could be solved with it (finding most important issues for team in troubles), but I have no team that would need such analysis. 😉

And what about you?

…and maybe you have used this diagram (or a different one?) to find/solve some issues within your team? I would be happy to learn about it!
Or maybe you have your ideas about when/how to use it? Do not be shy, share them with the world! 🙂

Source file – xmind

You can download the original xmind file here.