One thing that virtually every company on the planet has in common is that mistakes happen. An inventory order gets jumbled. An email was sent to the wrong recipients. A sales pitch gets botched. The list goes on. But another thing that virtually every company on the planet should have in common is the drive to learn from mistakes. Here at Kashoo, we use a methodology called 5 Whys. Originally born out of Toyota and mainstreamed by Eric Ries in The Lean Startup, the 5 Whys “is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.” (source) The name hints at the defining characteristic of the technique, when you ask why something happened you don’t settle for the first answer but instead you ask ‘Why?’ again. And again. And again. Maybe five times or maybe more. Until the team feels they have uncovered the true root cause. So here at Kashoo, when we encounter any event that we feel didn’t go as well as it could or should have anyone on the team can call for a 5 Whys. It is critical to iterate here that a 5 Whys is not a session to place blame. It is a session to dig deep and really understand why something happened the way it did. As Eric Ries so eloquently explains, “it’s about uncovering the human problem that underlies every seemingly technical problem.” But just to make sure we’re on the same page about not placing blame we start by citing Norm Kerth’s Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” From there we’re ready to dig in and learn… Here’s How Our 5 Whys Run A 5 Whys Master is chosen to run the session. (It’s helpful if this person wasn’t too heavily involved in the event so they can focus on the process thus allowing the folks who were involved to focus on asking and answering “why.” The context is presented by stepping through the sequence of events during the incident. For significant events we ask “Why?” Then we follow up the answer to that “why?” with another “why?” This process gets repeated five times. Lastly, we identify actionable tasks that can prevent each why from happening again. As a result of the 5 Whys session captured on the whiteboard pictured above (hey, who said developers had legible handwriting?), we uncovered a clear list of tasks which address technical issues and communication within Kashoo. This session also nudged us further along a path we recently started called ChatOps. But that’s a topic for a future post!
