Design a site like this with
Get started

Use a cause-and-effect diagram to achieve consensus when defining quality

When I gave the talks on “What is quality” I found it was not possible to provide a definition of quality on which everyone would agree. I recently read a book by Kaoru Ishikawa which included him describing quality using a cause-and-effect diagram[1].  It occurred to me that using a cause-and-effect diagram to describe something on which people have different opinions could be a way of building consensus. The effect the diagram was describing was quality and the causes the diagram showed were the causes of quality. This type of diagram is known as an Ishikawa or fishbone diagram. An illustrative example cause-and-effect diagram is at the top of this post. 

It can be difficult to achieve a consensus can when defining quality. It can be that some team members have definitions of quality that they believe are true. Differences of opinion over definitions of quality can make discussion difficult and this may make it hard to gain agreement on a form of words to define quality.

If a cause and effect diagram is used to define quality then you can use the diagram to create consensus on what quality is. It could be that even if people disagree on the words that they use to describe quality when they add items to a diagram there is agreement on the items they add. A facilitator can then use this as a way to create a consensus. 

The first step in creating a cause-and-effect diagram is to define the effect for which causes are to be identified. In this case, this is “Quality”. The name “Quality”  should be placed in the box on the diagram. Each of the causes of quality can then be placed in a box off the spine of the diagram. Subsidiary causes can be added as branches of the causes that have already been defined.

If people break down the ways to describe quality to specific items such as the use of continuous integration, they can add the items to the diagram as causes of quality. The creation of the diagram could start by adding those causes of quality on which everyone agrees. It could be that the group want to add code reviews as a cause of quality and this can be added to the diagram. Once items that everyone agrees on have been added the group can discuss adding other causes on which they do not agree. This process narrows down the areas of disagreement.

Defining quality is important because if you can not define quality then how can you achieve quality? Using a cause-and-effect diagram to define quality could be a way to create a consensus on an important subject. 


[1] What is Total Quality Control The Japanese Way by Kaoru Ishikawa (1985, p47)


Published by Mike Harris

Mike has been working in testing for 20 years and is the lone tester for Geckoboard. He has been a Test Lead and has also worked as a part of waterfall, lean and agile teams. He has a B.Sc.(HONS) from Middlesex University and is an Associate of the University of Hertfordshire. He has set up and led a Testing Community of Practice and been part of a successful agile transition. He is Vice-Chair of the British Computer Society’s Specialist Interest Group in Software Testing. He also contributed to the e-books Testing Stories and How Can I test This? and has had articles published by the Ministry of Testing, LambdaTest and The QA Lead.

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: