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

5

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 way that’s easier to adopt:

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.

Add comment

alexbolboaca.ro Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: https://codedesigner.eu. My plan is to add more blog posts there, and to involve other people doing work in this area.