The psychology behind a blameless retrospective

The psychology behind a blameless retrospective

By understanding human behavior, you can create safe and positive environments for your agile teams to reflect on and improve their work.

Sprint Retrospective Board
Image credits : 

by Dr. Ian Mitchell [CC0], via Wikimedia Commons

x

Subscribe now

Get the highlights in your inbox every week.

A retrospective is the act of dealing with past events and activities. The word comes from Latin, and it literally means "to look back." In the business world, a retrospective is a practice agile teams commonly use to reflect on how their work is done to improve how they do it so they continuously become better at it.

One of the Agile Manifesto's principles suggests all teams regularly reflect on how to become more effective. The main goals of a retrospective are to promote self-improvement, improve processes, and advance team members' skills.

The Retrospective Prime Directive says:

"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."

At first glance, this practice looks straightforward—but reality shows us it isn't. People naturally tend to make decisions based on their instincts instead of rationally evaluating a situation. When things go wrong, it is often hard to accept responsibility and not join the blame-game.

The psychology behind blame

As humans, we uncontrollably evaluate the behavior of others to explain the cause of the behavior and the events we witness. For example, is someone late because they are not able to manage their time? Or because of an emergency situation? Over 50 years ago, Austrian psychologist Fritz Heider introduced attribution theory, which says humans tend to see cause-and-effect relationships, even in situations where they do not exist. During a retrospective, it's natural to try to understand other people's behavior by attributing one or more causes to the specific behavior.

Next, naïve realism kicks in. We firmly believe our senses provide us with direct awareness of objects as they really are; however, our perception might be playing tricks on us. This is true for natural objects, as they obey the laws of physics, whether or not we observe them. But, our memory of events is shaped by our experiences and our beliefs.

What happens in the retrospective meeting when participants believe they perceive past events "as they were" rather than as a subjective construction and interpretation of reality? In these situations, we believe that rational people will have similar perceptions as ours, and folks with different views must be uninformed or biased. Therefore, it is good to be aware that it is always easier to blame someone else rather than to accept responsibility. As humans, we naturally opt for the option that requires less effort. Recognizing our contributions to a bad situation is harder than looking for others who could be responsible.

To help alleviate this pressure, it is critical to create a positive environment. The prime directive for holding a retrospective says for a retrospective to be effective and successful, it needs to be safe. Norman Kerth, author of Project Retrospectives: A Handbook for Team Reviews, explains that safety means all participants must feel secure within their community.

The 3 foundations of blameless retrospectives

To ensure your blameless retrospective truly is successful, make sure to build it on these foundational pillars.

1. Nominate a facilitator

A successful retrospective needs a facilitator who can ensure the group will achieve the goals of the meeting. A facilitator can help open up discussion by asking:

  • What didn't work?
  • What did everyone do and how did we do it?
  • What will we do differently next time?

To create safety, the meeting facilitator needs to actively invite input from and engage with all team members. The facilitator also needs to manage the meeting to avoid interruptions.

2. Everybody has a say, everybody has a voice

This is a foundation drawn from the principles of lean manufacturing. In the Toyota Production System, any employee can pull the Andon Cord. This action immediately interrupts work for everyone so the team can gather together to perform real-time root-cause analysis and quickly apply a solution. The only way the Andon Cord can work is when everyone feels empowered to use it.

The same goes for the retrospective. Team members are not only given permission to speak but should feel an obligation to flag issues when they occur. When teams are sharing bad news, it is even more important to create a feeling of safety and empowerment.

3. Embrace enjoyment

The foundation of play is "enjoyment." Laughter is often recognized as a fundamental sign of a safe connection inside a team. Therefore, creating the opportunity for fun will allow everyone to signal they feel safe. This may require you to try out some unconventional techniques. If you are looking for specific recommendations, check out FunRetro, an online open source retrospective tool for distributed teams, and the Realtime Retrospective exercise.

Master the art

A lot of deliberate practice is needed to master the art of blameless retrospective. It is worth investing the time to have regular retrospectives to create a feeling of safety and enable people to discuss their work openly.

"Building safety isn't the kind of skill you can learn in a robotic, paint-by-numbers sort of way. It's a fluid, improvisational skill—sort of like learning to pass a soccer ball to a teammate during a game."
The Culture Code, Daniel Coyle

Retrospective participants should be able to learn from the exercise, but the most important goal of regular retrospectives is to develop safety and maintain it continuously.

Want to learn more? Check out:

Topics

About the author

Dominika Bula - is an full time Agile Practitioner and enthusiastic participant of Agile and DevOps Community of Practice at Red Hat. Dominika has become active in Open Source, helping organize Fedora's conference, Flock 2016 in Krakow, Poland and Flock 2018 in Dresden, Germany. A graduate in Cultural Studies, she is excited to see how open communities collaborate and share. Prior to joining Red Hat, Dominika worked as Project Manager for internalization and localization projects helping adapt applications to...