I attended a project retrospectives training session last week. Although I’ve run quite a few retrospectives over the years I’ve never been trained in them. My guide has been Norm Kerth’s Project Retrospectives book and a whole bunch of ideas I’ve picked up over the years.
This training session was organised and run by Rachel Davies and Diana Larson. It drew on Diana’s new book Agile Retrospectives.
Although the book and the training is aimed at Agile practitioners it could be used by other teams – its just that Agile teams are more likely to do this stuff.
The world outside of software development is also catching onto retrospectives. In part this is thanks to the US Army and Marines who call them After Action Reviews (AAR). Now they have a macho name and the backing of some generals they seem to be cropping up all over the place.
That said, I still think Retrospectives – or AAR to give them a more fashionable name – are still more talked about then practised. The training session gave me an opportunity to reflect on this paradox (as well as learning some new techniques and improving my facilitation style.)
So why is it retrospectives get a lot of talk and little action?
There seem to be three basic failure modes. First is retrospectives that don’t happen. Usually the reason given is lack of time. However I think this only an excuse to hide behind. When people want to do something they do it, if something is important time is made for it. Conversely when something is low priority or someone doesn’t really want to do it then there is not enough time. We are all busy people, lack of time really means “is not a priority for me.”
I think one of the reasons people don’t want to do retrospectives is because they are scared of what might come out of it. Individuals could be criticised, companies could be found wanting or someone may say something they are not supposed to say.
Retrospectives expose the lie that your boss/manager/leader knows best. By definition retrospectives are about asking teams what they can do better. Traditionally we are brought up to expect that someone in authority, someone with a “big brain”, knows best. So retrospectives can be threatening to managers who feel they are loosing some power.
Which brings us to the second common failure: ineffective results. Simple formulaic retrospectives, perhaps they simply ask “What do we do right? What do we do wrong?” and perhaps they limit the whole thing to an hour, and perhaps the team leader or project manager acts as facilitators.
Such retrospectives are unlikely to uncover deep thoughts because they are not asking the questions that will cause people to reflect deeply about the whole project. Having a authority figure lead the retrospective will also cut off reflection, by leading this person is exercising their authority and sending a clear message “I am still in charge.”
Finally, the third failure mode of retrospectives is: Lack of action. Things the team decide to do aren’t acted on. This is actually closely related to the first two. If it is hard to find the time for a retrospective do you have the time to make the change? More likely you are risk averse.
And if the authority figure isn’t open themselves then they are not going to be fully behind the change. This will be clear to anyone tasked with making the change. That is, if anyone can be persuaded to take on the task.
Arie de Geus pointed out in his book The Living Company that when you have more people involved in making a decision it might take longer to actually make the decision but taking action once the decision is made will be quicker. This is because more people were involved in making the decision. If a retrospective is half hearted then any decisions will not have wide buy-in so taking action will be a slow process.
So what’s the answer to these problems?
Well I think I’ve realised were I was making my mistake. Like many other people I’ve been seeing retrospectives in isolation. As some kind of plug in solution, nicely self-contained. But they are not, this was the mistake.
I’ve realised that retrospectives need to be embedded in a learning culture. I used to think they could be one of the early tools to use in creating such a culture, now I realise they are an advanced tool to be brought in once you have the culture in place.
An organization that does retrospectives is an advanced learning organization. Most organisations are not learning organisations let alone advanced ones so it is hardly surprising that retrospectives are missing.
When you have such a culture not only do people value learning but it is a priority for them. They make time for learning events. They value the results and they take action.
In such a culture people feel less threatened by what might come out of a retrospective because they are accustomed to deep thinking and reflection. Everyone knows the rules and people are open to insights and change.
In a learning culture managers have already accepted that the team knows best. They have already changed the view of their role from command-and-control and “boss knows best”. They define their role more in terms of helping individuals and teams learn and advance. Neither are they threatened by loss of authority.
Finally, when you have such a culture, when people are not scared or threatened, when everyone appreciates the value of holding a retrospective then change does happen, people do follow through on the action identified in the retrospective.
So, how do we create such an advanced learning organization? Well, that will have to wait for another blog entry and even my book. In the meantime, if I can help with a retrospective or creating a learning culture please get in touch.
From experience, part of the issues with these reviews is around how many of the team are left around. It’s very common in consulting organisations to form a team to deliver software, and then disband the team at the end. Unfortunately many of the key contractors might have moved onto other projects or contracts way before the end of the project. The team resource profile changes over the life of any given project, and what may have had 100s to start may drop significantly towards the end – when this would normally happen – and you may find a dearth of input simply due to a lack of available voices. The way I’ve fixed this in the past is to run sessions of this type on a regular basis rather than one-offs at the end, in exactly the way that a learning org should. It’s much better to receive feedback and refine approaches on a course-correcting-as-you-go approach in an Agile development than to try and run these at the end of every project in order to inform the next one.
— Alistair.