The Five Whys and Continuous Improvement

At HubSpot, we've big believers in continuous improvement.  We hire stellar people, but no one is perfect.  No team is perfect, nor any process, nor any piece of code.

One of my favorite things about Scrum is the end-of-sprint team retrospective.  Each Scrum team meets, just the pigs, in private.  They spend a little bit of time (or as long as they want) talking about what worked well, what didn't, why things worked (or not), and how to make it better next sprint.  The outcome is a set of specific, concrete changes the team can try in the next sprint.

The Five Whys is a closely related concept.  It's also about continuous improvement, one form of which is called Kaizen, from the Japanese word.  I first learned about the Five Whys in graduate school, but then was reminded of it by Eric Ries, in his excellent Startup Lessons Learned blog.

The Five Whys is a fairly quick, transparent, and efficient way to do root-cause analysis.  At HubSpot,  the dev team does this for really serious bugs.  It typically takes 30-60 minutes, and the outcomes is always satisfying.  This works well for me, since I'm not a fan of long meetings and process just for the sake of process.

One thing we believe is that "people need to be smarter" is not acceptable outcome or improvement.  People will always make mistakes.  No one is perfect, no code is perfect, no process is perfect.  It's all about making things better and preventing future errors at every level.

In the future, we might start sharing the result of Five Whys analysis here.  We may not be able to publish every single detail, because some data is customer-specific and thus confidential.  But we'll try to be transparent about the process, the problems, our findings, and related metadata.

Would you find that interesting or valuable? 

Do you or your company practice this sort of analysis? If so, have you found that it's worth the time?

Do you know anyone who's sharing their problems and findings in public like this?