At Kaizen conf Mary Poppendick said it best:

1) The team picks the ONE thing they can CHANGE NOW, its really good if this happens to be the thing that is causing the most pain
2) The team is ALLOWED the TIME to fix it <- (this part is important!)

…or something to that effect.

Basically dont over complicate it. No lists of things that are never going to get done, no bitching or warm and fuzzy ‘what went well’. Just pick the thing that’s the most FU and give the team time to fix it.

(For the record, we still do the ‘What went well’, “What we could do better’ and ‘Action items for next sprint’ Probably by my tone you can tell what I think about that )

Great post Chris!

Agile spends very little time looking back and learning from mistakes and best practices, this is the purpose of the Retro, and in my opinion is critical if you’re doing Agile ‘by the book’. Keeping the Retro agile (little a) and to the point is the key. As a ScrumMaster I have to be as creative as possible and keep the format changing on a regular basis. This helps the team think in different ways about what they’ve accomplished, what they need to continue doing, and what they need to improve on.

I do enjoy the Derby/Larsen book and use it as a reference, though I don’t always use all the steps for smaller teams. The basic concepts of Setting the Stage, Gathering data, Generating Insights, Making Decisions, and Closing are still doable and help ensure that the team comes out of the other end of the meeting with actionable items. I think the ideas mentioned by cbilson are good for keeping things simple, but they might not always start the team out with the right mindset (i.e. might make the team feel like it’s not a big deal).

As a reformed traditionalist, there are actually a lot of ideas or activities that transfer from that world that can be performed even for small teams, but it takes making time (I try to spend as much time preparing as the Retro will take) and finding both creative ways to elicit quality discussion as well as keeping measurements consistent enough between iterations to build up the knowledge base about what works and what doesn’t work for the team, what helps them and what hinders them. Sometimes you have to fight the ‘corny’ factor a little but, but that goes back to finding out what the team likes and reframing the questions and activities to be more applicable.

Regarding business value, finding a way to keep the Retro relevant and useful (i.e. so that business value can be delivered) is really key to successful Retrospectives.