What does a great engineering retrospective look like?
In my last article, I wrote about cultivating an engineering process that really works for your team. I brought up retrospectives as a key tool for doing this, a mechanism for your team to discuss what’s working and what isn’t so that they can decide what adjustments they’d like to make.
But that’s a very tactical view of what a retrospective is and does. Retrospectives can and should be so much more. If your engineering process is the heartbeat of your engineering team, your team’s retrospectives are its soul.
A brief history of retrospectives
While it’s difficult to pinpoint an exact origin for the idea of retrospectives, the ‘reflection workshops’ popularized by Alistair Cockburn in his 1998 book, Surviving Object-Oriented Projects is one obvious candidate. The idea gained a little more notoriety when it was included in the twelve principles of Agile software, proposed as part of the Agile Manifesto in 2001 (Cockburn being among the signatories). The wording that group used is likely familiar to you:
‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.’
2001 also saw the release of Norman Kerth’s book, Project Retrospectives: A Handbook for Team Reviews, the first long-form text on how to do these periodic reviews well. Kerth is often referred to as the ‘father of retrospectives’, and his book is likely why we call these sessions retrospectives in the first place. It also gave us the widely-cited ‘Prime Directive’, regularly quoted by retrospective facilitators to help establish safety among participants:
‘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.’
From there, the idea of retrospectives has grown wildly popular. Some version is part of almost every formal Agile methodology out there, and most software teams conduct retrospectives on a regular basis. But the popularity of the idea is also its downfall in that not everything teams call a retrospective actually accomplishes the goal of helping a team continually tune their interactions and processes to make them more effective.
What makes a good retrospective?
Observing the past
From a basic, tactical perspective, the most important component of retrospectives is right there in the name: looking back. For a retro to be effective, it needs to be centered around reviewing the concrete things that have happened over a certain period of time. This doesn’t mean opening your project tracker and reviewing the work you got done over that period. It’s good to know that features A and B shipped, but it’s more interesting and useful to talk about the great stakeholder discussion that cut the work required to ship feature A by 30% or the missed detail that caused feature B to be delayed. The valuable information you’re looking to learn from is not in the work itself, but in the context surrounding that work.
Building safety
The primary reason to conduct retrospectives in the first place is to continually iterate towards more effective and efficient work patterns. For this to happen, your team needs to be able to talk about not only what’s gone well but also what’s gone poorly. This is why Norman Kerth’s ‘Prime Directive’ is such an important part of retrospective culture. If not everyone on the team feels safe, it’s easy for a retro to quickly devolve into exchanges of blame and defensiveness.
It’s hard to make retrospectives safe without building an overall culture of safety in your team. That’s a much bigger topic than I can do justice to here, but ensuring you always lead with curiosity instead of judgment when something goes poorly is a great place to start. Help your team embrace the idea that problems and failures are to be learned from, not punished, and guide blame-oriented conversations back towards a learning mindset.
Embracing feelings
There’s a prevalent belief in many countries that feelings and emotions have no place at work. We’re there to do a job, after all, and how you feel about your job shouldn’t affect your ability to do that job. The problem with this stance is that humans are anything but rational actors, and our feelings have everything to do with both our ability to do our jobs and our desire to stay in those jobs. To pretend otherwise is to deny reality.
If you’re leading a team, the feelings of each individual on your team and of the team collectively are critically valuable information for you as a leader. Engineering work is cyclical, and every team oscillates between periods where it’s shipping rapidly and feeling on top of the world and periods when projects are dragging on, next steps are unclear, and nothing seems to be going right. Making space to talk about these feelings in your retros brings them into the realm of common experience where the team can cope with them collectively and figure out what steps might prolong the good times or get them unstuck from the bad times.
Conducting a great retrospective
The actual mechanics of conducting a retrospective well are as simple as they are varied. There are certain things most good retrospectives have in common, but really there’s no right or wrong way to work through those things as long as you get your team talking about things that matter. In general, most retrospectives will have:
- What went well – What are the things that went well or that we’re particularly happy about during the period in question?
- What went poorly – What are the things that didn’t go as well as we hoped?
- New ideas and solutions – What are some things we might try over the next iteration to improve the way we work together, either by doubling down on something that went consistently well or adjusting something that went poorly?
- Commitments – Of all the things we brainstormed in the new ideas and solutions section, what one or two things do we want to actually commit to implementing?
If your team works together in person, you might have folks write their contributions down on sticky notes and stick them to the wall. If you’re distributed, there are ways to cobble together a retro using almost any tool that allows real-time collaboration, or you could opt for a purpose-built remote retrospective tool. You can discuss ideas in real-time as they’re shared, or you can give everyone time at the start of the session to get all their ideas out and then discuss them as a group. There’s no one right way.
As the leader, your role is to help focus the discussion around ideas that are particularly interesting or resonate with the group while also keeping the team away from blame and finger-pointing. When you’re first starting out, it can be helpful to add an anonymous section to the retro to help the team feel safe raising topics that feel riskier to them. As safety and trust build, this piece will become less and less important.
Once you’ve gone through a few retros together, it’s also a great practice to have other people on the team rotate through the facilitator role. Each team member will guide the conversation in a slightly different way, leading the team to focus on new and different things and surfacing different insights.
Iterate, iterate, iterate
Like engineering processes, the right retrospective is going to be a little different for every team. The Retrospective Wiki is a great source for retrospective format ideas, and you shouldn’t be afraid to try different ones until you find one that really works well for your team. Likewise, don’t hesitate to change formats if your tried-and-true approach starts to feel a little stale.
In the end, few things will accelerate your team more than regular, productive retrospectives. They’ll give folks a sense of empowerment and control over their own work practices that will spill over into everything they do, yielding better software and a happier team. They’ll bring resiliency and camaraderie that help you make it through the bad times and celebrate the good times together. Now that’s worth investing in.
