Root Cause Analysis – The Missing Ingredient in Your Agile Team

Recently, one of the teams that I began to work with was struggling to deliver a working product in a consistent manner. The Scrum Master had consulted me on a number of occasions in effort to resolve this issue that had been going on for months. According to the Scrum Master, the team felt that they were not improving how they worked together due to ineffective Retrospectives. Although I was not 100% sure that was the primary source of this team’s issue, I was curious how this team approached overcoming this critical juncture in its development.

Before I felt I could offer any solutions or recommendations, I needed more understanding on this situation. In order to accomplish this, I obtained approval from the team to attend a few team events in order to gain insight into how this team functioned. What I observed was something that seems to occur quite often.

This team is one that I would consider to be relatively capable; the team had been working together for several weeks, and seemed to have a solid understanding of basic Scrum practices and Agile principles. Under the guidance of the Scrum Master, they executed most of the events effectively. At the Retrospective, I noticed that this team fell into a very common pitfall that even the most seasoned teams encounter – they attempt to resolve issues and inefficiencies as quickly as possible without taking time to understand the root cause.

I believe that this occurs very often because as professionals, we aspire to contribute our skills and show the world that we are capable; this is basic human ego at play. How this mindset often exhibits itself is the need to solve problems as quickly as possible so that we can feel good about our contribution to the team, so that we feel that we are earning respect from our peers. While this thinking is usually a good thing to have on your team, solving the wrong problem can lead to wasted effort and prolong the team’s learning cycle.

So how do we make sure that we are addressing the right problems the right way? There are a multitude of techniques that can be employed in the field of Agile Root Cause Analysis, including popular methods such as the “5-Whys”, fishbone diagram (a.k.a. Ishikawa Diagram), which are very effective means for identifying the actual source of the issues that the team is facing. When might be a good time to do this? For most Scrum/Agile teams, the Retrospective is usually a good forum to solicit input on what processes, relationships, or tools require improvement due to some negative symptoms; this meeting is usually focused on revealing the symptoms instead of diagnosing what is creating such symptoms. Hence, there are two options that I would recommend: (1) Extend the Retrospective to ensure proper time is allocated for root cause discussion, or (2) Set aside a separate working meeting to dive into the real underlying reasons that things aren’t going as well as expected.

Agile purists may frown upon my recommendation to set up yet another meeting. Since the Scrum Guide does not disallow additional collaboration events if needed, I feel that it is often advantageous to give the team time to brainstorm and think about the issues at hand first before jumping to conclusions and attempting to apply a less-than-optimal solution that can potentially create even more problems down the road.

In summary, if your team seems to be stuck in an infinite loop where the same issues continue to pop up over and over again, it is very likely that the team is not solving the right problems. You can help your team by using Agile Root Cause Analysis to guide them towards a more methodical approach by analyzing the source of the problem. If you give them a chance to master this approach, you may see a significant difference sooner than you expect!