Start Your Retro by Reviewing the Last One

At the end of most retrospectives, the team has a whiteboard full of “Ideas for Improvement.” At the start of the next one, that board has been erased and nobody mentions it again. I believe every retrospective should begin by reviewing the action items from the previous one. Without that step, a retro is just a recurring meeting where the team complains about the same things every two weeks.

Where do the ideas go?

I recently asked my network on LinkedIn whether their teams review the last retro’s “Ideas for Improvement” to gauge progress. My answer is yes, and I think it should be yours too.

Consider a typical retro. The team splits the board into a few columns, something like “What went well,” “What didn’t go well,” and “Ideas for improvement.” Everyone writes sticky notes. The team groups them, votes, and picks a few things to try in the next iteration.

Then the meeting ends. Maybe someone takes a photo of the board. The sticky notes go in the trash.

Two weeks later, the team gathers again and starts from a blank board. Some of the same complaints show up. The build is slow. Stories are too big. Code reviews sit for days. The team writes new ideas for improvement, and they look a lot like the old ones.

If nobody asks what happened to last time’s ideas, the honest answer is that nothing happened to them.

Venting without follow-through

There is real value in letting a team say what is bothering them. A retro should be a safe place to do that. But if the conversation stops there, the team learns a bad lesson: the retro is where you complain, and complaining doesn’t change anything.

Once a team learns that, retros go one of two ways. They get quieter, because people stop bringing up the hard problems when they don’t expect anything to come of it. Or they get louder, and turn into an hour of venting that leaves everyone a little more frustrated than when they walked in. Either way, the team has stopped improving, and improving was the whole point of the meeting.

The fix is simple. Close the loop.

Open with last retro’s action items

Before anyone writes a new sticky note, pull up the action items from the previous retrospective. Go through them one at a time and ask a simple question: did we do it?

Each item ends up in one of a few places:

• Done, and it helped. Say so out loud. The team should hear that the retro works.
• Done, and it didn’t help. That’s useful too. Talk about why, and decide whether to try something else.
• Not done. Ask why, without blaming anyone. Was it too big? Did nobody own it? Did something more important come up? Then decide whether to carry it forward or drop it.

That last decision matters. Dropping an item is fine, as long as the team decides to drop it. Letting it quietly disappear is how the board fills up with the same ideas every two weeks.

This doesn’t take long. Five or ten minutes is usually enough. If you are familiar with Esther Derby and Diana Larsen’s Agile Retrospectives, this fits nicely into the “Set the stage” or “Gather data” part of the meeting. Last retro’s action items are data. They tell you whether the team’s process is actually changing, which is the thing a retrospective is supposed to find out.

Make the action items reviewable

Reviewing action items only works if the action items can be reviewed. “Communicate better” can’t be checked off. Neither can “write more tests.”

Here are a few guidelines I like to follow when writing action items:

• Make it specific enough that you’ll know whether it happened. “Pair on every story that touches the billing code” instead of “share knowledge.”
• Give it an owner. One person, by name. The owner doesn’t have to do all the work, but they are the one who reports back at the next retro.
• Keep the list short. One to three items is plenty. A team that commits to ten improvements will finish none of them.
• Write them down somewhere that outlives the meeting. A wiki page, a card on the team’s board, the top of the next retro’s agenda. Not a sticky note.

Specific, owned items are easy to review. Easy to review means the review actually happens.

A retrospective is supposed to make the next iteration better than the last one. You can’t know whether it did unless you look back.