Practice 4. Retrospectives
Retrospectives [Kerth 2001] are a critical part of sustainable software development. In order for continual refinement to be effective, the team must be able to continually learn and adjust not only its project (what the team is building) but also the methods members use (how the team works).
Teams should hold retrospective meetings at regular intervals during their projects. Ideally, this would be at the end of every iteration or the end of every second or third iteration. The purposes of these retrospectives are to provide a forum where the teams can openly question their current development processes and progress, learn from their mistakes and failures, and decide what changes they need to make to proceed effectively.
One of the key aspects of a retrospective is that you must lay out ground rules in advance. It is vital that a retrospective be a positive experience that focuses on learning and not on laying blame. Start by assuming that everyone on the team is doing the best he or she can, with the recognition that there is always room for improvement for every member of the team. Ideally, retrospectives should help uncover areas for improvement and give everyone ideas as to how to contribute more strongly to the project. But retrospectives should never be personal or antagonistickeep those discussions private and behind closed doors.
Retrospectives are a simple mechanism that helps increase the chance of your project's success. Frequent retrospectives during your project help ensure that course corrections and changes to your project and processes are made when you need to make them, not after it is too late. When action is required, the next retrospective should uncover what was not completed and why.
Retrospectives also serve as a useful forum to help the team bond because it gives them ownership of their processes with an eye to continual improvement. Team members aren't being told how to do their workthey are committing to each other how they are going to work. There is a huge difference between being told and making a commitment to your peers!
A simple format for the retrospective is to first ensure that the entire team is present (including businesspeople), select a moderator (ideally neutral, such as from another team), and then answer some basic questions such as:
Then, review outstanding action items from previous retrospectives and develop a new set of action items and changes that will be put in place immediately. Be sure to document your results and archive them in a central location so you can refer to them later.
Tip: Be Creative!
There are many creative things you can do to make retrospectives more productive and fun. For example, use different colored sticky notes to capture issues of differing levels of priority. Use a teddy bear or similar object to control who is speaking. Or capture an image of the screen of the product at each retrospective. It can be a lot of fun in the retrospective at the end of the project to review these images and notice how much the product has changed and evolved.
The duration of retrospectives is a variable that must be carefully monitored to ensure they do not become a burdensome overhead. Frequent checkpoint retrospectives that are held during a project should take an hour or less, while retrospectives held at the end of a major release might take a day or more, depending on how elaborate a retrospective is required.