Why Retrospectives Are Important in Agile Software Development
Periodically reviewing how things went—and looking for ways to improve—is an essential part of agile software development. Retrospectives are one way to do this, but it’s important to understand that there is a difference between a structured retrospective and “just talking about what happened.”
The structure of retrospective activities helps people recall and understand what happened, and provides a path to understanding and improvement that less formal methods do not.
One of the key benefits of a structured retrospective process is helping people get past their memory biases. While it may seem so at times, a software project rarely has the significance of a criminal trial. Consider what Elizabeth Loftus has learned about the unreliability of memory and how that affects a variety of factors, including how you ask questions. A well-conducted retrospective can help people focus on the significant events and help people remember what happened.
Even when we get the facts right, we don’t always remember things we deem important as the way they actually happened. Additionally, our memories might be biased from discussions we could have had in the past about similar issues. Because of issues like this, it’s important to have the retrospective led by a facilitator who can guide the team and can help people ask the questions.
A poorly conducted retrospective can be as bad or worse. While retrospectives have things in common with other feedback techniques, such as writers' workshops, it’s worth learning about the specifics of retrospective techniques.
Some resources for learning about retrospectives include the books Agile Retrospectives and The Retrospectives Handbook. You may be surprised by the benefits of applying a bit of structure to your retrospective session, and you can avoid some of the reasons that retrospectives fail.
Does your team do structured retrospectives? Do team members object to the retrospective process? If so, how did you overcome that?
