What’s the Point to Retrospectives Anyway?

Photo by José M. Reyes on Unsplash

A foundational component of Agile (whatever flavor of it you like) is daily improvement. Teams need to improve their code, tools, and even process to improve over time.

But when exactly does a team talk about how they should be improving? Enter the retrospective.

Retrospectives are some of the most neglected meetings in the software industry. I remember bringing a retrospective meeting to my team many years ago. Participation in was far from enthusiastic. They didn’t see the value of reflecting on the past iteration and didn’t care much about improving anything other than the code. Some were also put off by any mention of Scrum, with one engineer declaring, “We don’t follow Scrum!” in a rather aggressive tone.

And while that engineer was correct — retros originate from the Scrum guide — teams working in any iterative development cycle can still benefit from having a regular retrospective.

But it takes some effort and some experimenting. Today I want to walk you through what a retro is, a few high-level formats on a excellent retro, and my top tip for making your retros effective.

What is a Retro?

A retro is time for the team to gather, reflect on their work over the past iteration, and discuss ways to improve. The Scrum guide puts it this way:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. […] The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible.

But before getting hung too much on Scrum and Sprints, pay attention to the core idea of the retro. The team asks, “How can we plan to increase our quality? How can we build a more effective process? How can we get better?” Regardless of how your team delivers work, this is a valuable exercise.

To help break out of “sprint” thinking, think more about an iteration. How does your team break up work so that you can develop iteratively? However you divide up work (a time interval, release cadences, actual Sprints), the end of that iteration is a good time for a retro.