3 January 2013

How we do sprint retrospectives

At jclarity we try to undertake development in short sprints. This is a pretty standard agile practice, and each sprint is concluded with a retrospective.

Why have a retrospective

A retrospective is an opportunity to evaluate a sprint and see what can be improved in future. Each retrospective is different - but we do have a very loose approach that we follow. I'm not saying that its a perfect approach, or that you should instantly adopt it, but I think there's probably something for others to learn from it.

To me, retrospectives are like performing an intervention on a drug addict*: everyone gets their say, you need to be honest and you shouldn't be overly judgemental of individual actions. You need to listen to other people's criticisms and try and act on them in future. One of the nice things about having a regular retrospective is also reduces the incentive to belly-ache about issues during development and gives everyone the opportunity to be involved in discussing them when they crop up.

How it works

We schedule a time, via google calendar, write up a list of issues on a whiteboard and go through them one by one. For each issue we score ourselves into one of four categories:

We also make specific comments whilst we're going onlong about how we can improve, or turn around a negative trend. It might be that a trend isn't easy to turn around - for example if our Chief Scientist (who lives in hungary) has been undertaking client work in germany and plans to fly back to Hungary then its not possible for us to all work face to face. But noting it down at least tells us that we need to ensure that he's still in the loop or have him come to the UK in the nearer future. You also need to have some kind of buyin to the retrospective idea and to ensure that you try and improve in the ways that you can, and help others do the same. We always go through the following list of topics:

Does the approach matter?

I've heard that some people just go for a free form chat. I think having a bit of structure helps - it does ensure that you don't forget to talk about things. It also means that you get the psychological boost of a tick if things are just going fine, where as if you did a free-form you'd probably just ignore the issue.

Conversely I think any more process than a list of issues to go through is too heavyweight. Complex processes have a bad tendency to degenerate and parts be ignored or forgotten over time.

Credit for the approach should go to Martijn who has used it before in other teams he's managed and found it to be effective. I'd love to hear any comments from people who have a different approach.

* At least that's how American Television has taught me that a drug intervention should go: I've never been involved in one myself.

Read More: Slab: guaranteed heap alignment on the JVM