The Art of the Retrospective

Last Thursday night, on the evening before a long-needed day off, I found myself on Slack. Normally, I try to place some distance between myself and work with an impending holiday, but the questions were worth staying online to answer — they were from a new member of our team who was about to run his first project retrospective and seeking guidance on how to do it well.

I offered my ideas of what makes a good retro (in broad strokes) and tried to find a few articles to send his way that could provide some additional color and insight. Surprisingly, I didn’t find many I liked. I joked to my colleague that maybe I’d write an article of my own.

This is that article.

After mulling over the topic on that day off and throughout the weekend, I’ve done my best to document what I’ve learned about retrospectives in my last 5 years in tech: what they are, why they’re valuable, and how to run a great one!

First things first, because my network isn’t purely tech professionals, it’s probably worth explaining the obvious…

What exactly is a retro?

In my own words, a retrospective is a simple team exercise of looking back on a given period (e.g. a 2-week sprint) or initiative (e.g. a platform migration project) and identifying the things that went well, the things that were challenging, and the ways to improve in the future. It’s a bread-and-butter ceremony in Agile Scrum sprint process for a reason: it encourages a team culture and mindset of continuous improvement

Why are retros valuable?

Retros are valuable because they compel a team to pause and reflect. It’s easy, especially in tech or in any industry/field where things are fast-moving or otherwise “GO! GO! GO!” to just keep going. When work is busy, it’s not always easy to prioritize the time to pause and reflect individually — and even less so to pause, reflect, and discuss as a group.

In my experience on teams, on too many occasions, it’s easy to go on autopilot and either ignore a problem or live with a problem, saying “it’s just the way things are.” Moreover, issues that were really painful in a project — if not captured and discussed in some way — can go quickly forgotten, only to reemerge later. The opportunity to apply past wisdom to a current or future situation gets lost in the fog of continuous movement instead of continuous improvement.