Your retrospective is useless

Of course, it’s not useless! But there are things you should avoid. But let’s take a step back.

Retrospectives are pretty standard in tech companies, and they serve a great purpose: helping teams improve over time and learn from their mistakes.

However, over the years, I’ve seen many companies run them incorrectly, and by doing so, they lose all the benefits they provide.

Following are some of the most common mistakes I’ve seen, and some very opinionated ways to avoid them.

Icebreakers

Retrospectives are time-bound. You generally have a 1-hour meeting every N weeks, depending on your process, and that’s it until the next occurrence. So it’s very important to value that time and focus for two main reasons:

  • The sooner you identify problems, the quicker you can fix them, the better for everybody
  • All the team members join the meeting, making it one of the most expensive in a team lifecycle

Icebreaker activities are fun and help people get to know each other, but a retrospective is usually made up of people who likely already know their teammates. Furthermore, icebreakers don’t add anything useful to the future conversation.

What you should do

The strong (and my preferred) solution is to do absolutely nothing. You can schedule a fun time for the team in appropriate meetings. On the other hand, in remote setups or with brand-new teams, a 2-minute chill moment can improve the quality of subsequent discussions. Make sure to be very strict with time.

Focus on what went well

It’s quite common that retrospectives end up with both positive and negative items. Another important issue I noticed is giving too much importance to the positive ones.

Discussing and giving kudos to people is valuable because it manifests that things are working correctly, but that’s not the goal of the meeting! If you spend more than half of the retro discussing how well the team behaved, we’ll have insufficient time for corrective actions.

What you should do

There are two possible directions to mitigate this issue.

First, you can schedule an ad hoc Kudos meeting where people can praise others for the work they’ve done. That’s a wonderful moment, especially if you end up being appreciated. It recharges you.

As a second action, remember to tweak your retrospective format. It should have space for the happy points, of course, but more prominent space for the pain points. The real value of the meeting is to take on problems.

Try discussing everything

Let’s come now to the discussion phase. Depending on the team size and the number of items, there might be too many to discuss. Some teams still try to do it, maybe spending more time on a minor issue and realizing only in the last two minutes that they’re actually uncovering the elephant in the room, but too bad, time’s up!

What you should do

  1. First of all, group the similar items. If two different sticky notes look like the same, ask the authors, and if they agree, they can form a cluster (to which you can add other similar stickies, if any).
  2. Briefly explain the newly formed clusters, so everybody is aligned on the problem.
  3. Make people vote. For example, assign each participant a maximum of 3 votes and let them vote for the stickies they consider most problematic. They can also do all-in on a single problem, if they want to.
  4. As the last step, depending on the time at your disposal, take the N top-voted items (usually the top 3) and talk about them.

With these simple steps, your retrospective is now much more effective!

Do not create action items

Alright, at this point, your retrospective is almost perfect. But when you reach the end of the meeting, you say “Hi” to each other, and everything gets forgotten. Why? Because nobody wrote anything about the future steps, and as they say: “Verba volant, scripta manent”. Or in other words, motivation alone doesn’t stick.

What you should do

Every sticky note that you discuss should have an action item attached. An action item is something that someone should do to mitigate or completely avoid that problem in the future.

The above is still not enough. Treat your action items as other tasks on your board and track them. Of course, they won’t have the same priority as feature work, but sooner or later, they will be done.

Do you want one more? Give each of these retro items a deadline and an owner. It could be 30 days or even longer, but this way, if taken seriously, they will be treated with care, and you will have someone responsible for them.

Conclusion

I know, this might sound too harsh or strict. But I spent too many hours in retrospective meetings without having the benefits they were intended to have. Some companies run them because “that’s how agile works”, but without understanding the real value. Others simply needed a good facilitator.

Whatever the reason, I hope this post brings clarity and that you can now start to fully benefit from them.