First (Forgotten?) Rule Of The Retrospective: Follow Through

Even the very greenest of agile teams clearly recognize the word 'Retrospective'. But, alas, it is often overlooked that a retrospective may be a wasted effort if not used to initiate an actual improvement that the team follows through on. Past Gordon Pask Award winner Jim Shore gives advice on how to make the most of your retrospective and reminds us of the activity's ultimate place in the agile heartbeat.

In his latest "bonus material" posting on the website addendum to his book The Art of Agile Development, Shore begins with a succinct summary of one good way to go about operating your retrospectives:

• Start with Kerth's Prime Directive. Everyone makes mistakes; the Prime Directive reminds us to support, not attack, our colleagues.
• Have participants brainstorm ideas in six categories: enjoyable, frustrating, puzzling; same, more less. Write each idea on a card.
• Next, place the cards on a whiteboard. Move the cards so the most similar are closest together. Everybody participates; nobody speaks.
• Circle and name the resulting categories. Choose one, then brainstorm root causes and solutions. Pick one: it's your retrospective objective. Follow through in the iteration to come.

As has been a pleasant recurring trend with Shore's "bonus material", he includes a helpful visual of the above flow.

Shore continues then by focusing attention to the final item of the suggested format; follow through in the iteration to come.

... the most important part of the retrospective is what happens after you leave the room. During the retrospective, you'll reflect on the past and imagine the future. You'll conduct root-cause analysis and come up with solutions. That's great. But don't forget to pick one of those solutions and follow through on it.

The implication presented in Shore's commentary, and one often cited by agile coaches all over, is that it is not uncommon for retrospectives to be followed by an unfortunate lack of any visible improvement. Shore points out that often the proposed improvement is not in and of itself a difficult task, but still yet it often fails to be implemented. He asserts that often this is due to nothing more than the fact that the item is not something part of the natural focus of the team's regular activities. Because of this he suggests that the team make the improvement an explicit part of the iteration plan, posted on the "big visible charts" and all.

For a bit of fun, be sure to look out for Shore's subtle acknowledgement of how he's applied his lessons when it comes to learning from his on "mistkaes".

Also check out Josh Kerievsky's paper on Continuous Learning and Esther Derby & Diana Larsen's book Agile Retrospectives: Making Good Teams Great.