Don't Retro the Same Twice

Retrospective meetings are a cornerstone for most modern software engineering teams. They're the only regular practice mentioned in the agile manifesto, they've been written about ad nauseum, and many colleagues seem quite excited on the days their teams have retrospectives. Well-conducted, the retrospective can offer a lot of benefits to a team, their projects, and their organization on the whole, so everyone really wants to get the retro meeting right.

There's maybe a billion (I could be underselling it) formats for retro meetings, and in their care and consideration some folks have very strong opinions on the "right" structure for retro meetings. As (I hope) my writing on this blog can attest, I'm not a fan of that way of thinking about process. Retrospectives are simple - as long as there is a way to identify and discuss problems and successes then you're good to go; specific formats give some icing on the cake.

That icing can be quite important at times. While the primary utility of the retro is to identify and expedite the solution to problems, there's a host of ancillary benefits that can be gained from different retrospective formats. Indeed, different retro formats are going to be better suited to expressing different benefits. Maybe your team has a project which requires something more specific out of your retrospectives, and a particular format is obviously good for your team. That's great! Just remember it might change.

For most teams, one format isn't going to be clearly superior, but they can benefit - and benefit differently - from any format. So this is the advice I'll give: Don't have the same retro meeting twice in a row. This allows your team to get the benefits of all the formats, and there's a few ways to go about it. If you've got some persnickety folks on the team, you can rotate between different preferred formats to keep them all happy. You could, ahead of the meeting, briefly describe a couple of obvious challenges to Chat GPT and ask it to recommend a retro format to suit. My preferred way is to pick a format out of a hat and run with it.

Whatever you choose, don't retro the same twice! No format can do all the things for you and your team, and keeping the retrospectives fresh allows your team to approach their problems from different angles. For short-term problems (problems within a sprint) any format is going to be sufficient - as I said earlier all that is really needed is the ability to identify and discuss these. However, a lot of teams have long-running or more complicated problems, and the different angles approach might be better at unblocking these.

For the sake of being (too) analytical about it, here are some of the ancillary benefits (beyond identifying problems, improving process, and adapting to change) that retrospectives offer:

• Increase collaboration between team members
• Opportunity for distributed teams to build culture
• Celebrating individual and team successes makes everyone feel good
• Builds trust between members
• Helps individual members learn from mistakes
• Ensures team members have ownership over process
• Ensures members are aligned on team goals
• Allows individuals to "vent" when needed

And then here are some common formats, and how they express different benefits. You can find endless blogs about retro formats, so this isn't an exhaustive list but an exercise to point out how different formats can yield different benefits.

Four Ls

"Loved, Loathed, Longed For, and Learned". The "Loathed" column is particularly beneficial for members to see the results of mistakes and learn from them, and the "Learned" column specifically helps to stimulate collaboration.

Sailboat

"Wind (what's helping us), Anchor (what's holding us back), Rocks/Icebergs (potential future blockers), Island (what's the destination)". The "Rocks" and "Island" columns ensure the retro is balanced on looking to the future as much as the past, which enhances understanding and ownership over goals.

Mad, Sad, Glad

Self-descriptive, I hope! This breaks down the barriers to conversation, helping to build culture, celebrate successes, and allowing individuals to vent.

Six Hats

Each member "wears" one of the hats - Facts, Emotions, Creativity, Process, Positives, Negatives - and each issue is looked at from that perspective. Forcing these perspectives to be accounted for helps to stimulate collaboration and trust between individuals.

Five Whys

For each problem, ask "Why?" five times. By hyper-focusing on root causes, this can give the team a lot of control over its process by gaining a better understanding of how problems arise from situations or facts.

STAR

Each problem is described by the Situtation that happened, the Task that was being done, the Actions that were taken, and the Result. This is a hyper-focus on the relationship between goals, actions, and results, which is beneficial for helping individuals learn from mistakes. In the right situation it can help members vent in a productive way.