Running an Effective Agile Retrospective

This is a summary of a presentation given by Brad Swanson of Propero Solutions on November 9, 2010, with permission from Brad. The topic was around effectively leading an agile retrospective meeting.

The stages in an agile process might go like this:

1. Planning
2. Sprint
3. Demo/Review
4. Retrospective

The retrospective focuses on what worked well, what didn't, and what can be done to tweak the process -  all with the goal of continuous improvement.

Open the meeting by setting the tone with a reminder about why it's happening - you're looking for improvement, not blame. Stages of the meeting include:

1. Capture Facts and Data
2. What Went Well, What Didn't
3. Create Action Plan

Capture Facts and Data

• # of backlog items - how many at start, how many completed, etc.
• what were the dependencies, impediments (why wasn't something completed)
• what was the accuracy of our estimates - why did something take longer than expected
• what were the unplanned events, work items
• start-to-finish deltas on metrics
• what can be done to reduce unplanned events, distractions

What Went Well, What Didn't

• omit judgments - just brainstorm it
• perhaps use a whiteboard with three columns for the "three H's": Helped, Hindered, Hypothesis (corresponding to what went well, what didn't, and ideas for improvement)
• defer discussion for now on disagreements (e.g. "that didn't go well" ... "what do you mean? I thought it went great" etc.)
• look for clusters of related items
• now ask for discussion, disagreement
• this is a time-boxed exercise!

Create Action Plan

• after discussion is done...decide on action plan - what to tackle for next sprint
• use "dot voting" - e.g., everyone has 3 votes, each person distributes their votes as they see fit (can e.g. put all 3 votes on a single item)
• pick 2-4 top-ranked items, develop action plan for each
  • might be as simple as voting to discontinue a given practice, right then and there - done!
  • or, add to backlog as appropriate, feed this into Planning meeting...
  • some items are of value to developers, perhaps not so much to Product Owner; to address this, teams might have an upfront agreement that N hours are set aside for each sprint to address internal process, infrastructure, etc. - dev team gets to decide how to use this budgeted time slot.

Thanks again to Brad for his permission to mangle his words into mine. I also include these links to Brad's own writeup around this topic.