Retrospectives Work When They Are Impersonal and Impartial

Retrospectives are a terrific way to continuously improve any software development process. As long as the organization is committed to improving itself, rather than protecting the status quo, there is nothing better than regular retrospectives.

So why are project retrospectives often ignored or under used?

There are many articles across the Web describing how to do retrospectives. They are not hard, though there is a serious pitfall that can derail the best of intentions. Retrospectives must be impersonal and impartial.

That’s harder than it sounds. It seems that many of us are conditioned to place blame. At least here in the U.S.A., we see plenty of people not taking responsibility for their actions. They want to blame someone else every time there’s a problem.

We also tend to easily become defensive. Even if a problem is being discussed in general terms and no names are mentioned, some people will jump to the conclusion that they are being targeted. This usually prompts them to retaliate. The session can turn ugly, quickly.

If anyone comes out of a retrospective feeling beat up, picked on, or abused, the event was a failure. Even worse, no one will want to attend future retrospectives out of fear that they too will be abused.

Let’s examine a few situations that cause such behaviors and how you might handle them.

  1. There is one person on the team that is not carrying his weight. He is letting down the team and causing extra work for others. Is this a retrospective topic? No, of course not. This is a personnel issue and should be discussed with the team member in private.
  2. One of the processes followed by the team isn’t working. It turns out that the process is always executed by the same team member but she is doing it faithfully as defined. The process needs to change. Retrospective topic? Yes, but! The issue must be discussed with the team member in advance. Explain that the process is flawed and ask for suggestions that can be aired at the meeting.
  3. There is a process followed by most members of the team. But, a couple of folks take shortcuts resulting in unintended consequences. Retrospective topic? Maybe. There are two ways to handle this. a) Speak privately to those taking shortcuts and get them to stop; or b) modify the process during a retrospective so it works for everyone.
  4. The Product Owner or Scrum Master is not fulfilling the requirements of the job or meeting the needs of the team. Retrospective topic? No! Again, these are personnel issues and should be discussed in private. If the PO or SM wants to seek feedback from the team, that’s fine, but only after a private discussion.
  5. An end user, customer or client complains constantly and is difficult to handle. Retrospective topic? Yes, indirectly. The PO should engage the accused party in a conversation to uncover the real issue(s) and explore solutions. Meanwhile, the team can discuss how to better meet the needs of all people using the software.

The key points to take away are:

  • No surprises. A retrospective is not an ambush.
  • No confrontations. A retrospective is not a street fight.

Always keep Norm Kerth’s Retrospective Prime Directive in mind.

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.

Walking into a retrospective and becoming the target of someone’s complaints is not fun. Retrospectives are for continuous improvement of the software development process. People improvement is valid topic as long as the improvements apply to everyone. Individual performance is off limits. Take it outside.

Updated: June 26, 2012 — 10:03 pm