More than the 5 whys?

Sakichi Toyoda (of Toyota fame) developed a problem-solving method that will sound familiar to parents: repeatedly asking “why?”. However, unlike most kids, Toyoda believed that asking ‘why?’ five times led to an understanding of the problem and a solution. People often try to solve problems by addressing causes presented to them; the ‘5 whys’ helps you drill down into the problem so that you address the root cause, rather than symptoms.

For example:

• Users don’t like the homepage. Why?
• They can’t find what they are looking for. Why?
• The page has too much content. Why?
• Multiple departments demand their content be on the homepage. Why?
• No single person or team decides what goes on the homepage.

In this example, if we stopped at the first answer, we might get demands to add call-outs to key areas  … followed by more and more call-outs being added when one department feels another is taking the limelight. The second answer might make us slash content from the homepage … resulting in angry calls from departments blaming us for a slump in sales. And so on. But, by continuing to press for answers, we can get to the root cause and, in this case, get the business to decide who should be in charge of content on the homepage and make business decisions to solve the problem.

Problems. Why?
However, there are quite a few critics of the method. Here are a few of their points:

• The method only produces results based on the knowledge held by the parties involved. If I don’t know ‘why’, then I might guess the reason and steer us down a wrong path. “Users can’t find what they are looking for because … er … there isn’t enough content on the homepage”
• People don’t get to the root cause, but stop at a symptom; they stop at the fifth why, when they need six or seven or more to get to the real problem. It’s sometimes difficult to get to know when you are really at the root cause.
• You often end up focusing on a single cause, when often there are multiple, inter-woven, complex reasons. For example, users can’t find what they are looking for because of a poor search facility, bad design, code conflicts, dead links, etc.
• The results vary depending on who answers the questions (i.e. different people will lead you in completely different directions).

Lowe’s 4 whys
When I first heard of the 5 whys, I had no idea of its simplicity. I envisaged 5 specific why questions. I thought they might be:

1. Why does the business want the piece of work done?
2. Why has it not been done before?
3. Why are we doing it now/Why can’t it be done later?
4. Why isn’t someone else doing the work (i.e. a different team)?
5. Why can’t users currently do this on the existing system (i.e. is there a workaround)?

Although I was wrong in my understanding of the method, it has made me think that we should all be asking more questions. As agile teams focusing on delivering value regularly, we should be querying the value, order and validity of requests that come in. Remembering that what people ask for might not be what they really need, if we combine these two approaches, we can understand the root reason for the requests coming in and find out if there is a simpler solution for us to give them what they need.

“Why” is certainly a powerful tool. The question is “why don’t we use it more often?”