In the Privacy of Your Own Thoughts

Behind the scenes of The Art of Agile Development's Root-Cause Analysis practice.


"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 Art of Agile Development:

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.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.