If someone pitched it to you that way, I agree that's a dramatic oversimplification -- not of causality, but of what's meant by the "Five Why's."
"Five Why's" is a tool, a reminder to separate the symptoms from <waving hands> whatever complex system dynamics that caused them. Nothing about that analysis has to be linear nor yield a single answer.
The key lesson is to never solve a problem on the same level it was created -- i.e., the symptoms. Take the time to think through the causality. If you can go five levels up/away from the symptoms and still find an actionable mitigation for a whole class of problems, great! More likely, you go up one level and at least you won't experience the exact same symptom twice.
Agreed. I think some people must take the "5" portion very literally, but that's never how I've done it.
I just recently did a 5 whys session on some production data loss. We ended up with a branching tree that had 22 items and was up to 6 items deep. In the past I've ended up with bigger and deeper ones. To me, the "5" is just a reminder to really dig.
For me it's also a practice that's most valuable when used frequently. As you see similar things crop up in different sessions, that's a great sign to dig deeper. E.g., one of the leaf nodes in our recent retro was "no official process". That's deep enough for us; we'll create an agreed process for this particular thing and put it in the wiki. But if I see that a couple more times, I'll definitely drive the cause analysis deeper.
>I think some people must take the "5" portion very literally, but that's never how I've done it.
My personal experience has been anyone taking the "5" part literally is a cargo cult 5 why'er and they will not produce anything of value from the exercise.
> The key lesson is to never solve a problem on the same level it was created -- i.e., the symptoms. Take the time to think through the causality.
An example of how to illustrate the wrong behavior is -- for software devs -- something like a null pointer dereference. I've seen code reviews where the suggested fix is simply to guard the dereference to check if the pointer is non-null. Sure, sometimes that actually is the right fix. But a lot of time - maybe even most of the time - you need to to take a step back and ask yourself why it was null, whether it should have been and what else must change if it shouldn't have.
> dramatic oversimplification
> single answer
If someone pitched it to you that way, I agree that's a dramatic oversimplification -- not of causality, but of what's meant by the "Five Why's."
"Five Why's" is a tool, a reminder to separate the symptoms from <waving hands> whatever complex system dynamics that caused them. Nothing about that analysis has to be linear nor yield a single answer.
The key lesson is to never solve a problem on the same level it was created -- i.e., the symptoms. Take the time to think through the causality. If you can go five levels up/away from the symptoms and still find an actionable mitigation for a whole class of problems, great! More likely, you go up one level and at least you won't experience the exact same symptom twice.