I think retrospectives are misnamed. They're really about the future: what are we going to do differently so that we make better software? It just so happens that looking at the past is the best way to work that out. The danger I see of calling them retrospectives is that people sometimes view them as catharsis rather than tools of change.
If you're looking for an introduction to retrospectives, I like James Shore's chapter on retrospectives from the Art of of Agile. Of all of the meetings I've ever been in, regular retrospectives have been the most effective in leading to consistent and positive change. If you have a retrospective every two weeks, and you produce just one action that improves your process, that's twenty-six improvements in a year: not to be sniffed at. On the other hand, I've also seen retrospectives cause more harm than good. I thought I'd jot down my thoughts around retrospectives, and in particular how I've seen them go wrong.
I've found the best facilitator is a disinterested facilitator. One of the goals of a retrospective is fair and equal participation, and having someone neutral run the meeting encourages everyone to speak, and helps them feel as if they've been treated fairly. It's also easier to end conversations when you're a disinterested party rather than intimately involved. I personally like facilitators that do little talking, and ask participants to explain what they mean and to summarise rather than doing it themselves.
If you do have someone in the team run the meeting, I'd suggest you avoid having managers or others perceived to have power run it for the reasons above. Note that peers in the organisation chart might not be perceived as peers in the real world. For instance, if your product owner decides what work should be done each week, the result might be that the product is perceived as being senior to some of the developers on the team, which makes the product owner an inappropriate facilitator.
A few ways in which I've seen retrospectives not go as well as they could have, and suggestions for how the situation might be rectified. I'm no expert -- these are more random thoughts than structured advice! I also offer suggestions for fixes: these aren't guaranteed to work, but they might help.
The blame game
When describing things that could have gone better, it's tempting to try to attribute blame to someone, often to someone outside the room.
Fix: use Kerth's Prime Directive at the start of the retrospective to set the tone:
Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
The meeting overruns. A lot.
The first time you run a retrospective, it's often the first time that people are asked to reel off everything that's good and bad about their job. You can easily end up with an awfully long list, and people might have a lot to say on each point. The result is that the meeting overruns, you can't get around to everyone, and don't have a chance to set any actions.
Fix: Carefully structure the meeting. Make sure you have a plan for the different sections, and how long each should be. Stick to your timings as much as possible. The facilitator should stop any conversations on any one topic that go on too long.
People don't feel like they had a chance to speak about what they brought
Some people might naturally dominate the conversation, or the group might get caught up in one topic.
Fix: Again, the faciliator should stop any conversations that go on too long. They should also make sure that everybody gets a chance to speak, and give everybody an equal chance to raise the points they're interested in.
For instance, suppose everybody's brought a list of items that want to raise. Rather than letting each person go through their entire list before moving on to the next person, have each person explain their most important point before moving on. Only go round the entire table again if you're sure that you can do so in the time left.
No actions get decided
Although talking can be cathartic, actions are usually what actually drive the change. If you spend too long talking, you might not ever get to set actions.
Fix: At the risk of sounding like a broken record, make sure that the structure of the meeting allows time at the end to think through possible actions and decide which ones to choose without being rushed. Better to discuss fewer points and have one solid action than to try to discuss more points.
Actions don't get done, attendees become disillusioned
Some actions can be well-meaning, but flawed. For instance, an action might be:
- Reliant on a factor outside of the team's control
- Too long-term
Fix: Try to pick actions that you're confident can be achieved before the next retrospective, especially when trying to build the credibility of the idea of a retrospective. Even if you have larger long-term goals, try to pick actions that allow people to see tangible progress.
Choice of focus or actions feels unfair
Everybody might get an opportunity to speak, but the decision on what to try to improve and what actions to take should also be democratic.
Fix: Use a democratic process for deciding what to focus until the next retrospective. For instance, once a list of possible foci has been generated. use dot voting to decide which one to pick.