I'm proposing we try out the Five Whys process at work. The primary goal is to determine the root cause of a problem by repeating the question "Why?". Each answer forms the basis of the next question. The "Five" should not be taken literally, keep asking why until you uncover the root cause.
The method provides no hard and fast rules about what lines of questions to explore, or how long to continue the search for additional root causes. Even when the method is closely followed, the outcome still depends upon the knowledge and persistence of the people involved.
It's important to note that the purpose of Five Whys isn't to place blame, but to uncover the root cause of the problem. To create small, incremental steps so that the same issue doesn't happen again. Our bias as developers is to over-focus on the technical part of the problem; Five Whys tends to counteract that tendency. What started as a technical problem often turns out to be a human and process problem. Sometimes a solution may cut across several departments ... requiring the support of someone with authority to change process at that level.
I'd like to learn from your experiences with Five Whys. Has Five Whys been tried in the Perl or Open Source world? Have you tried it at work? How did it go? What did you learn?
Proposed Five Whys Process
As advised by Eric Ries (see References below), at least for a trial period, all Five Whys meetings will be run in the same way, by the same "Five Whys Master". We'll continuously adapt our use of Five Whys, based on our experiences. Note that Five Whys is a technique for continuous improvement, and can therefore be applied to itself.
Loosely based on Ries' advice, this is the proposed Five Whys process:
Commit to make a proportional investment in corrective action at every level of the analysis. These small investments cause the team to go faster over time. Proportional means not to over-react to problems; a ground-up rewrite is not always required. Though the Five Whys Master leads the discussion, others assign responsibility for the solution to anyone in the room. The analysis should propose solutions, aka corrective actions. For each solution, ask "how will this solution prevent the error from occurring again?". Each corrective action is marked as must (mandatory), should (strongly recommended), or may (use discretion, depending on time and resources); periodically after the analysis is published, track which corrective actions have actually been implemented (this metric will be used to tune our Five Whys process). The results of the Five Whys analysis is shared with the whole company. The solution is in plain English that anyone can understand. Each Five Whys analysis is a teaching document.
Fishbone (aka Ishikawa) diagram
There may be many opinions of root cause. The fishbone visually displays many potential causes for a specific problem. Because people by nature often like to get right to determining what to do about a problem, the fishbone can help bring out a more thorough exploration of the issues behind the problem - which leads to a more robust solution. To construct a fishbone, start with stating the problem in the form of a question. Each root cause idea should answer the question.
The rest of the fishbone consists of one line drawn across the page, attached to the problem statement, and several lines, or "bones", coming out vertically from the main line. These branches are labelled with different categories; the categories are up to you to decide, for example: Four Ps (Policies, Procedures, People, Plant/Technology); Six Ms (Machines, Methods, Materials, Measurements, MotherNature, Manpower).
The team should agree on the statement of the problem and then place this question in a box at the head of the fishbone. The defect is shown as the fish's head, facing to the right, with the causes extending to the left as fishbones; the ribs branch off the backbone for major causes, with sub-branches for root-causes, to as many levels as required. One or two of these "causes" will have a greater effect than the others and will guide you to the root of the problem. This structure allows you to tackle smaller chunks which have a large impact on the problem. Looking at elements of the problem and not the whole process will likely make finding your solution less daunting and problem solving more manageable. Screen your causes as described above. Focus on causes with result VV, VS and SV.
Typical Software Problem Categories
I couldn't find much specific advice on applying Five Whys to software problems - if you know of good references, please let me know. Examples of typical software problems can be found at: Common Software Development Mistakes. As for categories of typical software problems, perhaps:
|Replies are listed 'Best First'.|
Re: Five Whys
by Ratazong (Monsignor) on Oct 29, 2018 at 13:40 UTC
Re: Five Whys
by reisinge (Hermit) on Oct 29, 2018 at 11:16 UTC
Re: Five Whys
by Anonymous Monk on Oct 30, 2018 at 08:12 UTC