If you're not looking back, you're not learning
How retrospectives taught me this the hard way
Bad retros = bad outcomes
Early in my career, I hated retrospectives.
Every two weeks, the team went into a room and moaned about various things, and worse, various people, that were “getting in the way”. The meeting would quickly descend into backbiting about other folks who weren’t in the room, leadership, and several other issues external to the team. The one thing that was never held accountable was the team itself.
The PM who led these retros seemed powerless to do anything to arrest this pattern.
We tried several different formats.
Stop/start/continue
The sailboat
The island
Five whys, and many more.
At first, we felt slightly unburdened. After a couple of months, we just felt frustrated.
Nothing seemed to help. Every two weeks, we did the same thing and we got the same results. No internal inspection. No action. No improvement.
The people who could potentially help address some of these issues were not invited to a discussion and never had any feedback shared with them. I later found out that one engineering team was having retrospectives without product in the room. Guess who the majority of their complaints were about?
In the end, I couldn’t abide the learned helplessness or the impotent frustration. I hated retrospectives, to the extent that when I got my first PM role, I tried to survive without them. I couldn’t conceive of putting myself or a team through that experience again.
No retros = bad outcomes
It was a disaster.
The team worked well enough, but without a ceremony to raise concerns, the team got just as frustrated as I had in my previous organisation. People were having side conversations, and getting frustrated with one another, with me, and some wider organisational issues. All of the behaviour I had hated in retros from my previous role was still happening - it was just now happening outside the meeting, uncontrolled, stalking the team’s morale and togetherness.
One day, one of my most senior team members gave it to me straight. The team wanted and needed to have regular retrospectives.
So I cracked. With no small amount of apprehension, we scheduled our first retro.
Given my historic experiences, I wanted to be open about my concerns. We did an icebreaker where everyone had to share one hope and one fear for the meeting or more generally about the work of the team.
My hope was that the team felt safe enough to be honest with each other and to have some difficult conversations. My fear was that this ceremony would turn into a talking shop, which was the kindest description I could think of for my previous experience.
Then we used a simple Stop/Start/Continue format, similar to that which had failed in my previous organisation. We opened up a board, and reviewed the most recent work done by the team, what had gone well, and what issues we had that needed addressing.
Good retros = good outcomes
As we reviewed the ‘Stop’ items, someone started to complain about how our dependencies weren’t being addressed by another team. My stomach tightened as I felt the pattern of my previous organisation’s retros threatening to emerge. Instead of letting it slide, I asked: “What could we have done differently to get that resolved or surfaced earlier? The energy in the room shifted. We weren’t victims. The situation we were in was only out of our control because we hadn’t taken control. We could see what we should have done differently, and agreed how we would approach this in the future, committing to a new way of behaving then and there.
It was amazing.
The team drilled into a recent failure we had experienced, where we had introduced a bug to our application that was causing a significant customer issue. We had scrambled on it, identified the root cause, which was a side effect of an uncovered edge case from a change that had been introduced 14 months earlier.
We identified some gaps in our approach to testing that would hopefully address similar cases going forward. We talked about how some external work had come in recently and blown the team off course. We debated whether this incident should impact the team’s DORA metrics, given the age of the code that introduced the bug to the system. We usually only looked back a year at most for our metrics. How should we acknowledge the impact of something that happened over a year before? In the end, we agreed to adjust the historic data to allow for the issue having happened. Ignoring it because of its age felt dishonest.
These decisions fuelled the team to ever-greater heights as they were able to acknowledge concerns, understand how to correct for them, and to hold themselves accountable for their performance.
Having unlocked the power of the retrospective, the team kept up this important ceremony so that it could learn, adapt and thrive. We quickly iterated to a structure that worked for us in ensuring that we got the most out of our retrospectives.
Icebreaker
The Prime Directive
Actions since the last retrospective
Retrospective activity
Affirmation of open actions and an agreement on who was responsible to complete them
Thank everyone for participation
In summary
Inspection, learning and adaptation are key to agile product management. Retrospectives are a vital tool in the product team’s armoury, but they need to be respectful and respected. Retros without action are talking shops. Actions without retros are fumbling in the dark.
How to make your retros useful
Remember the prime directive
In order to focus people on actionable change, it’s always good to start a retro with a reminder that everyone did the best job they could with the information available to them at the time. Retros shouldn’t become blame games or deflection zones. It’s important to develop the muscle to have honest conversations about what could be improved without assigning blame for past issues.
Use an icebreaker.
To help guide people, or to create an appropriate air of vulnerability, it’s a good idea to use an icebreaker to settle people into the meeting. Doing something fun or lighthearted can set a positive tone. Showing some vulnerability at the start of a meeting will demonstrate to your team that you’re ready to listen and engage.
Allow open debate (within reason)
It’s important to ensure that everyone has a voice in the retro, and no topic should be considered off limits. Encourage everyone to speak up, and don’t let the loudest voice dominate any debate.
If things are getting heated or people start disappearing down rabbit holes, there’s nothing wrong with suggesting a separate meeting to dig in further on this issue. This can give time for calm to prevail. If you do decide to ‘take things offline’ then make sure the debate is surfaced in another call with the relevant folks. Few things destroy psychological safety in a team as quickly as a sense that some things are not to be talked about.
If you get the impression that people are grinding axes rather than focusing on how to improve, you’ll need to call that out. If you’re confronted with what looks like a chronic complainer, then make sure they become responsible to take actions that can help address their complaints. When working with another team, one person regularly complained about unclear requirements. When they raised this in a retro, I asked them to take responsibility for creating a requirements checklist we could use going forward. The complaints stopped, and our process improved.
Engage with humility
Speaking of which, some topics are going to be raised, and some things are going to be said, that make you uncomfortable. You’re going to need to lean into that discomfort, show vulnerability and curiosity when the topic turns to your behaviour or a belief you hold dear. It’s important that you model good behaviour by being responsive to feedback and asking open questions when you are being challenged.
Don’t skip them
Build a cadence of regular retrospectives. It can be tempting when you’re busy, or when things seem to be going well, to skip retros. This is a mistake. Not giving the team time to review and discuss issues leaves wounds to fester. Even if the team shows up and agrees everything is going swimmingly, you’re showing the value you place on giving them a safe space for feedback.
In order to build the team’s skills, it is a good idea to cycle through team members as facilitators. Occasionally, say, at the end of a particularly large piece of work, or if there’s a particularly knotty problem the team is trying to unlock, ask for an external facilitator so that all of the team can focus and make their voice heard on the issue at hand.
Take action
Most importantly, if you agree you’re going to take action as a result of issues surfaced during a retrospective, follow through. Trust is built through consistency. If the team see that you’re not willing to follow through on certain actions, they’ll not be able to trust your word. Make your word your bond or watch your team stop believing anything you say.
The truth is, I never hated retrospectives. I hated feeling powerless, and being stuck in a place where I wasn’t heard. Retrospectives are how you make your team feel heard. Don’t silence them.