It isn’t too surprising when you see that there are so many different ways to do a retrospective, after all, if there are that many options then surely you are meant to switch it up at the end of every Sprint?

So when should you move onto a new retrospective format? Well naturally if the format you are using isn’t working then consider using a format (more on this moment), but to help here is my decision tree on the matter:

Okay, so maybe there was a simpler way to say this…

If you haven’t used the original technique for more than six times in a row then don’t try something new.

Why six times? It is enough to get a pattern, to feel comfortable with the process so that you can maximise the focus on the intent behind the practice.

If your team has been doing it the same way for longer than that and don’t want to change it, then as a Scrum Master DON’T CHANGE IT. It is their decision not yours to switch it up in this instance.

I’m not going to go into the menagerie of options that you can use for a retrospective, but I would recommend that when you start keep it really simple. Ask two to four questions, no more than that. I still use the original ones:

• What worked well
• What to do differently next time
• What puzzles us
• Lessons learnt.

What I find is a lot of retrospectives fail, not because of the process per se, but because of the little additional “gotchas” that seem to be hard to find as guidelines/rules on the topic. Here are my top tips:

1. Start you retrospective by reviewing your previous retrospective actions. If they aren’t done then focus the retrospective on why the actions themselves aren’t getting done.
2. Don’t commit to more than five actions. You just won’t do more than five.
3. Fix the root cause not the surface issue. To do this, you need to make sure that you actually discover the root cause within your retrospective.
4. Treat the retrospective as a law of thirds – one third define (brainstorm), one third discovery (share) and one third determine (next actions). Teams often make the mistake of not managing time effectively that result in not enough time for actions.

• PMI and Agile are completely different mindsets, PMI Project Managers are “the CIOs of their projects”
• AgileWelly – strength through the struggle of doing Agile in government
• Wellington Agile community led by TradeMe, Snapper, BNZ
• Gojko Adzic – Specification by Example and Impact Mapping
• Agile NZ conference
• Retrospective design – creativity in facilitation is a gap
• Esther Derby’s model for restrospectives
• Paper Airplane game – using an abstract process to apply learnings to the real process

TheAgileRevolution-84 (25 minutes)