This is my summary of Chris Hedgate’s “Effective Retrospectives”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

  • participation
  • decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

  • Facilitation = planning, leading, setting a goal. Gives us flow.
  • Framing = setting up and ending, making it focused
  • Structure = ensures balance, gets everyone’s input

Facilitation

  • Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
  • Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
  • Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

  • Modify the retrospective according to its purpose
  • Define the goal and agenda
  • Not every retrospective needs to be about “how can we get better”
  • Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
  • Start with a check-in: everyone says/draws something about the iteration
  • Make it safe to participate

Structure
A retrospective should have three phases:

  1. What happened? Why are we here? – In this phase we share context
  2. Why did that happen? – In this phase we diverge, by brainstorming
  3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

  • Looking at raw data: burndown chart, story list, bug count chart
  • Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
  • An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

  • possible
  • valuable/important
  • someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.