The Five Whys
I've been reading a book called the Lean Startup recently. It is filled with great advice and the Lean Startup is basically a business approach that aims to change the way that companies build and launch new products. Whilst reading the book I came across a chapter that dealt with a technique called the Five Whys. This technique instantly piqued my interest as it is relates quite closely to problem solving in a product development environment.
The Five Whys technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a methodology that allows us to get to the root cause of a problem. The system takes its name from an investigative method of asking the question "why?" five times in order to understand what has happened. In theory this sounds simple, but putting this into practice is a lot harder than it sounds. By systematically going through a problem five times, you force yourself to get to the real root cause of the problem.
An example of how this could be applied to a software development process may look something similar to the following:
- Why did the signup form fail? Because the API returned an error.
- Why did the API return an error? Because the email address wasn’t being validated and caused the API to fail.
- Why wasn’t the email address being validated? Because we didn’t think it was necessary.
- Why don't we have email validation in place? Because we rushed to get code out and didn't think we needed it.
- Why are we releasing code on a Friday night? Because there is no policy in place that says that we can't.
If this systematic procedure of asking "why" five times wasn't done, we wouldn't have gotten to the root cause of the problem. We might have just fixed the signup form and not the root cause of the problem. There could be a number of reasons why a development team may only look at the initial issue instead of the root cause of the issue, but by using the Five Whys you are ensuring that nothing slips through undetected. At each stage of the Five Whys, you are also able to identify different actions that need to be done in order to fix the problem.
The Five Whys doesn't only relate to software development, it can be applied to all manner of issues that need resolving. In fact, the National Health Service in the United Kingdom actually use this technique when dealing with hospital issues. A key phrase to keep in mind in any Five Why exercise is "people do not fail, processes do". You will often find that the root cause of the issue can be resolved by a simple change in process. The Five Whys can act as a powerful feedback loop. By simply making small adjustments to your processes and revisiting them with the Five Whys, you can ensure that little by little, large problems are resolved at the root cause.
I have only given a brief summary on the Five Whys, but for more information check out the book - The Lean Startup or for more information take a look at this article. The next time that an issue affects your team, I recommend that you give the Five Whys a try!