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
2. Analyze what you find
3. Focus on solutions
4. Follow up
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 firstname.lastname@example.org Thanks for reading!