James Shore

in 99 words

When mistakes occur, blame your process, not people. Root-cause analysis helps. What allowed the mistake to happen? What will prevent them in the future? Assume people will continue to make mistakes and build fault-tolerance into your improvements.

One approach: ask "why" five times. Use it for every problem you encounter, from the trivial to the significant. You can apply some solutions yourself. Some will require team discussion, and others need coordination with the larger organization.

When mistakes become rare, avoid over-applying root-cause analysis. Balance the risk of error against the cost of more process overhead.

as haiku

a slug eats dessert...
making lattice from lettuce,
she thins the surplus

Inside This Section

• Root-Cause Analysis
• How to Find the Root Cause
• How to Fix the Root Cause
• When Not to Fix the Root Cause
• Questions
  • Who should participate in root-cause analysis?
  • When should we conduct root-cause analysis?
  • We know what our problems are. Why do we need to bother with root-cause analysis?
  • How do we avoid blaming individuals?
• Results
• Contraindications
• Alternatives

Commentary

"Aren't you being a little... self-centered?" Rob asked. Rob's a good friend of mine. "Shouldn't root-cause analysis be a team discussion?"

"Huh... what?" I riposted eloquently.

"In your book. When you're talking about who should do root-cause analysis. What about the rest of the team?" He showed me the section, on page 89 of the book:

Who should participate in root-cause analysis?

I usually conduct root-cause analysis in the privacy of my own thoughts, then share my conclusions and reasoning with others. Include whomever is necessary to fix the root cause.

I had to pause. It was an entirely reasonable question, and the obvious answer was yes... absolutely yes. In agile development, we celebrate the team over the individual. Root-cause analysis should take place in team discussions.

But that isn't what I actually do! Shane and I drew the advice in the book from our own extensive experiences, and that's where that quote had its origin. When I do root-cause analysis, I generally do it in the privacy of my own thoughts, then discuss the results with others. Does that mean that I don't really value team input? Am I really a cowboy coder in denial?

I have to admit, the thought disturbed me for a moment. And then I realized: root-cause analysis is nothing special. It's a tool you can use whenever you see a problem of any sort, from the trivial to the terrible. And I don't know about you, but I see problems everywhere. It's the nature of our business. There's no such thing as perfection in software.

So I keep my brain switched on at all times, and apply root-cause analysis all the time. Whenever I see a problem--and if I'm programming, that happens several times per hour--I ask "why" and try to get to the root-cause of the problem. (I have to admit, pair programming helps immensely, by giving me free time to do so.) If I stopped to involve the team every time I did root-cause analysis, we'd never get anything done.

So, sure, involve the team in root-cause analysis during your retrospectives or team discussions. But don't let it stop there. Keep your brain switched on. Apply root-cause analysis all the time.