It’s not about what you did. It’s about what you’re going to do.
I’ve had plenty of opportunities to observe misinterpretations of agile practices, and retrospectives are near the top of that list. That’s too bad, because the retro is an essential tool for continuous improvement.
We’re big on mindset shifts here at Sketch, and we know that realizing the value of retrospectives, begins with thinking about them correctly. Specifically:
Retrospectives are often mistakenly portrayed as the agile version of the “lessons learned” or “postmortem” meetings that cap off traditional projects. There are a couple of problems with that view.
First, when project teams are frequently assembled and disassembled around projects, “lessons learned” are likely to just get shunted into a folder, never to be seen or heard of again. And with team composition constantly in flux, there’s no real opportunity for learning.
Secondly, the very term “postmortem” is an indicator of the mindset that underlies that exercise: “Something has died. We’re going to look at it, but there’s nothing we can do now, so we’ll just move on.”
To be fair, even in an agile workflow visual – Scrum, for example – the retrospective typically shows up at the end of a repeating series of steps or ceremonies. And since “retrospect” does mean “to look back”, it’s not unreasonable for people to focus on looking back.
But retrospection is just part of an agile retrospective.
What has happened supplies the raw materials for agreement as to what will happen going forward. You can think of the past as the “why” for the future “what”. For example, one “Keep doing” outcome of a retrospective might be “We will always pair new team members with experienced team members (what), because pairing new team members with experienced team members has proven to speed knowledge transfer and technical upskilling (why).”
The “what”/”why” relationship works the same way for things we will “start doing” and “stop doing”.
At its core, the retrospective is a conversation that helps us use the backdrop of the past to understand what we need to do to improve for the future. If you don’t come out of a retro committed to specific actions for getting better, you’ve only looked backward. And you won’t improve.
If any of this resonates, it probably means that you’ve at least taken the first step to valuable retros: you’re having them! Hopefully, you haven’t been taken in by the notion that retrospectives are optional.
One of the biggest faux pas that I see is teams (and leaders) treating retrospectives as optional. In some organizations, that makes perfect sense: If all you ever do in a retro is mull over what’s already been done, it probably seems like a waste of time that would be better spent “working on something”.
“Optional” can also mean “only as needed.” As you might guess, “only as needed” usually means “something is on fire, and we need to try and fix it now.” That’s hardly the setting for thoughtful reflection and discussion.
Even if retrospectives remain cadenced on your calendar, a surefire way to know your retros aren’t valuable is if people aren’t showing up. Cancelling retros outright just wouldn’t be “agile” (one might think), so the middle ground often ends being to make retros optional. And since other meetings are just waiting in the weeds to pounce on any non-committed calendar time, optional retros soon become no retros.
The retrospective provides a venue for transparency, inspection, and adaptation regarding the way teams go about working together to deliver value. That is critical to the health of your team and your organization. Metaphorically speaking, it’s how the organization detects pathogens, fights them off, repairs itself, and protects against future infections, all while keeping the healthy processes going.
If you’ve made retros optional because they aren’t valuable, kick them back into gear on a cadence and make sure they provide the opportunity to stay healthy and get stronger.
Most people think of retros as part of a framework, where they occur on a cadence. Cadenced retrospectives are absolutely one indispensable means of ensuring that the necessary process transparency, inspection, and adaptation happen.
But retros aren’t limited to the cadence prescribed by one framework or another. In addition to the cadenced retrospectives, you can have a retrospective on virtually anything, with the appropriate assemblage of people. For example,
As with cadenced retrospectives, trust the collective intelligence of the assembled group to have candid conversations and to come up with innovative improvement ideas.
Organizations are at different points on their “agile journey” (it never ends, by the way). It can take time for people to get used to being empowered to improve things, and for the organizational culture to embrace that empowerment.
The retrospective plays a key role in cultivating the continuous improvement culture. Three keys to maintaining effective retros are to:
The best way to gauge whether you have the right mindset around retros is by looking at the outcome of the retro itself. If your team is creating a backlog of improvement items (you can think of them as experiments) and committing to acting on the most important one or two of them before the next retrospective, then your retro is doing what it should.
If your retros stop catalyzing improvement, or they stop happening at all, that’s when it’s time to reinvent or revisit how your Scrum Masters are facilitating those retros.
There are many effective ways to facilitate your retros, and it is well worth learning a few and mixing them up a little. If you want to learn some of those methods and start completely re-imagining your retros, I highly recommend Sketch’s free webinar facilitated by agile coach James Nippert, “Crafting Retros Your Team Can't Wait To Attend.” His advice will help you craft retros that your team will want to attend, which will keep you on the path to continuous improvement.