People often ask me how I structure retrospectives — meetings where a team debriefs and harvests its learning. As with all of my techniques, I am happy to share, and my framework and template is freely available on this website. As a process geek, I love exploring the art of leading good retrospectives. But when it comes to most groups, I prefer talking about some of the more mundane aspects of retrospectives.
Scheduling them, for example.
First, a story. One of the hardest, most time-consuming problems in software development is finding bugs — mistakes in the software’s code. Bugs are inevitable, and fixing them takes up large chunks of a programmer’s time. When I worked in tech over 20 years ago, I met with a vendor that had an extraordinary debugging tool. It would analyze your code and automatically spit out a list of bugs. It wasn’t doing anything magical, it was just clever automation of some oft-practiced techniques.
I was blown away by the simplicity of what they had done. I asked them how others were receiving their tool, figuring that it was selling through the roof. The representative furrowed his brow and responded, “Most people don’t react positively.”
“Why?” I asked in surprise.
“When we demo our tool,” he explained, “we ask people to point it at their actual software, so that it’s working with real data. When it starts spitting out bugs, people start freaking out. They don’t have the resources to fix all of the problems it finds before their scheduled release. They’d rather not know about them.”
It was hard for me to fathom at the time, but as I spent more time in tech, I started seeing this for myself. As I transitioned out of tech into organizational work, I started seeing this manifest in a different way.
Simply put, in my experience, most teams never schedule retrospectives. If we’re being honest with ourselves, I think this is because most of us are afraid of what we might discover. Maybe we’re worried about our ability to fix the problems. Or maybe we’re afraid of negative feedback and challenging conversations. Either way, what it boils down to is that getting better has to wait… possibly forever.
When we do schedule them, they are often the first to get canceled when things get busy, which for most groups is always. I say this with the utmost humility, because this is absolutely true of me. I try really hard to be disciplined about doing them with my teams, and I’m probably better than most. But that’s not saying much, because the bar is really low, and my track record is mottled with canceled meetings.
Perhaps you’ll understand why, then, if you ask me how to lead a successful retrospective, I will often respond, “By scheduling one.” I’m not being facetious. If you’re actually having retrospectives, you’re already doing better than most.
Scheduling them, unfortunately, is only step one. Step two is integrating what you learn. As I wrote last week, people forget things at an exponential rate. It doesn’t matter how artfully you facilitate your retrospective if you’re not building in time to review what you learned, because you will likely forget all those lessons anyway. If you can’t remember what you learned, you’re not going to have anything to integrate. What’s the point of learning if you’re not integrating those lessons?
Step three (which is actually step one) is aligning around goals and success as a group. If you haven’t aligned around goals and success at the beginning of the project, then how can you assess how well you did? For most groups, the answer is generally that whoever has the power gets to decide. There’s no accountability to actual results, because you haven’t decided as a team what you were aiming for. It’s too easy to rationalize anything as success.
If you’re truly serious about learning and improving, then you are, at minimum:
- Aligning around goals and success as a group
- Having retrospectives
- Taking time to review and integrate what you learn
Make sure these are on your calendar, and protect those times.