What’s the Point to Retrospectives Anyway?
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…
