8D (Eight Disciplines Problem Solving) is a powerful problem-solving tool developed by Ford Motors. The main purpose is to identify, correct and eliminate the root causes of the problems through corrective actions. Now 8D method is used not only in the automobile industry, but in all areas where Quality Management System (QMS) is implemented. We use the 8D method for problem analysis that occurs during the software development process. Let’s look at our example of using this technique for the problem: «Too much regression bugs».

What we should remember

The first rule of quality management system implementation is engagement of managers in all levels. The second sounds like «we should not find a guilty person,  we try to find problems in process». And the third,  the product Team should have the opened mind for understanding, adopting and using the QMS tools.

8D. Step 1. Team Formation

It is necessary to form your Team by members with sufficient product and process knowledge. Also the Team members  should  have the ability to make decisions and carry out the required activities. In our case,  Team consists of developers, analysts, testers, managers.

8D. Step 2. Detailed Problem Description

Next step: detailed problem description using problem clarification. We use 5W2H method (MindMap)

1. WHO. Who discovered the problem?  The testers.
2. WHAT. What is the problem? Too much high priority regression bugs. Much more than during testing the iteration User Stories.
3. WHEN.  When was the problem detected? The problem was found during the regression testing of 14 Iteration.
4. WHERE. Where was the problem detected? All regression autotests was crashed and all manual test-cases had a first/second steps problem.
5. WHY.  Why is this a problem? Because we delayed in the product release and the stakeholders did not receive the required functionality in time.
6. HOW.  How was the problem discovered? During the regression testing and analyzing the bugs queries in TFS.
7. HOW MANY. What is the problem scale? In this case, this item is empty, since the stakeholder receives the software with a single assembly.

As result we have the detailed  problem description: regression testing (main scenarios) is carried out in the end of 14 iteration (before the release), a large number of regression bugs with high priority and severity lead to delay in product release, because the basic customers scenarios do not work correctly.

8D. Step 3. Interim Сontainment Action

It is necessary to carry out containment actions, that will not allow the present problem to spread. In a particular case: the containment actions can solve the problem. Unfortunately, in common way Systematic Problem Solving stops on this step. Our containment actions: all developers fixed the regression bugs, analyst helped the resters to retest bugs.

8D. Step 4. Root Cause Analysis

Thanks to a detailed description of the problem through 5W2H, we get a more detailed representation of it in comparison with the original (MindMap). For Root Cause Analysis we use the Ishikawa diagram (Fish Bone) and «5 Why » method.

Using Fish Bone

For Fish Bone method we lead a brainstorming session and identify all the possible causes of the problem. Answer by question: Why did it happen? For all possible causes you can use most deeper analysis (we use mind map to write the results). The main aim: to find root course and further solution. After all possible reasons were considered, you need to prioritize high likely causes for next analysis («5 Why » method). The results of our brainstorm you can see there:

 

We decided that the most possible cause is «testers do not have feedback from developers«.

Using 5Why

For this cause we use «5Why» method. The main aim is to determine the root cause of a problem by repeating the question «Why?» Each answer forms the next question. To search the root cause, you do not have to answer all 5 Why, sometimes its can be less or more. If the analysis did not show a sufficient result, use the next FishBone possible cause. If all efforts have been in vain, try to change your mind and fill new FishBone, try to find out possible cause that were not taken into account earlier. Despite the fact that «5 Why» applies to the most possible cause, pay attention to the others and create a strategy for working with them. Often they help to identify problems in the process, not just about the current problem. In addition, you can invite not 8D Team members, for «outside view».

WHY1: Why testers do not have a feedback from developers. Answer 1: Lack of developers’ time.

WHY2: Why does Lack of developers’ time exist for feedback. Answer 2: Such activities do not estimate in US story points

WHY 3: Why do such activities not estimate in US story points. Answer 3: Because such activities are not considered labor-intensive

WHY 4: Why are such activities not considered labor-intensive. Answer 4: because its percentage are considered as low

WHY 5: Why are its percentage considered as low. Answer 5: because quantity of requests from stakeholder was forecast as low

Congratulations! We find Root Cause: quantity of requests from stakeholder was forecast as low. Find MindMap there.

8D. Step 5. Corrective Action

We formulate a list of corrective actions. The aim is to eliminate the identified root cause. All proposed corrective actions should be initially analyzed, including taking into account the risk of new problems.

Corrective actions in our case: we decided to create a buffer User Story (about 1/5 of story points of iteration) for new tasks according Stakeholders requests.

8D. Step 6. Validate Corrective Actions

At this step, you need to make sure that corrective actions have been effective. At 100% efficiency, these corrective actions will replace the containment actions of step 3.

Now it is the second iteration with such US. Previous was fine!

8D. Step 7. Identify & Implement Preventive Action

This step applies as to the current project and as others. For others projects we add buffer US in iteration.