Get certified - Transform your world of work today


Taming the Blame Game Dragon

Finding the "real" root cause

26 August 2016

Vivek Ganesan


A scene during a retrospective

"How can you expect me to reduce the 'blocked' time for the testers? No one cares about red builds. Developers take days to fix the builds. They are simply shirking their responsibilities. Behavioral issues need attention and action from authority," a voice complained in the program retrospective meeting. Obviously, a root cause analysis was in progress.

After a heated exchange of words, a decision (irrelevant to us now) was reached. Someone noted the action item. A few minutes passed, and a few more issues were discussed.

The same voice spoke again.

"One good thing that happened in this iteration is that we were able to get the [insert tech talk here] standardized for developers across the program, thanks to the tireless efforts of my team members."

Maybe you've heard something like this before. Do you see the problem? No? Read on!

Let me assume the voice of the "the voice" above and rephrase what was said.
  • Situation 1: I am not able to influence the developers to fix red builds faster. It is the developers’ problem. Escalate to authority.
  • Situation 2: I (or my team) was able to influence developers to do X. It is my (team’s) achievement. Reward me.
Now you see the problem, right?

Understanding the fundamental attribution error

Take a minute and try to recall a time when you behaved like the voice above. If we are honest with ourselves, we probably can think of at least one instance. Everyone commits this mistake. It even has a formal name in social psychology — a fundamental attribution error. A fundamental attribution error is a mistake that almost every normal human commits. It is just another way of saying, "Something went well because I was the reason. Some other thing went badly because the situation was bad."

This error might just be secretly killing your retrospectives, without being very visible. The long-term effects of ignoring the fundamental attribution error could be that the team stops talking about uncomfortable topics, i.e., their mistakes, because they know that the person with the loudest voice will never accept any part in the mistake. This can seriously hamper the learning system of the team.

Digging deeper

Let’s dig deep into what can qualify as the reason for something going well or badly. When something goes well or badly, the reason can be one of the following:
  • Person/people
  • Surroundings/situation
  • Time
Unless one pays great attention, it is easy to decide on the most visible or salient item in the list above as the cause. For example, it would be easy to blame a new member of the team for the team’s high bug count.

Objectively determining the real root cause

If all human beings are vulnerable to the fundamental attribution error, what is the right way to arrive at the real cause of a situation? Luckily, social psychology also provides us with a way to differentiate among these three possible root causes. The model that helps us to zero in is called the Covariation Model.

During root cause analysis, to wear an objective hat, keep looking for the following factors:
  • Consensus: How many people/teams do it?
  • Distinctiveness: Do all situations result in such behavior?
  • Consistency: Does this happen repeatedly or was it just this one time?
Let us take an example of the "build red" situation and explain the above terms:
  1. Do all developers not fix the builds or only some developers? (Consensus)
    • All developers (High consensus)
    • Only some developers (Low consensus)
  2. Do they not fix builds only in the current notification system, or even when alternate notification systems are installed? (Distinctiveness)
    • Fix builds in alternate notification systems but not the current one (High distinctiveness)
    • Not fixing builds irrespective of notification system (Low distinctiveness)
  3. Was this behavior seen only in this iteration or was it in the past iteration, too? (Consistency)
    • Past iteration too (High consistency)
    • Only this iteration (Low consistency)
We just have to follow the matrix below to objectively arrive at the real root cause.








The "real" root cause

Low (Not all)

Low (Both in current notification system and in other systems)

High (Every time)


High (All devs)

High (Only in current system)

High (Every time)

Situation (or notification system, in this case)

High (All devs)

Low (All systems)

Low (Only this time)

Time (Probably this iteration, the team is under high pressure to do more features)

Take some time to digest the above table. Yes, it takes a few minutes!

Now, you might ask me, "What do I do if I get values like Low, Low, and Low in all three variables?" There is no answer for such a combination in the above table. In such a case, the simple answer is that we do not know. There is not enough information to arrive at a single root cause. Instead, try attacking two possible causes.

By following the Covariation Model in root cause analysis, particularly during retrospectives, we can unlock some powerful perspectives. Make this a habit, and the team is more likely to openly discuss problems and solve them when empowered by the objectivity that this model offers.

Try this model for the problem that is hurting your head right now — and do tell me how it goes.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.8 (5 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up