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:

  • What worked well?

  • What needs to be improved?

  • What should we do differently?

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.

Traditional Methods: Plan a Lot, Do a Lot, Learn a Little

Traditional methods of software development are best termed plan a lot, do a lot, learn a little Great effort is spent before any software is written to understand the user's requirements and design the system. Then it is built, usually with little or no customer feedback.

Customer feedback usually doesn't occur until a beta version is released to select customers. But beta releases are almost always too late to do anything about customer-reported issues or requests because they're usually late in the release cycle. Because customer feedback is late in the release cycle, there is a high chance of wasted effort as features that aren't critical to customers are built or features are built in ways that aren't usable. And because customer requests often lead to risky changes that would jeopardize the eventual release, they often get moved into the next release, when in most cases the changes will be less useful, not to mention late!

Usually, teams are so busy building their products and trying to meet their deadlines that they hold a post-mortem at the completion of the project. But along the way, they have missed many opportunities for course correction and process changes.

Sustainable Software Development. An Agile Perspective
Sustainable Software Development: An Agile Perspective
ISBN: 0321286081
EAN: 2147483647
Year: 2005
Pages: 125
Authors: Kevin Tate © 2008-2017.
If you may any questions please contact us: