This technique is so clear and revolutionary that I couldn’t resist the scammy post title.
Dan Milstein, Director of Product Development at Wingu, recently gave a talk about running a 5Whys session (slides at the end of this post).
5Whys is a terrific way to solve problems properly – in a way that truly prevents them from happening again. The key insight is that problems have reasons, and the reasons have reasons. If you simply address the surface problem without addressing the underlying reasons, then that problem (or a similar one) is likely to trouble you again.
5Whys is a great technique to use in Agile retrospective meetings, because great Agile teams are built through a process that continually improves itself – and 5Whys allows people to make deep improvements in their processes.
The 5Whys technique was made popular in the 1970s as part of Toyota’s very successful drive to improve the quality of their cars. The big win comes because the further you go up the chain of reasons for a failure, the more problems you solve – problems that haven’t even occurred yet. And solving problems before they occur is almost always cheaper and better for customer satisfaction than solving them after they have occurred.
In brief, the 5Whys technique involves working out the reason for a problem, then working out the reason for that, then working out the reason for that – and so on until you’ve worked through five levels of reasons.
At that point, you’ve probably reached the deep underlying problem. Fix that problem (and it may not look so much like a problem as a side-effect of an official policy) and you’ve really improved your process. Incidentally, in my experience, that fifth level of reason for a problem is almost inevitably at management or director level: there’s almost always a department or corporate policy that needs to be changed or tweaked in order for a problem (and it’s class of similar problems) not to recur.
Dan has identified three key barriers to running a 5Whys retrospective: people feel shame when they are implicated in the reason for a problem; people feel moralistic when problems are associated with mistakes made by other people; and these factors cannot be avoided because they’re part of what makes us human.
Dan’s genius idea shows us how to accommodate this natural human tendency to fall for what’s known as the ‘fundamental attribution error’. The reason Dan’s solution might be tricky to implement in some situations is because it involves a ‘non-business’ approach to running a 5Whys retrospective meeting. He says we need to use humour to circumvent our tendency to feel shame and blame. The good news is that he steps us through how to do it, giving examples you could use yourself. You start by humorously showing what the worst is that could have happened, or the dreadful things that have happened in projects. And you continue to use humour (always laughing with and not at meeting attendees) to guide the meeting through the reasons for the problem.
This method works: I’ve seen it applied (even though we may not have known that we were applying it). Dan gives a clear template for using humour to dispel blame and shame – and for creating real improvements through 5Whys retrospectives.
Genius indeed. All aboard the fail boat.