Published: March 15, 2023 • Updated: March 20, 2023 • 4 min read
Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros. If you’ve never done one before; you can do it!
I’ll be covering:
Let’s get started.
What is a retro? From a dictionary:
Retro, short for retrospective: ‘a surveying of the past.’
Retros are a Scrum/Agile ‘ceremony’, a collection of best practices for software engineering teams.
I see a retro as a safe space for a team to pause, discuss what’s going well and what could be going better, and take action to improve.
Why should we retro? We retro because processes can evolve with effort and communication.
Effort is the intent. Everyone has to try and believe that things can improve. Communication is the tool— talking, listening, taking notes, and following up.
In Extreme Programming Explained, Kent Beck shares one of the core ideas of XP: if something is good, we should do it all the time. Communication is good and retros are an easy way to communicate often.
Every great team I’ve worked on has done retros. As a leader, it shows you have vision beyond the current obstacles and are building processes to last.
When should we retro? Anytime!
I like to do retros at the end of a project. They can be done weekly or monthly, too. If you feel like you’re not getting as much value out of each one, do less. If you feel like communication is poor, do more.
Let’s get set up!
First, put the retro on the calendar and invite your entire team. Everyone must attend the entire meeting; no absenteeism, fighting fires, or multitasking. I think an hour is the right amount of time.
Second, assemble materials. The tools I use are:
Sometimes tensions can be high, even on productive teams. That’s why I always start by reading ‘The Prime Directive’ aloud:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” —Norm Kerth, Project Retrospectives: A Handbook for Team Review
Retros must build on top of this agreement to succeed.
How do we actually collect the feedback that we need?
The most common format I’ve seen is asking:
Write these on the whiteboard as two columns, and give everyone five to ten minutes to jot down their thoughts on Post-Its. When finished, have people place their Post-Its on the whiteboard under the appropriate column.
If tensions are high on the team, you can anonymize the feedback with online tools like Easy Retro.
💡Pro tip: mix up the retro format. Next time, ask:
Or, try one of the dozens of retro formats you can find online. Mixing up the format wakes people up and elicits better feedback.
When you’ve finished collecting feedback, pick a team member to read the Post-Its. I like to delegate this task to a different person each time to increase participation.
If you’ve chosen to anonymize the feedback, give people the opportunity to speak up and own their feedback. Listen, ask good questions, and take notes.
Retros need action items; demand action. Here’s an example:
If you aren’t assigning concrete tasks from the meeting, you’re doing it wrong. People don’t just want to be heard, although that is important. They need to believe that things can improve. To build that belief, you must take action.
Start the next retro by reviewing the previous action items. Did everyone do what was asked? Keep pushing until the answer is yes.
💡Pro tip: take a picture of the retro board when you’re finished. It’s a snapshot in time and a record of the effort your team is investing to get better.
If you want to dig deeper, Atlassian has a great collection of resources about Retrospectives in their Playbook.
Retros are important; give them a try! They’re one of the best tools I know to evolve a team.
Get better at programming by learning with me. Subscribe to my newsletter for weekly ideas, creations, and curated resources from across the world of programming. Join me today!