Agile Retrospectives – Part 1

Retrospectives are the agile team’s most powerful tool for facilitating continuous improvement.  We’ve all encountered teams that make the same mistakes and suffer the same pain over and over again.  The good news is that it’s possible for just about any team to break this cycle by investing as little as an hour a week in learning to use retrospectives to systematically and incrementally improve performance.

Agile teams continuously inspect and adapt, resulting in ever-improving performance, and happiness.  The retrospective (some call it a meeting, while others refer to it as a ritual) that is held at the end of each and every sprint is the primary means by which the team is empowered to improve, as it 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 agile 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, agile teams hold retrospectives regularly, at all levels of a project.  Common types of retrospectives include:

  • Iteration
  • 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:

"Once again, we didn't have enough time for testing."
"Integrating the subsystems was painful."
"Fixing bugs kept us from working on the new features."
"It took too long to get database changes from the DBAs."

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, 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.

This entry was posted in agile. Bookmark the permalink. Trackbacks are closed, but you can post a comment.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>