Most startups working in cross-functional teams tend to have retrospectives.

But they are also sometimes deprioritised and either skipped or cancelled. But I think they are one of the most, if not the most important meetings for a team to have. Without a retro, you can get stuck in working in the same way, and not improving.

What are sprint retrospectives?

But first, let me start with an explanation of what sprint retrospectives are!

Often just called retros, they are a meeting that teams often have every couple of weeks or so. They are used to look back at how they recently worked on a project, how it was delivered, and how they can improve.

A typical format is like this:

• 1 hour meeting
• Everyone from a team joins (engineers, design, product, QA, and (sometimes) relevant stakeholders etc)
  • Either online (with tools like teamretro.com)
  • or in real life, often with a whiteboard and post-it notes
• Board is split into 2-4 sections, such as:
  • Start/Stop/Improve:
    • Start (ideas to start doing new things)
    • Stop (actions that the team should stop doing)
    • Improve (how can the team improve)
  • Or something like:
    • What went well
    • What went badly
    • Shout-outs
    • Ideas

The meeting itself will often run through these steps:

• Step 1: Review last retro actions
  • Look at the previous retro. Were there actions to be done? Review them, and discuss if they were done or not.
• Step 2: everyone writes ideas
  • e.g. "delivered X on time" (went well), "lack of initial planning on X" (went badly), "Y did a good job of collecting API specs" (shout-outs), "Next time let's have a kick-off session" (ideas)
  • They can write as many ideas as they want.
• Step 3: Group the ideas
  • Multiple ideas (even from the same person) are likely very similar, so it makes sense to group them at this stage.
• Step 4: Vote for groups
  • Everyone is given some votes (e.g. 5) and puts their votes on the items they want to discuss.
• Step 5: Discuss groups
  • For the remainder of the meeting, discuss each group. Start with the ones with the most votes.
  • Some items just need a simple discussion. But some are going to include ideas on how to change your ways of working for future sprints. These should be logged as actions, and ideally assigned to someone. These should be completed by the next retro. (See step 1 - you should always review the previous actions).

Common Reasons for Skipping Retros

For a team that is valued on the number of features or releases they deploy (without focusing on improving how the team works), retros can be hard to justify.

You might hear something along the lines of "Why spend an hour talking about what we delivered? We could be coding and releasing features instead".

Or maybe there are objections due to a never-ending list of actions which are never completed.

Even on well-structured and well-performing Agile teams, occasionally you can hear "We love retros, but are swamped by $big-project this sprint - let's skip the retro this sprint".

Some people just find retrospectives dull. I disagree personally, but I can understand why some see this as a waste of time.

Some people don't feel they can speak up about their team. This is a much bigger issue than the previous ones I mentioned. If you have a toxic team, I could imagine that suggesting 'things to improve' could be hard if there are certain personalities in the team who have no time or fight back against criticism about how they work. This is something which needs to be fixed (outside of a retro) and is out of the scope of this blog post.

But why do I think retros are the most important meeting?

The Importance of Sprint Retrospectives

In a typical team following an agile/SCRUM methodology, you often see the same sorts of meetings. And everything is split up into sprints - often 2-week periods where teams work on delivering specific work within that time.

• Daily standups
  • A daily call (often in the mornings) to discuss what the team is working on & if there are any blockers to those things
• backlog refinement
  • Once per sprint, go over upcoming tickets and ensure they are written up, understood, and ready to be worked on
• Sprint planning
  • Before starting a new sprint, go over tickets (already refined) and bring them into the next sprint so people know what to work on
• Sprint review
  • Demo/discuss the work that was delivered in a sprint. This is a meeting with stakeholders and others in the business, to show and get feedback on what they've worked on

And of course, the meeting I am discussing today:

• Sprint retrospectives
  • Meeting with the team to look back on how they worked in the previous sprint, and how they can improve in the future

I think that you can get rid of the other 4 main meetings and work will still be done. (Tickets will somehow get assigned, and people will work on them)

But nothing will improve. And this is the key thing.

I've worked on great teams, very effective - but there are always things to look back on and improve for the future.

If the only meeting you have is a retro in every sprint then over time your team will end up bringing up ineffective ways that the team functions (and hopefully offer ideas on how to improve).

How to ensure actions don't get ignored

One issue that can come up is that you can have retrospectives, and come up with lots of actions... but then nothing else happens. Everyone is too busy to do the actions, and they sit there waiting to be reviewed again and again (still incomplete) every time you do the next retro.

This can then lead to it seeming like retros are not productive as nothing gets done.

Firstly I think retros are good for a team to celebrate successes as well as how to improve. So even if you just end up with a backlog of actions which are never actioned it can still be good for the team. I think this is even more true for fully remote teams, where you don't have that 'water cooler chat' as much.

But actioning the actions is still critical to making good use of the retros ;). I've found one way to avoid this is to assign them to specific people (and if they are too general to be assigned to someone then don't list them as an action), create a ticket in Jira for it, and follow up with that person mid-sprint to make sure these actions are done.

Maximising the value of Retros

It is easy for a team of 5-8 on the team to come up with enough topics in a retro to fill up a 2+ hour meeting. But honestly, 2 hours is probably a bit too much every sprint.

It is important to have someone run the retro - and they must be careful of watching the time. If you end up in a 15-minute discussion about something, they should draw the discussion to an end for that item. Take the discussion offline, or set up a separate meeting for it.

Retros should be fun

Retros with a team that has gelled should be fun.

Unlike the other meetings (focusing on delivering work) a retro is about the team members and how they work together.

The team should embrace improving their ways of working, and if everyone feels safe to share their opinion these meetings can be fun. The real benefit, of course, is the outcome of the retro - and how you can improve the team's ways of working.

How to measure the success of retros

I've been in good and bad retros. The worst retros are honestly a waste of time. No one has anything to contribute, people are hostile and argumentative, vague actions (if anyone), and people dread going to them.

On the other hand, great retros tend to have these:

• Previous actions were (mostly) completed
• Someone runs the retro and keeps on top of timing and moving the retro along
• Team members come prepared, with ideas of what they want to add to the board before it begins
• Ideas/grouped ideas are succinct and easy to understand by everyone
• The team easily agrees on how to group items
• All ideas are spoken about, giving time to the ideas people want to bring up
• Actions are assigned to specific people, and they are always easy to define what they are and how they can be marked as done.
• And the most important thing - the team evolves and improves their ways of working