Benjamin Chait // October 2021
This document is a collection of notes and suggestions for approaching retrospectives, also called retros.
A retro is NOT conducted as a response to a feature launch or incident; those are learning reviews and have different objectives.
Retros are a tool to help a team assess its ways of working. It must be conducted as a safe space for any individual to ask questions, make suggestions for improvements, and for the team to understand what went well and what could be improved as this team continues to deliver software together.
Retrospectives should be planned and scheduled at a regular cadence. This could be aligned with a sprint schedule (eg. a retro to coincide with every two-week sprint) or for teams working in kanban, retros should be regularly-scheduled (eg. every two weeks).
Everyone on the delivery team should be invited and included as a participant. Retros should not include stakeholders nor individuals not directly involved in delivery.
One individual is tasked with facilitating and leading the retro. This can be an engineering manager, a product/project manager, or someone indirectly involved in delivery. This person must be aware of their involvement, and their objective is to support the team during the retro.
Some teams prefer structured retros. These can include a pre-built board using a tool such as EasyRetro. While acceptable, I’ve noticed relying on specific tools often separates a retro from the day-to-day work. If you choose to go this route, the “Went well / To improve / Action items” format has worked for my teams in the past; and the facilitator gets to configure some choices within the tool.
I myself prefer a simple document (eg. Google Doc) with three sections: The Good, The Meh, and The To-Be-Improved [example doc]. This doc should be shared with every participant having Edit access.
Each retro should start with the same prime directive:
“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
I like to read that out loud to set the tone for our discussion. I also remind people that we’ve booked 60 minutes* for our time together, but that we’ll end early if no further discussion is warranted.
If anyone is new to the retro, I take a moment to describe our process: We’re going to review three topics/themes, one-at-a-time. Once the team has written some commentary, we’ll look for themes and discuss.
When we’re ready to begin, I time-box the first section (“The Good”) to five or ten minutes; and tell folks they have “until [10:15 am]” to write some comments. This is a good opportunity to remind participants that it isn’t about blame, and it’s okay if multiple people write something — we care more about capturing ideas here, and later we’ll group themes/topics.
While participants write, I often go on both video mute and audio mute; and chime-in with a minute or two remaining.
Repeat for the next two sections. As facilitator, this is an opportunity to group like-for-like topics; never delete or add your own content, but re-arranging might be helpful!
Once your team has written feedback for all three sections, I also ask people to give a “+” beside the section that best represents how they felt about the last few weeks. I use this as a gauge for team health, and typically notice the team is pretty positive here.
Now that we have some discussion points, I give the team a few minutes to read ALL of the written commentary. I encourage folks to add new thoughts if they have them, or to simply add a “+” beside any topic that resonates with them. And I also remind folks that they’re empowered to group themes/topics or change the retro notes, so long as they aren’t deleting something they themselves didn’t write (additions are always welcome). Like other activities, give a time-box and call-out when we’ll regroup (eg. “let’s spend seven minutes reviewing this, and we’ll discuss as a group at 10:25 am”).
When you’re ready to discuss, I try to go line-by-line to acknowledge every topic. This will take a long time, especially on your first retro. Taking the time early on helps the team learn this habit; and if the point is to foster and encourage discussion, I think it’s an incredibly valuable investment. As a facilitator, a few things to consider:
- Are you building a shared understanding of what happened?
- Are folks casting blame? If so, how can you redirect/refocus the conversation to what’s within your team’s sphere of influence?
- Are you talking in circles? Time to move on!
- Can you (as facilitator) add notes as your team discusses? These make for great action items.
Once you get to the end, I like to call-out any action items and assign both owners and ask them to commit to a date by which they’ll attempt to tackle those tasks. Write that down!
And lastly, if time permits, I ask if anyone has something more to share — it could be something they forgot, something they’re now thinking after the discussion, or even something they learned. Those are great!
Finally, thank everyone for their participation; and remind folks about the next time y’all will be conducting a retro.
- I start with 60 minutes for the first retro (or three) until the team naturally gets into a cadence of 30-minute retrospectives. From my past experience, the first two or three retros will require the most time; after those, I’ve found my teams more naturally approach continuous feedback and talking about our ways of working throughout our delivery process.
As soon as a retro concludes, publish your notes in a shared place (eg. Slack channel). I continue to keep these notes only visible to those participating in the retro, but want to make them easy to find.
When a retro concludes, I try to have the next retro date and time identified (and booked on calendars). This is easy if it’s part of a two-week sprint, or on some sort of regular cadence. Regardless of how you do this, giving folks a gentle reminder that we’ll be back in [x] weeks is helpful for building this as a team habit.
Maintaining a single shared retro notes doc can help with building this into your team’s delivery approach. I prefer this as compared to spinning-up a new doc with each retro, or creating a new ‘board’ within a third-party tool — either of those practices requires you to also manage your various retro links, which can add complexity/takes effort for people to look back at prior discussions.
And lastly, you should always ask this question about your retros themselves: Are they serving the purpose this team needs? If not, you have an opportunity to change your process and approach :)