Retrospectives – the most important Agile meeting!

Much is made of some of the agile ceremonies – notably standups, even though they often done completely wrong – but sadly in many teams if it’s perceived that time is tight, the first meetings to be dropped are retrospectives. Unfortunately it’s quite rare to see effective retrospectives, which is often a reflection on organizational and team culture. Retrospectives are quite simply the team’s structured opportunity to identify and implement ways to improve their ways of working. If a team are struggling, declining opportunities to try to improve is normally a bad idea – after all a reasonable definition of insanity is to do the same thing again and again, expecting the results to change!

One of the big impediments to retrospectives is when the team either don’t believe change is possible in their organization. If teams come forward with things that can be improved, it is absolutely imperative for the organization to take this seriously and empower the team to improve their process. One of the main points of having a scrum-master or similar role is to act on the team’s behalf to make things happen. This doesn’t mean the scrum-master should assume to own the retrospective, or to own the actions that come out of it, but they should be a major player in pushing for results from those proposed actions. If a team see no progress, they will very quickly be disheartened, and see retrospectives as a waste of time. The actions don’t have to be big, and it’s a good idea to limit actions to an achievable number. Sometimes all it takes it to set the ball rolling, by delivering a simple small improvement, and that can open a pathway to bigger things.

Actions that come out of retrospectives should be considered high priority; these are things that the team think will mean that delivery will improve. Over-ruling the team’s opinion on how they do their jobs and how they could do better to try and cram something else through even though they are explicitly saying there is a better way to do things is a fast way to lose their respect and interest. I like to have a ticket tracking mechanism for retrospective actions, and the first thing in a standup is to have an update on these items. Taking ownership of progress on a retrospective item is a promise to the team, and if you’re not in a place where you can deliver on that it’s better to acknowledge that and pass the baton to someone else than to allow the item to stall.

Another really easy way to ruin retrospectives – and a team – is if the team gather for a retrospective but don’t feel like they can be open and honest. In an organization that has trust issues, or politics problems, this can be especially prevalent. It might be worth filtering who attends these retrospectives to just the team members themselves – not managers, stakeholders or anyone else who could be seen to use retrospectives against the team. Getting a neutral facilitator can make a big difference – someone who clearly has no agenda of their own, and who can simply help the team talk honestly. Scrum-masters who spend a lot of time with a team can have a difficult balance here, because they will have their own opinions but need to be careful to allow the team to set the agenda and direction of the session. I’ve seen teams rotate the scrum-master role within the team, and allow any member of the team to facilitate retrospectives, and this can work well. It can also mix things up to change the environment – why not try having an off-campus retrospective in a neutral environment. Sometimes getting the team in a different setting can encourage fresh ways of thinking. I’ve seen teams go to the park or similar, with very positive outcomes.

Counter-intuitively, one way to improve retrospectives can be to have more of them. One problem is that if retrospectives are too infrequent, a long list of things can build up – so when there finally is an opportunity to get together, it can turn into a venting session, with far too much going on for the session to be effective. With some teams, I’ve tried daily retrospectives, in a stand-up like format, where each team member identifies one thing that could be done better tomorrow. This can force teams to focus on iterative improvement, and prevent big problems developing. The ideal situation, as with standups, is for retrospectives to become trivial, because the team autonomously self-organize to nip problems in the bud and improve naturally and continuously.