Retrospectives are a scrum team’s most powerful tool for facilitating continuous improvement. We’ve all encountered teams making the same mistakes and suffering the same pain over and over again. The good news is that it’s possible to break this cycle by investing as little as one hour per week in a sprint retrospective.

Scrum teams continuously inspect and adapt, resulting in ever-improving performance and happiness. The retrospective that is held at the end of each and every sprint is the primary means by which the team is empowered to improve. The retrospective allows learning and insights to be captured while experiences are fresh, and before negative patterns have a chance to harden in place. The goal of every retrospective is simple: to identify one or maybe two areas to improve, and to create an action plan to implement the changes.

Some people new to scrum may have experience with traditional 'post-mortems' or 'lessons learned' sessions. Traditionally these are held at the end of a long project, and often generate long lists of 'plusses' and 'deltas' that are forgotten almost as soon as the meeting ends, amidst disgruntled mutterings about “barn door” and “the horse has bolted.”

In contrast, scrum teams hold retrospectives regularly, at all levels of a project. Common types of retrospectives include:

• Sprint
• Release
• Incident
• Project

While generating the traditional laundry list may be initially cathartic, it quickly becomes frustrating to see the same items show up over and over:

It feels much better to identify a single area to improve, and then do something about it. Teams that effectively use retrospectives feel a strong sense of empowerment as they continually improve the way they work.

How long does a retrospective take? A rough guide is 30 – 60 minutes of retrospective for every week being retrospected upon. Teams often find that as they get used to the process, they need less time than when they first start doing retrospectives.

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.

This is The Retrospective Prime Directive. It was created by Norm Kerth, author of Project Retrospectives: A Handbook for Team Reviews, and he explains it this way:

At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated…

The prime directive sets a productive tone and spirit for a retrospective. Of course, the team knows much more now, and would do things differently. Without mistakes and shortcomings, we’d never uncover new opportunities to improve. The pain and struggle that led to learning should be honored. In this way, the team can benefit and build on the lessons and the learning that took place. If we finger-point, blame, and embarrass, then people will be unwilling to share; the opportunity to improve will be lost.

Tune in for part two, where I will walk through a retrospective agenda.