Three Hidden Problems That can Ruin Your Agile Retrospectives

Scrum.org defines a sprint retrospective as a time at the end of each sprint where the team discusses what went well, what could be improved, and aligns on specific actions the group can commit to improving for the next sprint.

Retrospectives are an essential part of any organization running agile software development. I don’t care if you’re running scrum, kanban, scrumban, it doesn’t matter. Reflecting on how you are doing and working to get better is essential to team success throughout and morale. And when teams don’t run retrospectives, the reason is rarely about tools, or workflow or anything like that. It’s time.

Time is the biggest problem teams face when thinking about retrospectives

There are instances where teams don’t retrospect at all because they believe it takes too much time away from feature work.  And when teams do hold retrospectives, they often don’t allocate enough time to be effective, rushing through the meeting because of other priorities.  When your team rushes through, conversations don’t get to the necessary deeper level that enables true progress or learnings.

If you don’t take a step back and think about how things are going and what can be improved, how will you, your team, or your organization ever grow?

When thinking about the next sprint, teams often lump retrospective and planning together when they should be run as two separate meetings.  Retro, where you review what happened, and planning, where you take your learnings from retro and immediately put them into action.

The cost of skipping retrospectives

The problems come when you compare planning and retrospectives according to their short-term impact, rather than the less visible long-term implications.

Planning is essential. If you don’t plan at the start of a sprint, the short-term implications are bad: your scrum team runs out of work to do. Morale drops. Direction starts to fragment. Stakeholders start asking questions. The repercussions are incredibly visible.

Retrospectives feel like they’re easily skippable, because the short-term implications of skipping a retrospective are not especially visible. But I would argue that your retros are essential, and here’s why.

You skip a retrospective and things appear fine – the team still has work to do, stakeholders are happy. But you didn’t learn anything as a team from your last sprint (and you can be sure that there were things to be learned). So now you’re heading into your next sprint without a clear idea of where someone on the team might have made trade-offs, or without addressing the things that you all know didn’t go well previously.

In short, you’re all set to make the same mistakes again, or to stumble into a world of pain and edge-cases that you could easily have avoided.

My favourite analogy is that retrospectives are like eating your vegetables. Sure you don’t need them every meal, but skip them regularly and your health will inevitably suffer. By regularly incorporating retrospectives into your lifestyle, your team can grow big and strong (& smart).

How to get team buy-in for retrospectives

We understand retrospectives are the vegetables that can fuel your team to strength and good health, but how do we start actually doing them if you are not already?

Just ask

Oftentimes, engineers will be totally open to having retrospectives!  Many have worked at other companies or on other scrum teams and ideally have seen the benefits of moving from teams that don’t regularly retrospect to those that do.  Many engineers will want to actually champion the idea themselves.

Get buy in at a 1:1 level

Maybe you asked the team and got pushback, or your sixth scrum sense tells you it will not go over well.  Being a good Product Manager means knowing your team well including having an understanding of who influences who on the team, and who can be an ally.  Don’t just ask anyone, but think about who might be able to help you get buy in on the engineering team.  Many people will be significantly more open to new ideas in a 1:1 setting rather than a group discussion.  If regular 1:1s are abnormal with your engineering team, make it casual.  Go for a walk or get a coffee together.

Pull in an expert

Often organizations will have access to agile coaches.  Certain scrum masters can also do the trick.  These individuals have been trained in the magic that is scrum, are firm believers in the benefits of retrospectives, and have practiced retorts to all of the common concerns non believers bring up in terms of retrospectives.  If agile coaches or scrum masters are not available, experienced engineers on adjacent teams can often also be relied upon to get buy in for the team.

Once the team buys into the idea of retrospecting and has started to develop the habit, small problems can come up that can completely throw off how effective this practice can be.

The human problems that can ruin a retrospective

Once you’ve got your team running retrospectives, and you’ve overcome the common “not enough time” arguments, you’ll have a different set of issues to contend with. It’s still not about tools or process – now the biggest challenges you need to be aware of are social and psychological.

1. The lure of group-think

This one is easy to spot – everyone is too busy looking at what others are contributing, rather than thinking independently about what went well for them over the last sprint. As humans, we strive to a certain degree of conformity and group identity, so it’s only natural that we each try and align ourselves with what our peers think went well, or could have gone better.

There are countless retrospective formats out there. As a quick, easy, and free solution, I’ve seen teams use Google Docs or Dropbox Paper documents for retrospectives where you can see what everyone is writing in real time.  These are great for aligned collaboration, but not for a retrospective. To start with, you actually need a certain amount of hidden information.

How to solve it:  When thinking about what tool to use for your retrospective, look for one that has a feature that obscures what people are writing until it is time to share.

2. The backfiring bystander effect

In a similar vein from the group-think issue, you might find that people aren’t raising issues because they know (or believe) someone has already brought it up. They might think they’re helping by pre-de-duplicating talking points, but by stepping aside “because someone else will talk about this”, they’re actually missing the point.

Duplicates are probably the most valuable part of a retrospective, because they highlight what is truly top-of-mind for the team. You want to see those duplications coming out, because they’ll help you all focus your attention on the issues that are affecting large parts of the team.

How to solve it: Use a tool that allows duplicates on the same topic to be grouped or stacked (the joy of post-it notes!) Once everyone has entered their retrospective discussion topics and you are reviewing, grouping common thoughts is an effective way of showing what the group is collectively thinking about.

3. Fragmentation rather than focus

The team can’t clearly come to a consensus on what is the most interesting to talk about in our limited time. This might be happening because the team has unintentionally fallen victim to some version of groupthink or the bystander effect, but it might just be that there are a lot of issues that need discussion, it’s hard to know where to start, and you’re burning valuable time trying to decide.

Of course, while some teams review every item, ideally you would:

1. Have too many retrospective points from the team (suggesting that the team is really investing in the process)
2. Have a team that would rather go deep on a few topics rather than shallow on a broad amount (suggesting that your team is really committed to meaningful growth, rather than just paying lip-service to the process)

How to solve it: Voting functionality is a great feature to look for when evaluating retrospective tools. Alongside clustering of duplicate points, it’s a great way to show where the team’s attention is focused. And especially now that so many teams are working remotely, voting is essential to understand where to go deep in retrospective conversations.

A closing note on tools

While there are tons of tools out there, my favorite to date has been Retrium.  It is a great tool and, although I am not sponsored by them yet (hint hint, in case anyone from Retrium is reading 😉), it offers a few different retrospective formats and really hits the mark.

Ultimately, no matter what tools you’re using (and I’m including post-it notes in that definition), it’s crucial that you support these three key experiences:

• Let your team generate ideas as individuals
• Encourage your team to list everything, and then form clusters of shared interest
• Enable your team to silently vote on the issues they really want to focus on, so that you’re spending time having valuable conversations, not deciding which conversations are the most valuable.

No matter what your format is, make sure you retrospect. It’s a crucial practice as our teams become more distributed, and essential for any effective agile development team!