[sturadnidge]

As much as I agree with the general message (nobody died, so it's not _that_ bad), and have employed that same technique over the years, the part about root cause is off point IMHO.

'Root cause' can absolutely refer to a collection of events. In the example given, clearly both things were causal, clearly you fix both - you don't pick one and label it 'THE root cause' and forget about the other (yes I know he talks about prioritisation, but again that's perfectly valid when addressing a root cause that happens to be a collection).

[danmil]

Heya, author of the slides here.

Re: 'root causes' -- I find the words somewhat important. Like, if you say you're looking for a root cause, then people tend to be in the sort of moral mindset, and have a harder time seeing it as a collection of contingent events.

Also, in the (truly amazing) "How Complex Systems Fail", he's pretty down on "root cause":

http://www.ctlab.org/documents/How%20Complex%20Systems%20Fai...

"7) Post-accident attribution accident to a ‘root cause’ is fundamentally wrong"

[wpietri]

I'm with you on this one. Especially in an iterative context, there is zero value in looking for the true root cause.

The point of the exercise is to identify economical interventions that will get the system to produce better results. If you go much beyond that, people can get off into moral, analytical, or philosophical weeds and get lost.

As long as you do retrospectives and five-whys frequently, you can count on useful analytical depth to come over time. If an issue is really both important and subtle, it will crop up again. The next time you'll have another perspective, so it will be easier to find. And by waiting, you'll have avoided examining all the equally subtle but unimportant things.