Monday, December 8, 2014

How we do retrospectives

I've been facilitating formal retrospectives on this team for a few months now. We use this structure:

  • Meet at the end of each week for an hour.
  • Everyone writes observations on a sticky note (something that sucked, or something that was awesome by accident that you want to make sure we don't lose)
  • Dot-voting to select one item. 
  • Open discussion to deeply understand this item
  • Propose possible changes
  • Dot-voting to select one
  • Refine the item in to a crisp experiment

Most of the time is spent in the open discussion. I think this is the most interesting part. What causes this? What value do we get from it? What are some changes we could make, and what might the consequences be? How do other teams avoid or address this issue? Are there non-obvious changes that might make this issue disappear? (Causality may not be obvious.)

We have tried a few experiments with how we do retros:

  • Allow outsiders (including our manager) to attend. 

Learned that's OK if they stay quiet.

  • Each person can only put up one sticky note in the first round.

This speeds things up, and lets us devote more time to the open discussion.

  • Only call out good things that we want more of.

Assuming that bad things will fall away. Focusing only on fixing bad things will eventually get you up to "tolerable"; you need to increase good things to get to "awesome".

Overall I am very happy with our results. 90% of our decisions have been fully implemented; most produced valuable improvements. Where things didn't get better, we learned something valuable. For example, "Retrospective outcomes that require people to do more work are not likely to be adopted.", so at least for now, we should focus on things that don't require more work. (Maybe later, when our overload is reduced, and we can carve out more slack, we can start trying those things.)

No comments: