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:
- Good - We're pretty much satisfied with this area.
- Trending Upwards - We're not there yet, but its improving.
- Trending Downwards - We're not there yet and things are getting worse.
- Bad - Does what it says on the tin.
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:
- Is the Customer Happy? Obviously its unrealistic to expect all of your customers to be happy 100% of the time, but the aim is to get as close to that as possible. Its also important for the team to think of their customers, since they're the people who really pay for our salaries.
- Were we flexible? Incredibly important in a startup. Some weeks you don't need to be flexible, but we regularly have a priority change or an important issue crop up out of the blue - especially with products in beta or on sale.
- Did we work well together? This is really an opportunity to evaluate how we can improve things. Development processes need to evolve with the team and the work.
- Did we deliver working code regularly? This is a drill-down on one aspect of keeping the customer happy. Most developers might think this is the only aspect, but in reality its just an aspect. It is important enough to have its own section though.
- Are we being supportive and trusting? This encompasses issues of employee satisfaction, but also whether you think colleagues are working to your satisfaction.
- Face to Face We have a distributed team, so its important that we regularly meet up face to face. Ideally this is in person, but if that's not possible its good to schedule Skype or G+ meetings.
- Technical Excellence Are we doing everything technically possible to produce the best possible product? Do we have good test coverage? Have things horribly broken? Is there too much close coupling in a big new API? etc.
- Are we keeping it simple? Its always possible to overcomplicate things, leading to technical and administrative debt down the line. Its an important thing to consider over time.
- Are we a self organising team? Are we reacting to customer questions and needs without having to have a team-wide meeting? Are we doing the right amount of planning individually? Are we making sure that code gets reviewed as its being developed?
- Who gets the red stripe? After the retrospective we all have a beer. If anyone has done anything particularly bad (for example I managed to write some code that kernel panic'd our CTO's macbook) then they're required to drink a punishment red strip beer. This helps ensure the exercise ends on a positive note since its the most jokey part of the retrospective.
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.