On The Inside: Agile Retrospectives: Worth the Hassle?

Welcome back to On The Inside! This is part 7 of my Agile adventure at Allthings, a technology startup in sunny Dundee building a group project collaboration tool. If you haven’t read part 1 (which is all about diving into the deep-end!) then you can find it here (you can read last weeks here). I’m trying to give an honest, personal, warts-and-all account of our journey…

The retrospective can be an opportunity for the whole team to look back and reflect on what they’ve done and how they’ve reached a certain point together. It’s a meeting the whole team has at the end of a cycle in an Agile project to identify any improvements which could be made. It’s also an opportunity for everyone to come up with actions on how to implement those improvements.


This meeting is a key part of the agile process and it can be the heartbeat powering the team to strive for improvement iteration after iteration, milestone after milestone. A healthy retro can empower and motivate your team.

However, a bad retro can destroy morale and create tension between team members. It can also be a colossal time suck and a moan session to managers – one of the most painful meetings in the Agile calendar. If you’re not getting any value from your retro the temptation is to skip it, but your team will be missing out on a valuable opportunity to realize their potential. With the right skills and preparation you can avoid missing out on such an opportunity.

So how should a retrospective work?

The retro should be a chance to talk about how you worked together and how you can work together better in the future. It’s important to talk about and celebrate what went well while also talking about what didn’t go so well. It’s even more important to create a safe environment where it is OK to talk about what went wrong honestly and openly. If issues aren’t getting aired then the team won’t be able to find solutions for the problems.

A team that can feel and see their work method improving will very quickly take ownership of their own approach to work and drive improvement in quality, performance and morale each iteration. They will look for opportunities to improve even tiny parts of the process and these can aggregate up to major improvements in productivity.

The key to the retro – and Agile – is empowering the team. Creating a space where the team can openly discuss what’s wrong without it being held against them and having the space to decide together how best to fix it will empower them. They’ll feel like they own their own approach to their work. It will be their problem to be fixed. Then it’s the manager’s job to support the team by making sure they have the time and resources to fix any problems.

Simply being listened to is extremely motivating for a team – for myself personally, it’s the power behind the upward spiral of improvement that leads to high performing and self-organising teams.

When To Do It?

For the retro, you have to find the right date in the calendar. The natural place is after the sprint has finished and just before the planning meeting. That way, you will have hopefully finished all the work in the sprint and can discuss what’s happened during it – any actions it generates can be incorporated into the following sprint plan.

It’s very much what works for you and your team but I like to have the retro on the last afternoon of the sprint and then have the sprint planning the following morning. I used to have both meetings on the same day but this can lead to a long planning day where everyone gets tired. Splitting the meetings over two days helps maintain energy levels.

If you’re interested in learning more about the sprint planning process, you may find this article useful: On The Inside: Fail to plan and you plan to fail

I’ve experimented with many different approaches to the retro. I would recommend you also do this, as you might find that some just don’t work for you and your team. Experiment with them. Mix them up, keep them fresh and take suggestions from the team on what would make the retro better. Do whatever you can to make this a fun, exciting meeting and not get bogged down with all the things the team still has to fix.

One technique I’ve used and found to be a success went like this:



1. Canvas opinions and concerns

• Write “What did we do well?” and “What could we do better?” on a whiteboard and pass out post-it notes to the whole team.
• Everyone spends 5-10 minutes silently writing answers to each of those questions and sticking it on the board. This gets everyone contributing all at once.


2. Analyze what you find

• Going round the room, each person takes a turn reading out a post-it and the team explain and discuss what it means. The key here is to keep the meeting inclusive and flowing quickly. Don’t let it get bogged down on one sore point. Keep it moving.
• When each card has been read, the person holding it puts it in a group with other similar cards or creates a new group for it.
• As a team, check the groups are roughly correct and the names are suitable.


3. Focus on solutions

• Take each group in turn and quickly brainstorm what could be done to solve a problem area. If the solution isn’t obvious, make the actions a spike to investigate for potential solutions.
• As a team, pick a solution and create an action for it.
• Cost and schedule the actions. Don’t let them slip out of the sprint for other work. Almost all of the improvements require some time out of the sprint – especially if it’s something technical. I’ve found that the only way to make sure we stick to our actions as a team is to make stories out of them for scheduling, preferably in the next sprint. That way, the team actually implements any improvements instead of allowing them to be squashed the out of the sprint by other work.


4. Follow up

• All cards are written up and emailed out in their groups with the actions after the meeting. This is especially important when you have multiple teams doing retro at the same time and in different locations. Using that email I could have a quick meeting with team leaders to discuss problems particular to their team after the retro and flag up anything that required more attention.
• Make sure you read the list of actions from this meeting at the start of the next. This helps reinforce that the meeting is important and what’s decided during it is valued and will get done.


I’d really like to hear from you how you do your retrospectives. I’m always on the look out for something else to try and I’d love to hear what works for you. As always, if you have any questions about my retrospectives or would like further advice, please leave your questions in the comments below or you can contact me either on twitter at @allthings_io or via email at peter.gordon@allthings.io Thanks for reading!