.png){kind=icon}
Table of Contents
For most teams, regular retrospectives create momentum and feed progress. Once your team starts focusing on what it can control, the 15% solutions start adding up and positive change becomes the norm.
Hurray! All done here, right?
Well, not so fast. Some teams may realize they’re finding solutions in their retrospectives before they fully understand the problem that needs to be solved.
To be more specific, if your team says things like “we’re trying to be better but we keep running into the same issue” or “we just can’t seem to do this better,” it’s probably time to take a closer look 🧐 at the causes of the problem you’re facing. It’s time to run a root cause analysis exercise.
Try Retrium. It guides you through the retrospective process.
Start today for free!Root cause analysis describes activities or tools designed to help teams and organizations uncover underlying (root) issues.
In simple terms, a root cause analysis activity goes beyond the initial problems and explores what deeper problems exist. Maybe there’s a problem with testing efficiency or testing maturity. Or maybe the team is facing a tooling challenge. Or maybe the team is just hangry and needs permission to take longer lunch breaks. 🍽
We live in a complex world. Many times we face issues that have a multitude of contributing factors. Holiday schedules, team dynamics, tooling, weather patterns, etc. The list can get pretty long. However, not all of these are under your team's control. A root cause analysis activity can help you, and your team better understand what all is affecting the team and the best way to move forward.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
As the saying goes, it's better to work smarter, not harder.
Is your team facing the same issue even after multiple attempts to find workarounds? Or is the team running multiple meetings on the same problem that doesn't end in any productive change?
If your team is constantly spending time trying to fix the same issue over and over again, then you aren't working smarter. You're just working more.
Now let's pause for a second. As I have said, agile is all about finding ways to continuously improve. So if your team is retrospecting on issues and are creating action items that lead to improvement, fantastic!
But if you're sitting in meeting after meeting week after week thinking, "it's the exact same problem we've been struggling with FOREVER," 😱 then you may be putting bandages on more significant troubles and not tackling the real issues. In other words, your team is finding a solution before identifying the problem.
It's okay - it happens to the best of us! And this common misstep can cost teams time, energy, and money.
This is where a root cause analysis can save the day! 🦸 Instead of running into the same blockers regularly, your team can identify real causes and set the stage for solving a problem for good.
A noticeable difference between a retrospective and a root cause analysis is the underlying approach.
Retrospectives are a valuable opportunity for the team to reflect on the previous iteration and identify possible changes to how the team works. Usually, the team has a pretty solid understanding of how to improve and address any hiccups in the work process. You’ll probably walk away with action items so your team can get to work and measure progress.
On the other hand, with root cause analysis, you usually start with one persistent issue - the problem statement - slowing down the team, which hasn’t been resolved in your retros. During your root cause analysis, you’ll dig into every level of that problem to get to the root of it.
By understanding the depth and variety of factors at play, your team can better understand where to start tackling the obstacle instead of finding solutions that may never fix the underlying problems. This means you might not walk away with any action items or solid solutions - you might leave with a clearer understanding of what’s causing your problems and roadblocks.
While this may feel counterintuitive (isn’t agile supposed to lead to actionable change?), sometimes you need to take some time to diagnose the actual cause before you treat the symptoms.
Root cause analysis describes a type of activities. And when it comes to root cause analysis, two activities reign supreme - the five whys and fishbone. When you combine these techniques, you have a dynamic strategy to get to the root of any issue.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
Part of a root cause analysis involves adding causes-of-causes. This strategy allows everybody to elaborate on why they think each problem occurred.
The five whys technique is a great way to dig into an issue and uncover any patterns that might point to the root of an issue. Its goal is to find the primary cause for an issue by asking “Why?” - usually five times. (I know, surprising!)
For each initial cause your team creates, continue to ask why each cause occurred. To help illustrate how this works, let’s look at a sample problem statement: “the project went over budget.”
Why?
“Because nobody met the deadline.” Our initial cause.
Why?
“Because the scope changed, and the project became more complex.”
Why?
“Because leadership expectations were explained after the scope was established.”
Why?
“Because leadership was not involved in initial scope conversations.”
Why?
“Because we thought we understood expectations.”
With this technique, you went from blaming team members for missing deadlines to discovering a systemic miscommunication with stakeholders. Moving forward, your team can work on how and when they receive shareholder expectations.
You know your team best - if you feel like you can’t dig any further, then feel free to stop. Maybe you only had to ask “Why?” twice, or maybe you had to ask seven times. Every team is different.
Ishikawa Diagrams
In the 1960s, before Lean and Six Sigma joined forces to combat inefficiencies, Kaoru Ishikawa developed the Ishikawa diagram to measure quality control processes in the shipbuilding industry. An Ishikawa diagram is a cause-and-effect diagram (told you we’d come back to that 😉) used to illustrate the causes of a specific problem or event.
Today, the Ishikawa diagram is considered one of the seven basic tools for quality. It goes by many different names - a herringbone diagram, a cause-and-effect diagram, or a Fishbone diagram.
You’ll probably see Ishikawa (aka Fishbone) diagrams used in many different settings. Outside of Lean Six Sigma as a tool to identify problems interfering with team processes, the Scaled Agile Framework utilizes the Fishbone technique as part of their Inspect and Adapt Event for team problem-solving.
Fishbone diagrams are an incredibly popular tool for root cause analyses. They give teams a way to illustrate the causes of a specific event and organize feedback into groups (useful for the visual learners among us 🧐).
With that said, while we’re here, I’m going to talk a lot about running a root cause analysis with Fishbone.
Many teams leverage Fishbone as their go-to template for problem-solving because it’s easy to adapt to the needs of all kinds of teams. Whether you’re using a facilitated tool or just a pad of paper and a pen, it’s an accessible and effective way to get your team into problem-solving mode.
You might use something different to problem-solve as a team - and that’s fine! If you’ve found something that works for your team, keep doing it. But if you want to switch up your problem-solving sessions, or you want to see the value Fishbone can bring to your root cause analysis, then let’s dig in. 👇
Similar to traditional retros, facilitators encourage different opinions to drive a thoughtful discussion. After all, fruitful conversations thrive off of different perspectives.
Since we want varying points of view to be shared in our retrospective discussions, it’s important to establish expectations for the meeting before it starts. While it’s nearly impossible to ensure that everyone agrees all the time, there does need to be some agreement on specific procedures to help make the discussion productive.
In chapter 8, we talked about the value of working agreements. Your working agreement should be a living document that sets clear guidelines for how the team approaches your meetings - what are decorum expectations? What tools are you using? When should the meeting have been an email or Slack message?
Having these guidelines in place before you start your meeting means you won’t sweat the small stuff. Especially during a fishbone, having those all-important working agreements on how to write topics or when you will move on from a discussion point can help your meeting run smoothly so you’ll be ready to hit the ground running with fewer disruptions
If you’re running a Fishbone retrospective, start by identifying and agreeing to a specific problem statement. A problem statement provides a brief but broad overview of the team’s obstacles.
We talk about the problem statement being the most critical part of your Fishbone. That’s a lot of pressure to put on a sentence!
But it doesn’t have to be intimidating! Yes, your problem statement is the backbone of your conversation…but lucky for you, we have a quick tip to create a great problem statement. Are you ready?
Keep it simple.
Yep, that’s it!
Ideally, your problem statement should:
That’s it!
Let's say your team is meeting because your project ran over budget. Now, three people on the team think the project ran over budget because the team is understaffed and overworked. But two team members believe the project went over budget because deadlines moved too often. In an effort to incorporate everyone's input, you set your problem statement as: "the project went over budget because we're understaffed and deadlines changed."
But now you're only talking about staffing issues and deadline changes. What if other people on the team thought the project was affected by scope creep? Or lack of clear communication?
Suppose you get into specifics in your problem statement. In that case, you'll limit your conversation from the onset and potentially miss out on a great discussion because people feel like they can't contribute their points of view! Definitely not what we're after.
So our advice is to simplify, simplify, simplify. Look at your problem statement and ask yourself (and your team!) if the statement can be any broader.
If you start with: "The project went over budget because we're understaffed and deadlines changed."
Peel it back to: "The project went over budget."
This simple change in formatting opens up the entire conversation. You've broadly defined the group's main issue, but you're not locking yourself into one specific conversation.
Remember - paring down your problem statement doesn't mean you won't get to discuss the specific concerns on everyone's minds. Remind everyone that they'll all get to contribute their unique perspectives in the next phase of the retro. The problem statement is just there to help you get the ball rolling.
A massive part of root cause analysis is identifying potential causes to support the problem statement by asking “why.”
If you have “The project ran over budget” as your statement, the team can start to add their causes by adding “because” and finishing the sentence.
“The project ran over budget because of changing deadlines.”
At this point, the Five Whys technique can help teams identify underlying problems. By asking the group to question “why” several times, you gain a deeper understanding of the issues facing your team or project.
Ask the group to add all possible causes to the problem statement. The sky’s the limit! The more everyone contributes, the more you have to work with later.
I like to remind my team that there’s no right or wrong way of generating ideas. Encourage everyone to contribute their thoughts, regardless of the degree of significance they may have. At this point, it’s essential to avoid identifying solutions. We’re generating ideas and working to explore every potential cause related to the problem statement.
At this point, you’ve got a lot of ground to cover. The team has contributed their causes and their causes-of-causes.
Now what?
Readily available prompts can help encourage discussion and make the process of identifying causes to address run smoother. Using a prompt can keep the group focused on the topic at hand while encouraging your team to see things from different perspectives if they’re feeling stuck.
If you sense that the conversation is losing direction, try: “Let’s talk about the causes the team has control over.” This statement can help ensure you’re focusing on problems that you can actually solve - not getting stuck in a downward spiral that doesn’t lead anywhere. 🌪️
On the other hand, you may announce, “let’s focus on causes that require help from management to address.” This can be a great way to start a conversation on what team members need and how to ask for it when they need it.
Yes! You’ve reached the end of your root cause analysis! 🎉 Your team has had a productive discussion and identified a root cause that requires your attention.
Now it is time to take the next step.
We’ve already established that a root cause analysis differs from your typical retro. In a classic retrospective, you work to create a list of action items for the team to follow through on to drive continuous improvement.
There’s more flexibility on what comes after a Fishbone or other root cause analysis activity.
The team may know exactly what needs to be done to solve the problem, so you whip up a couple of action items and call it a day! But what if you need more time and data to move forward? Time to do some research!
Sometimes you’ll see root cause analysis activities end in a list of Causes to Address. Reaching this step means that your team has identified potential root causes that are getting in the way of success but that you haven’t come up with solid solutions for addressing them yet. That’s okay - we promise!
Let’s say you get through a Fishbone and identify a single cause to address: “Management didn’t set clear deadlines at the start of the project.”
However, you’ve just spent an hour digging into the tough stuff, and the team may be slightly burnt out. A fishbone is all about taking the time to develop understanding. So once everyone is on the same page about what challenges the team, what do you do next? 🤔
Let’s take a look at some of the options for how to move forward together.
Sometimes it’s best to revisit a tricky subject after the team has had some space to think and refresh.
In moments like these, many teams like follow the root cause analyses with a retrospective similar to how SAFe approaches their Inspect & Adapt event.
If you’re stuck at the end of the Fishbone, consider scheduling a different retrospective focused on your cause to address. A “Start, Stop, Continue” retrospective can help the team think through clear solutions to your issue.
Pro tip: there are lots of retrospective techniques out there. Make sure you’re choosing one that’s right for your team and the issue at hand!
If you create a list of action items at the end of your root cause analysis, make sure you have a plan for how the team will follow through on their commitments to each other for improvement. Will you add these items to the backlog? Does the action item have an ambassador? Is there a system in place to monitor and record your progress?
Knowing how you’ll tackle your action items increases the likelihood that things actually get done. If you already have a plan in place, your team won’t struggle to figure things out on the fly - they’ll feel empowered to take action on their own.
Don’t feel pressured to figure everything out at once. Getting to the bottom of a recurring problem is a win - and we’re all about celebrating every victory! 🥳
The short answer? All teams can benefit from a root cause analysis exercise.
Root cause analysis is frequently used in many different ways across several industries. From improving internet safety for cyber security teams, to ensuring quality on manufacturing teams, to improving efficiency and safety for healthcare workers, a root cause analysis can be adapted to meet the needs of any team.
Root cause analysis isn’t really new. Teams have been using it for decades to find solutions and ways to solve problems standing in the way of improved performance. If you’ve heard of Lean Six Sigma, the Scaled Agile Framework, or Ishikawa diagrams, you’ve probably come across root cause analysis in one form or another.
Even if you’re not part of any of these communities or don’t subscribe to any of these methods, the type of thinking at their core is still valuable. All these groups are defining a way to come together successfully and problem-solve. The theory is the same, but the execution may look slightly different.
If your team faces an intimidating issue, you might face some analysis paralysis. You know something is standing in the way of success, but where do you start?
By running a root cause analysis, you’re taking that big issue and breaking it down into smaller, more manageable causes as much as you can. Taking the time to dig into every layer of the problem will make it easier to tackle.
No more getting stuck in thoughts and stressing about things that feel out of control. By completing a root cause analysis, you’re making sure your team is focused on things they can change. Those feelings of frustration will start to transform into a sense of success. 🌱
All of us, agile or not, know the pain of running into the same feeling of discouragement over and over again because we’re not addressing the core issue. We want it to be easy to get to the root of our problems, but we all know it’s never that simple - emotions cloud our judgment, our decision-making is affected by the people around us, and so on.
That’s why the value of root cause analysis isn’t just for agile teams. After all, what are we really talking about when we talk about agile? Helping teams make better decisions together - and that means all of us.
For most teams, regular retrospectives create momentum and feed progress. Once your team focuses on what it can control, the 15% solutions start adding up, and positive change becomes the norm.
Hurray! All done here, right? Well, not so fast.
Some teams may realize they’re finding solutions in their retrospectives before fully understanding the problem that needs to be solved.
To be more specific, if your team says things like, “we’re trying to be better, but we keep running into the same issue” or “we just can’t seem to do this better,” it’s probably time to take a closer look 🧐at the causes of the problem you’re facing.
It’s time to run a root cause analysis exercise.
As a facilitator, choosing the best technique for the team and selecting a guiding topic to lead a meaningful discussion will set your team up for success in the next sprint. Are you just going to focus on the bigger technical aspects of the sprint? Will you focus on bugs? Does the team need to discuss organizational concerns? All of the above? Deciding what to discuss and how in your retrospective is no easy task!
.png){kind=small}
