Determining root cause of a problem and solve the root cause rather than symptoms is one of important principles of Lean methodology. I have been in situations where we do not have time to determine root cause, so we waste our time just solving symptoms of a problem. I am sure many of you have been in this kind of situation. Unless we solve root cause of a problem, the problem will keep coming back. So it is important for us to determine root cause of a problem and solve it instead of solving symptoms. How do we determine root cause? Lucky for there is a simple technique to determine root cause of a problem.
This technique is called "5 Whys". The technique is to repeatedly ask "why" till we find root cause of a problem.
It is easy to explain with an example.
Problem: QAs take lot of time to test application.
1. Why are QAs taking lot of time to test application?
- Because they find so many bugs in application. They have to wait for developers to fix those bugs, so they can retest.
2. Why are QAs finding so many bugs in application?
- Because the application has lot of bugs.
3. Why is application having many bugs after development is done?
- Because developers did not find these bugs when developing application.
4. Why developers did not find all these bugs during development?
- Because they do not have enough unit tests.
5. Why developers did not write enough unit tests?
- Because developers did not do Test Driven Development.
You can see that QAs taking lot of time to test is not the real problem, it is just a symptom. After applying 5 whys technique we found the root cause of that problem is developers are not doing test driven development. In fact we can repeat why questions some more time to make sure it is root cause.
6. Why developers did not do Test Driven Development?
-Because they don't know how to do Test Driven Development.
Now we have determined the root cause of our problem. It is not QAs taking lot of time to test. It is developers do not know how to do test driven development.So instead of adding more QAs to reduce testing time, we should train developers how to do test driven development.
Friday, January 23, 2009
Determine root cause of a problem
Subscribe to:
Post Comments (Atom)
5 comments:
I'd also go a different branch
6. Why don't the developers do TDD or some other method to prevent defects?
- Because they don't see it as their responsibility to prevent defects
7. Why don't the developers see it as their responsibility to prevent defects?
- Because the overall team does not know the difference between Quality Assurance and Quality Control
Yah Jason that is another possibility. I wrote that as an example :)
Short and sweet but I belive that this "5 Whys" was written with the last two points "decided" from the start. I've seen too many exercies like this turn end with what the facilitator thought we should be doing all along or always end up with "blame management/customer".
4. Clearly identifies lack of unit tests as a cause but wouldn't a comprehensive acceptance test suite also fix the defect as this level?
Or simply concluding "development does not take responsibility for shipping bug-free code to testing".
In the later scenario we would probably end up with Jasons #7 developers don't see it as their duty to prevent defects as a root cause and hopefully that could spur a discussion amongst them. Leading to some solution to fix that, probably some sort of test automation. And there TDD could be introduced as one way to fix the problem. Tooling or lack-of-using-practice-x is almost never the problem, they can be the solution though.
Torbjörn I accept to what to say. I wanted to give an example how to use 5 whys.
I really like your point "Tooling or lack-of-using-practice-x is almost never the problem, they can be the solution though." It is well put.
Thanks for your input
5 Whys work well when we understand the problem space well or the problem space is simple. Otherwise, something like a fishbone diagram might be more effective. For really complex problems, Current Reality Trees may be the way to go.
Post a Comment