How we introduced efficient agile retrospectives

6 months ago, our team started to run systematic iteration retrospectives. Within these 6 months, our team became more agile than ever. Running efficient retrospectives is what makes good teams great, it is what truly makes a team agile. Here is our story.

At the begining, we started with a standard retrospective format inspired from The Art Of Agile Development (A truly great book by the way). As I was used to running retrospectives, I did the first one. This is how it goes :

• Repeat Norm’s Kerth’s prime directive to everyone (5 minutes) :

Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

If the message is awkward, the animator can explain that the point is to avoid counter productive blaming (even if it is unlikely to happen in your setting …)

• Do some kind of brainstorming (10 minutes) :

One his own, everyone writes what went well on green post-its, and what did not went so well on blue post-its. Everybody sticks them up on the flipchart.

• Group insights togethers (15 minutes) :

The animator reads every post-it aloud, asking team members for details, and tries to group notes together. When everyone is ok with the groups, dot vote : every team member gets 3 points, that he can assign as he wishes on any group. Here is what the board should look like at this point.

• Find actions to improve the process (30 minutes) :

Pick up the 3 most voted issues, give everyone 5 minutes to think of useful actions to fix these. Then take another 5 minutes so that people can discuss their solutions in pairs, and another 5 minutes to do the same in groups of 4. Eventually, as the animator reports on the flipchart, do the same altogether. Make sure that the solutions are doable within the next sprint, if not discuss and split them until they are. Again, dot vote for the prefered actions.

• Do it :

As soon as the retrospective is finished, the animator must enter the actions in the coming sprint backlog. These actions are not user stories, but they must be done. If there are not, the team cannot be agile as they will be no continuous improvement. Don’t assign any story points to these items, but let the velocity auto adjust for a given amount of improvements during every sprint.

After the first one, every team member animated such a retrospective, one after the other. When everyone was at ease with this, we changed the format. We bought Agile Retrospectives: Making Good Teams Great and everyone was responsible for designing his own retrospective session when his turn came. This allows different and various insights.

To conclude, here are a few retrospectives hints and guidelines

• Everyone’s voice should be equal, everyone should feel free to talk
• Don’t worry if good ideas are not selected the first time, they’ll come back
• At the begining of every retrospective, review what happened about what was decided during the previous one
• Use sticky flipcharts and stick them on the wall as you go through the different activities
• Prepare flipcharts in advances to make the retrospective run more smoothly
• Use colored post its to highlight different aspects (good things, bad things or whatever)
• Use markers to write on post its (how can one read it from the back of the room otherwise ?)

If you haven’t yet, you have no excuses not to start now !

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!