Getting the Most Out of Agile Retrospectives

SoftwareDevTools
SoftwareDevTools: The Publications

--

Agile development teams seem to appreciate the value of having standup meetings. They are easily adopted by teams.

Unfortunately, I can’t say the same thing about retrospectives.

One of the common problems that I’ve noticed is the lack of discipline with retrospectives, especially when it comes to defining and following up on action items.

It seems that retrospectives are being done to ceremoniously comply with the requisite of doing so rather than looking to establish a continuous improvement process. That’s when “retrospective fatigue” kicks in. That’s quickly followed by comments, like, “What is the point of doing this? Nothing is going to change anyways.”

You Might Be Too Busy to Improve

Based on what I’ve seen in the different projects I’ve participated in, and from other experts, some reasons are:

  • Retrospectives are the only thing that hold back the excitement to begin planning new stuff. Everyone wants to get into a new iteration ASAP.
  • There is no leadership.
  • There are more complainers than doers.
  • “Someone else must solve this.”
  • No concrete action items are defined during the retrospective.
  • Action items are hard to keep track of (and spreadsheets suck).
  • Everybody is busy and action items are forgotten.

How to Implement Retrospectives

  • Evangelize the retrospective process, make sure it is important to the team.
  • Agile process simulation games help teams understand the value of retrospectives, especially the Ballpoint Game.
  • Show the results of action items and share them with the team as soon as they are solved.
  • Define owners and due dates for action items. Otherwise no one will be responsible.
  • Have action item owners share status during daily meetings as if they were User Stories.
  • Start each retrospective by looking at the action items that came out of the last one.

What Can We Learn from Retrospectives?

  • They are really simple to do.
  • They help the team improve and get better results.
  • Dev teams feel backed up and supported.
  • Helps the team solve problems and improve themselves.

--

--