Retrospectives are one of the best ways to improve the way a team works. They're one of the most important Agile practices.
A retrospective is a time set aside to reflect on how the project has been going, and how things could be improved in the future. Specifically, what changes can be made by the team itself in order to work better?
The team should discuss mainly the processes they use to get work done. These are the most ripe for improvement. Many coaches don't recommend talking about technical topics at a retrospective, but if there's a technical issue that the team needs to make a decision about, or if there's a technical means of making improvements, then those should be fair game for discussion at a retrospective. When in doubt, ask "will this discussion help us improve the way we work?".
A lot of process issues have to do with the way team members work together. Working in close quarters for long periods of time under stressful conditions can lead to lots of tension. These tensions can play out between team members. In some ways, a retrospective can be like group therapy or marriage counseling. This is a good thing; working out those issues will lead to a more cohesive and productive team.
Retrospectives are often held at the end of an [iteration]. However, this does not need to be strictly the case. Many teams prefer weekly retrospective meetings, even if the iterations are longer.
It's important to have regularly scheduled retrospective meeting times. Self-improvement isn't something to do on occasion. It's something to do as often as we can afford to. One hour a week is 2.5% of our work time. There's a good chance that the improvements suggested during the meeting will more than make up for that time.
But not every retrospective needs to be held at a scheduled time. If there's a process issue that needs immediate attention, then an impromptu retrospective meeting might be the best way to work through and resolve the issue.
TOOD: Sidebar story about impromptu retro with T1D team.
If at all possible, get someone from outside the team to facilitate the retrospectives. This should be someone the team can trust. A team lead from another team would be a good facilitator, especially if the other team is also implementing Agile practices.
Ideally, the facilitator should facilitate the meeting, and not necessarily try to control the meeting. The team often will go where it needs to go, with just a little push in the right direction. The facilitator should try to keep things on track though, so that people don't go off on tangents that aren't addressing the issues at hand.
Another role the facilitator needs to play is referee. Make sure that people aren't placing blame for things that went wrong. The team should always be focused on how to improve; looking to place blame is not helpful in moving forward. One way to keep from placing blame is to realize that given the same situation, resources, and knowledge at the time, you would probably have made the same decisions. Placing blame on individuals will just cause them to stop being open and honest, and the pace of improvement will slow down.
Everyone on the core team should attend. This should include all developers on the team. Designers and QA testers should probably be included as well. Unless the issues always tend to be developer-oriented, the other team members will often have ideas to contribute.
Opinions are mixed on whether managers should be a part of the team retrospective. If the manager is engaged day-to-day with the team, and there's trust between the manager and the other team members, then the manager should be a part of the retrospective. If that's not the case, then it might be difficult for people to be open and honest if the manager is present. It's very important that people feel comfortable speaking their mind during the retrospective.
When facilitating a retrospective, you'll often need a way to drive the conversation. Sometimes the team will have topics that they would like to discuss. But often, the facilitator will need to come up with a way to get people to talk, and direct them to important topics. These are done though various retrospective activities or exercises. (Many Agile practitioners call these games, but we prefer use a more serious term.)
There are many activities that can be done during a retrospective. The canonical reference is the book Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. Anyone facilitating a retrospective should read that book, then use it as a reference.
Some short activities are good to do at every retrospective meeting. One of our favorites is the "temperature reading", where everyone rates their current happiness with respect to the project and the team. This is then used to plot whether the team members think things are getting better or worse.
Other activities take longer, and should be scheduled for a specific purpose. Generally this is to find out what's on people's minds, but it might be more specific, such as getting to the root of a particular problem that the team is facing.
The typical longer activity involves asking 3 simple questions:
- What are we doing that is working well?
- What should we stop doing?
- What should we start doing.
The idea behind most of these activities is to drive discussion. At the end of the discussion, the team should decide on some action items. These action items are small changes that the team can make to try to improve.
-
Start out with regularly scheduled retrospective meetings every other week.
-
Start with 1 hour retrospective meetings.
-
Get an outside facilitator if possible.
-
Start out without any managers or project managers involved. The facilitator should ask the team on occasion if they think they would like to invite the manager.
-
Start with 2 basic exercises:
- Team happiness temperature
- Start, stop, continue
-
Make adjustments as necessary.
- [Agile Retrospective Resource Wiki]
- TODO: More resources.
[iteration]: TODO: Reference the chapter on Iterations. [Agile Retrospective Resource Wiki]: http://retrospectivewiki.org/