The Agile Architect

Crafting the Perfect Agile Retrospective

Our Agile Architect leads you through all the things that go into crafting a perfect agile retrospective.

• By Mark J. Balbes, Ph.D.
• May 4, 2022

One of the core tenets of agile thinking is to harness the power of the experience gained through the life of a project. Rather than making decisions early in the project lifecycle to (imagine sarcastic air quotes here) "mitigate risk," delay decisions until you know as much as possible. Learn from experience.

Naturally, this means you have to take the time to recognize those learnings and figure out how to incorporate the changes into your work.

The 12th Principle from the Agile Manifesto addresses this. It states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

The primary mechanism to realize this principle is the retrospective or, as its colloquially called, a retro. Agile teams will typically conduct a retro every week or every other week.

Done improperly, retros can be draining and demoralizing for a team, with endless talk about problems that don’t seem to get fixed, and airing of the same complaints over and over again, while quieter people are overshadowed by the loud talkers in the room.

Done well, retrospectives allow a team to incrementally improve over time. They give license to the team to try new things and gain momentum with minimal investment. After all, a one-hour retrospective each week is just 2.5% of the team’s time.

A Retrospective for Every Occasion

A retrospective is a time to look at something and ask how we could have done better. Ergo, you should have retros at the end. For example, you might want to have a retro:

• At the end of a meeting to see if you accomplished the goals of the meeting and how you could do better next time
• At the end of a sprint to see if you accomplished the goals of the sprint and how you could do better next time
• At the end of a business cycle, e.g., quarterly, to see if you accomplished the goals of the business cycle and how you could do better next time
• At the end of a project to see if you accomplished the goals of the project and how you could do better next time

And so on. You get the picture.

How to have a perfect retrospective

Here are some hard-won lessons on having an effective retrospective.

Use an objective facilitator

I’ve seen teams try to facilitate their own retros. It’s difficult if not impossible to be objective. Having a trained, objective facilitator ensures that everyone’s voice is heard.

Prepare

The team should spend time before the retro, either together or individually, figuring out what topics they want to discuss to make the most valuable use of their time. The facilitator should discuss this with the team members and prepare an agenda accordingly.

Be prepared to throw out what you prepared

No matter how much you prepare, be ready to throw it all away once the retro gets started. The whole point of the retro is to learn. Things come out that you don’t expect. You want to be able to follow through on whatever comes up. Be in the moment and go with it

Use exercises with a purpose

There are some great sources available for different exercises and/or games to fit any need. Some examples:

• Agile Retrospectives Making Good Teams Great
• Tasty Cupcakes
• Lean coffee
• A good, old-fashion open conversation
• Or create your own, as I did (Unbalanced Villains and Overpowered Heroes)

Find ways to bring in all voices, loud and soft

The exercises above are a great way to do this. Vary how the team contributes: verbally, written, collaborative whiteboarding, drawing, etc.

Start the retro with metrics

Metrics help the team see how they are doing. They can be standard metrics, such as cycle time, velocity, and burn up. They can also be the metrics used to measure whether an ongoing experiment is being successful.

Here’s an article by my colleague, Jason Tice, that discusses simple team metrics to assess improvements: "Simple Team Metrics to Assess Improvements."

Devise time-boxed experiments

As I alluded to above, the only way to know for certain you are getting better is to measure the improvements. Time-boxed experiments are a great way to free the team to try new things without having to commit long-term. This allows naysayers to approve of the change and lean into the experiment without thinking they’ve given up something important to them permanently.

Give yourself enough time

A solid sprint retro should be scheduled for an hour at minimum. End-of-project retros should be several hours, if not a day, depending on the size of the project. There needs to be enough time to understand the successes and challenges of the work, analyze it, devise experiments, figure out how success will be measured, and plan how the team will tackle the experiments. If there's not enough time, the retro will devolve into a bunch of talking heads with the ideas going into the air and scattered to the wind.

Final Thoughts

What if there were no retrospectives? What would your team do to improve? How would you capture learnings, devise experiments, and measure whether the team was improving?

It’s a useful discussion because retrospectives are not the only way a team reflects on how they work and try to improve. But that’s a subject for a future column.