The sprint retrospective is an important ceremony in Scrum. The Agile Manifesto clearly underscores the significance of this ritual, stating, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Of course, it’s bad if you don’t perform retrospectives at all. However, more often than not, it is not the retrospective itself, but rather a poorly conducted retrospective that results in an ineffective, stale, and meaningless effort.
One reason for the poor quality of retrospectives, according to Mark Levison, is that retrospectives often get overlooked during training sessions, like two-day classes on an introduction to agile. Mostly, the trainers cover just one simple type of retrospective. A single approach to retrospectives makes them boring, and over time people lose interest in participating.
Another reason for poor quality is that retrospectives can become negative gripe sessions, interspersed with blame and counter blame. This goes against the “The Retrospective Prime Directive.” The directive says, “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
In the following YouTube video, Jeff Sutherland gives an overview of a sprint retrospective in Scrum. He is very candid about identifying the one thing that will have the biggest impact upon fixing, which you should be committed to do. If the problem is not fixed, ideally before the next retrospective, then the retrospective has been a complete waste of time.
So, what needs to be done to improve the retrospectives?
In order to keep the retrospectives useful, they must be meaningful to the participants. The team—not the coach or other dominating person—decides to consider and improve in areas it believes are important. It goes without saying that the chosen items should be actionable, measureable, and controllable by the team.
Periodically changing the technique of retrospectives can keep them interesting and relevant. This includes switching locations, swapping facilitators, and changing techniques to bring an element of freshness to the retrospectives. You can lookup the Agile Retrospective wiki for retrospective plans, tips, tricks, tools, and ideas to get the most out of your retrospectives.
High-performing development teams emerge over time and only by the persistent quest for improvement. Sprint retrospectives are a key aspect in that quest.
How have you dealt with sprint retrospectives? Let us know in the comments below.
