When moving fast, breaking things, and concentrating on short sprints, it’s easy to focus on one fire after the next. Stopping to examine the root cause of failure or other unexpected outcomes is sometimes avoided in favor of the speed of productivity. The 5 Whys approach is an iterative, interrogative technique to explore the cause-and-effect relationships underlying a particular experience.
Recently, the implementation team at Revelry participated in a Blab session to chat about applying the 5 Whys framework within a startup environment. Here’s some takeaways from the event, which the team has further expanded upon.
Ask “Why?” Five Times
To determine the root cause of an effect or problem, the 5 Whys approach encourages a deep dive by simply asking “why” to the answer of a succession of questions. Instead of simply identifying a result and resolving to “Don’t let that happen again,” the answer to each question becomes the next question.
Upon answering the fifth question, a plan of action for future processes can often be reached.
Problem: The vehicle won’t start.
Q: Why won’t the vehicle start?
A: The battery is dead.
Q: Why is the battery dead?
A: The alternator isn’t functioning.
…And so on, until it’s found that maintaining a car according to the service schedule will prevent the alternator belt from being taxed past its useful service life. This is a much more specific plan that you can put in place through a 5 Whys approach than simply saying, “Take care of your car so it’ll start next time!”
The 5 Whys Approach as an Alternative or Enhancement to a Retrospective
An Agile retrospective is one way of looking at a sprint, whereas a 5 Whys process is akin to pulling the emergency brake on the production line.
5 Whys can guide you through a retrospective, providing a way to dissect a theory in a more thoughtful way. Often, an ill-informed theory can be created after skipping the interrogative process. But, Agile teams are often skeptical of this inquisitive process since it can feel like a personal blame game if conducted irresponsibly. If the participants actually don’t know the answers to a question, it can feel more like a “Who?” than a “Why?”.
But pulling that emergency brake, especially when moving fast and breaking things, is pretty important so that you’re not out there creating a bunch of technical debt in your code. 5 Whys are not only for technical teams, though. Asking questions is essential in the building of any company or startup.
Pushing Back and Asking “Why” is a Valuable Habit
This question-and-answer framework provides an opportunity to refine direction for improvement of any single department, process, or even for the entire company. You can identify and change processes that aren’t working, before they create unintended culture habits. And, you can improve upon, or repeat, processes that are working well and aligning with your company vision.
It can be difficult to create a playbook to address problems, especially for new companies. The strength that 5 Whys offers is in the way it helps to compare outcomes to assumptions. Through this process, it should be easy to create a transparent way to demonstrate to new hires how policies are created. The documentation that results from a 5 Whys session can capture the institutional/project knowledge that was created.
5 Whys documentation that’s accessible to the whole company offers insight into the thinking behind important decisions that have been made.
Why don’t we utilize this growth avenue?
Because it hasn’t worked in the past.
Oh, what didn’t work about it?
Long-term projects can mean that lots of participants are coming in and out of the working team. Onboarding new team members can be difficult without having good documentation to review.
Pushing back and asking why, rather than presuming an answer is obvious, is a valuable habit. The structure itself demands a deeper dive into cause. Findings can sometimes be more embedded into team culture and leadership, rather than simply project process, which can provide an opportunity for team growth.
Creating Multiple Decision Trees
Processing 5 Whys as a team provides a larger opportunity to consider varied answers from numerous perspectives. In other words, conducting 5 Whys among leadership and excluding a working team will prevent a rounded perspective. A representative from each team that is involved in a project is recommended to participate in the 5 Whys.
But, splitting this exercise into two different groups at first can be an interesting experiment in that it can free energy up to dive into two completely different paths. And even from those two groups, multiple decision trees may result. Any 5 Why process that involves a group of respondents will likely produce more than one answer to each “Why?”
Capture answers into process so that improvement can actually be explored. In other words, turn root causes into something that changes the way the organization or project works.
- Create an issue or story in your project management flow (e.g. GitHub, Pivotal Tracker, Jira) based directly on the findings from 5 Whys, and assign to a responsible team member.
- Check in on progress of findings during standups.
- Utilize findings as validation for team direction and momentum.
When any team member is taking a project ticket, it’s important that they’ve read through the onboarding documentation. If the 5 Whys process has been clearly shared, a team member who is taking a ticket will be equipped to describe how they are going to approach that ticket.
Use a Moderator for Your 5 Whys Introspection
It’s important to keep your 5 Whys approach focused on the process. If possible, utilize an experienced moderator so that as each answer is addressed, the discussion stays on track and follows the path created by one specific answer.
Even thought various branches can be created with varied answers, it’s important to note them so that the discussion can revisit them separately. It’s important to appreciate that there are multiple causes and can be multiple findings, so planning to revisit multiple pain points shouldn’t be seen as a diversion but a foregone conclusion.
Remember that different perspectives make this process most successful, and after you’ve executed your 5 Whys followup strategy, determine which of many potential findings is the one that can be addressed most efficiently.
Ask “Why?” Even When Things are Going Well
5 Whys should not be reserved as a way to address only the problems that come up. This process is just as valuable when things go really well. Outcomes that you want to duplicate deserve a 5 Whys approach so that the correct characteristic of a successful outcome can be repeated.
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.