5 Whys Shouldn’t Be 5 And Shouldn’t Be Whys

Romanians have a class of jokes called “Radio Yerevan” jokes. My favourite one is:

Is it true that Ivan Ivanovich Ivanov from Moscow won a car in a lottery?

A: In principle yes, but:

  • it wasn’t Ivan Ivanovich Ivanov but Aleksander Aleksandrovich Aleksandrov;
  • he is not from Moscow but from Odessa;
  • it was not a car but a bicycle;
  • he didn’t win it, but it was stolen from him.

I realized that the same happens with the rule of 5 whys.

This rule states that to find the root cause of an issue in a team you have to ask five times “Why?”. This technique is part of lean methods and was initially used as part of the Toyota manufacturing system. It was then adopted as a tool for agile coaching.

This rule is however a lot like a Radio Yerevan joke. It is very useful but:

  • You shouldn’t ask why because it’s annoying and puts some people in a defensive stance
  • You shouldn’t ask 5 questions because it might be too much or not enough

My rule is that I ask context-free questions until I am satisfied I understand the problem.

The best resource I could find for context-free questions is the CIA “Phoenix” checklist. I recommend this list to everyone who needs to find solutions to a problem. It’s amazing how it makes people move around a problem and understand what they are missing. Some of my favourite questions from the list are:

  • Why is it necessary to solve the problem?
  • What isn’t the problem?
  • How many different ways have you tried to solve the problem?
  • How will you know when you are successful?

The second part of the rule is more subjective and requires experience. JB Rainsberger taught me another, easier to adopt way:

Ask questions until your interlocutor starts thinking

So here it is, use the 5 whys rule but don’t ask why and don’t ask it 5 times. Everything else should be fine.

Published by

Alexandru Bolboaca

I like to develop software, and my history shows that I do it well. I've learned it in a real project, with a mentor who slapped my hand whenever I did something wrong. I've tried to continuously improve myself and thus choose to walk the software craftsmanship path. I like to teach people how to program better and to work side by side with them to build innovative software or solve "impossible" problems while also leveraging their potential. I do not have all the answers, but I like to find the good ones with the help of a team. Currently I am working with MosaicWorks at developing the agile and software craftsmanship groups in Romania. Details of this activity are available on www.agileworks.ro I also help organizing the local agile conference - www.openagile.ro I also provide Unit Testing and Test Driven Development trainings, help groups solve their problems using value stream mapping, do technical coaching and pair programming and others. I've learned many of these techniques by practicing and discussing with much more experienced people, like JB Rainsberger, Corey Haines, David Hussman etc..