Agile teams strive for continuous improvement. Just as Refactoring is used to improve the design of the code, Retrospectives are used to improve how the team works. Traditionally, retrospectives were held at the end of a project and were commonly known as post-mortems. Other than the connotation that the project is dead, holding a retrospective at the end of project is quite simply too late.
In Agile, Retrospectives are used at two levels – at the end of each Iteration, and at the end of each Release. In both cases, the goal is to identify not only what didn’t work well for the team, but to acknowledge what did work well. It’s equally important to learn from one’s victories as it is to learn from one’s mistakes!
Retrospectives are always held with the mindset that every person on the project did the best that they could do at the time. This isn’t New Age blather intended to prevent people’s feelings from being hurt – it’s actually quite rare for people to actively sabotage projects! Retrospectives are also not a forum in which to exact revenge for perceived wrongdoing, or simply a blame session. They are used to help the team improve with each and every iteration and release, and are a crucial aspect to remaining Agile in the longer term.
Iteration retrospectives are typically held in the afternoon after demonstrating the latest features to the Product Owner. At this level, the meeting is relatively short, taking 1-2 hours.
The immediate team participates, and one person acts as a facilitator. Using a whiteboard or flipchart, each person in attendance may suggest items or issues that they feel the team did well, or needs to improve upon. The facilitator writes down the items, possibly asking questions for clarity’s sake. People may also suggest multiple items, or even the same item under both “did well” and “needs improvement”. At this point, the team does not discuss the items.
Once all team members have had a chance to suggest items, the team as a whole discusses the two lists. For the items that are deemed to be the most important, the team as a whole creates actions that will be used to address the items. These actions could be as simple as posting a progress chart on the wall daily, or possibly as significant as asking that the developers receive training in Test-Driven Development.
Retrospectives at the Release level are quite similar to Iteration Retrospectives in terms of how they are run. However, they can be considerably longer, often taking 1-2 days. Rather than just the immediate development team, all stakeholders may be invited to this retrospective.
Release retrospectives deal with more strategic issues, such as the team’s workspace, the composition of the team, the involvement of stakeholders, and dealing with teams or resources external to the project.
For both Iteration and Release retrospectives, the goal is the same: improve the performance of the team.