I have recently been pointed to a great blog called Startup Lessons Learned. There are some great posts on product development, Agile practices, hiring practices and tips, and TDD, some of which have made me rethink how I go about my day and the practices I employ. I highly recommend giving it a look.
There were a couple of posts on a practice called the Five Whys, which comes out of Taiichi Ohno’s book Toyota Production System. The first post is about the Five Whys and what they are meant to accomplish, and the second is on how to actually run a Five Why’s analysis meeting.
I am very eager to start applying this technique. I am fortunate enough to be working on a really great team that has the maturity to avoid turning the five whys into a blame game. I am sure it will take some practice, but I am interested to see what comes out of it. If anyone has used this technique and has advice or stories to share I would like to hear them.
I’ll let you know how it goes.
Old Dog, New Tricks 
It sounds like Taiichi Ohno got his idea from his kids. “Why is the sky blue?” “Why does our dog wag his tail?” etc
The Five Whys makes me think of another process which was intended to improve quality….checklists! In the past, I’ve had a horrible experience with overkill checklists. Even The Daily Show entertained a guest who wrote a book on the subject. http://www.thedailyshow.com/watch/wed-february-3-2010/atul-gawande
I would like to hear more about your experience and if it works, but my first assumption is that this is just adding another meeting and another layer of process which hurts startups. In an Agile environment, I wonder if you can bake this into a retrospective instead of having a separate meeting. The other issue I see, especially with startups, is how do you commit to fixing the problem? In the link posted, the root issue came back to training new hires, and I think that’s something very difficult for a startup to accomplish because they are more concerned with getting something prototyped or out the door quickly as opposed to building infrastructure for new employees.
More recently I’ve had the experience of going through one of these “What went wrong meetings” and it was made a point to not blame each other. Inevitably when different groups or departments were involved, that’s what it boiled down to… a blame game, which hurts the team philosophy in my opinion.
Long story short, I am curious to hear how others have experienced the process and if it’s value is worth including.
Thanks for your input.
Although I think retrospectives are useful (see https://mdenomy.wordpress.com/category/retrospectives/), one reason that I would not want to push this off to a retrospective is that I would want to take action when the crisis/problem is still fresh in everyone’s mind. Also this type of a meeting may require a different set of people into the room than a normal retrospective. It is an interesting idea though, and depending on your development/retrospective cycle it would be possible to address the issue in a retrospective. The key to both types of meetings is to take action after the meeting.
As to your point about committing to fixing the problem, if you don’t have someone leading the meeting who has the authority to effect change and assign actions across the organization then I would agree that the meeting is probably not worth having. That doesn’t mean the CEO has to run the meeting, but the organization needs to support the outcome and actions. That is a significant concern.
You are correct, Agile is about getting things out the door and having a lean process, but it also is about changing that process to be efficient. That is why we do things like automated testing, continuous integration, etc. Those take work to implement, but in the long run make for a responsive, streamlined system.
In the link’s example, the training was an issue that was repeatedly causing problems and something had to be done. That may not mean implementing a full-blown, week-long class right off the bat. Maybe it starts out as a wiki of common problems and issues, assigning mentors to incoming employees, etc. An incremental improvement in the process will not solve everything, but it will pay dividends.
Blame is a tricky one. The organization and team has to be capable and respectful about “naming names”, but only if it results in solving problems and correcting behaviors. I have been in similar meetings that you describe where the purpose is just to assign blame. They are no fun and don’t serve a useful purpose to make actual change.
Thanks again for your thoughtful response.