Agile Retrospectives – Part 2

In my first post about retrospectives, I described what a retrospective is, why you want to do them, and described the Retrospective Prime Directive.  Now it's time to talk about how to do a retrospective.

A Retrospective Agenda

In Agile Retrospectives: Making Good Teams Great Esther Derby and Diana Larsen provide an excellent basic agenda for a retrospective:

  • Set the Stage
  • Gather Data
  • Generate Insight
  • Decide What to Do
  • Close

Let's look briefly at each of these.  I strongly recommend reading Esther and Diana's book for a more in-depth treatment.

Set the Stage

At the beginning of the retrospective, you want to establish a shared understanding of the goal: You are looking for an area to implement some improvement, based on the experiences the team just had.

This is also a good time to identify the comfort level and level of engagement of the participants.  If it turns out that the participants don't feel safe, or would rather not be in the retrospective, it will probably be much more productive to deal with those issues instead of moving ahead with the retrospective as planned.

Gather Data

This section is all about 'what': what happened during the period under examination.  We’ve learned that it is always best to have some measure of structure. Simple exercises, many of which are detailed in Esther and Diana's book, can help keep your thinking fresh and your discussion on-topic.

Time-line exercises are extremely popular for this.  You can use index cards or sticky notes to build a time-line on a wall, with each team member contributing as many events to the time-line as they can recall. 

This is a good time to bring in the project artifacts: burn-up and burn-down charts, story cards, lists of bugs, data about build breakages, customer comments, or any big visible charts that the team uses. 

Whatever method you use, the goal is to gather enough data to help the team see what happened as completely as possible, from as many points of view as possible.  The longer the time period being retrospected upon, the more important this section is.

Generate Insight

The section is about 'So What?' as in: So, what does it all mean?  This section is also about 'why', as in, why did these things happen?  It is not about “who”—remember the prime directive and be careful to avoid finger-pointing and blame.

During this phase the team will do activities designed to:

  • Find patterns in the data
  • Find the most important items
  • Deepen understanding
  • Find causes and effects
  • Identify possible solutions or improvements to try

Decide What to Do

This is sometimes called 'Now what?'  The team has looked at what happened, come to some understanding about how and/or why it happened.  Now it's time to pick something to do differently going forward. 

It's generally best to pick only one area (maybe two, maybe) to improve.  The idea is for the team to make steady forward progress, not to get overwhelmed trying to fix everything all at once, however strong the inclination to do so may be.  A team that is successfully addressing one new area every week will feel great about it.  A team that is trying to fix five areas but failing to take action on four of them will feel disheartened. 

Pick things that are under the team’s control, and within their power to implement.  It's not helpful for a team to decide to hire more testers, if they don't have the authority.  Much better to pick an action the team can implement, like: Improve our testing by automating more test cases.  Be specific.  The outcome of this section of the retrospective should clearly identify who is going to do what by when.

The change should be viewed as a trial, or experiment.  It should be implemented, and then the results examined to determine if the change actually had the desired impact.  Not all process improvements work as expected!  So, along with who will do what by when, identify when you will check back in to judge the effectiveness of the change.

Close

The team has done some good work.  They are putting in the time and energy to continuously improve.  Take a bit of time to recognize and celebrate this.  You want the team to walk out of the retrospective energized and more bonded than they walked in.

An appreciations exercise is a good way to end a retrospective.  Invite people to call out specific things that they appreciate about their teammates.  The more specific the appreciation is, the better.  Use the format: "I appreciate <person> for <something>."  Here are some examples:

  • I appreciate Brad for staying late to fix the broken build.
  • I appreciate Kira for being patient with me when I was grumpy on Tuesday.
  • I appreciate Kai for helping me debug the redraw issue.
  • I appreciate Justus for his deep knowledge of Visual Basic; it really saved us this iteration.

That's it!  Go forth and improve.

Get your ScrumMaster certification with Jeff McKenna and I before the October testing deadline.  Hurry, this class will fill up quickly.

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>