Get rid of your retrospective meetings

The end of the sprint rolls around - you know the drill. Pile into a room with the rest of the tech team for 2 hours and discuss how the sprint.

The goal of this is to action any improvements that could be made.

But that’s rarely what happens.

What happens is:

  1. People rant and don’t offer solutions.
  2. Teams assign actions/blame to people outside of the meeting
  3. Action items aren’t followed up correctly.
  4. Action items don’t always reflect where business priorities lie.
  5. A small percentage of the team dominates the conversation. Making it impossible for others to speak.

And that is repeated week in, week out.

I have seen this pattern emerge in many organisations I have worked with. And the solution was quite simple - get rid of retrospectives.

What would this look like practically?

  • No regular meeting
  • Create a group retrospective board that is the same week to week. This surfaces recurring problems.
  • Action points “open” at any one given time are capped at 3. This pushes more ownership of those changes rather than just piling them up.
  • The items raised on the retrospective board are done asynchronously via chat. This encourages less extroverted members of the team to get involved. The idea is that this process doesn’t always need to be repeated. Just as and when there are new items to discuss.
  • Once action items are decided as a priority, they are created as a ticket or task in a shared area (like JIRA).
  • Reminders are set weekly to remind the team to follow up on these action items.
  • All action items should have a few states - Done, In Progress, Outside of team scope, Not a business priority. In the case of the latter two, this means they are dropped or a workaround needs to be implemented.

Why this approach?

  1. No meetings. Meetings cost a *lot* of money. It’s total madness to block important work in favour of ranting about all the problems. In the words of Elvis Presley - a little less conversation, a little more action, please. If you’re curious about the cost, you can estimate it using this tool.
  2. All persons get an equal say. Whereas in a meeting a small minority dominate the conversation, this approach encourages all to participate.
  3. Asynchronous. If you’re a large organisation, no doubt you’re desperate to expand to other countries. But without asynchronous working practises, it will be chaos. Encouraging these practices early sets you up for success in the future.
  4. Focus on solutions, not rants. As the conversation is entirely oriented around capturing action items that line up with business goals and can be accomplished by the team; it stops conversations about how Joe in marketing is blocking work or Elizabeth in admin keeps sending requests directly to one developer. There is a place for those discussions but this is something to capture as and when they happen and escalate this through managers. A retrospective sprint discussion focuses on the action items and nothing more.
  5. Documented. Visibility to stakeholders and the tech team is important. It means we can easily go back and see recurring issues, actions taken, and if those solutions worked. This all builds towards an organisation that documents its work. All too often are retro meetings held for 2 hours, and produce nothing more than a couple of messages on Slack.

I have used this approach to great success in many organisations and I hope you can too!

Give it a try for a while. After all, no one is going to complain about missing a 2-hour meeting every other week.


What's this?
    Loading Webmentions...