Agile Retrospectives

I'm sure you have received an email like that. GRRRrrrrrr!!!

One of the most powerful tools available to us as technology leaders is the project retrospective. A well-run retrospective yields opportunities for every team member to improve and it also builds cooperation between individuals. Teams that have adopted the agile paradigm know that rigorous retrospectives result in continued learning and continuous improvement.

But what if you haven't adopted agile?

If anything, retrospectives are even more important for non-Agile projects. Think about this: if an Agile team got 2% better every two weeks by carefully reflecting on their experiences and making corrections, they would get 60+% improvement in productivity over the course of a year! Think about that! SIXTY PERCENT!!! For a team delivering quarterly, you would need to see a 12% improvement each release to even get close. And too many non-Agile teams skimp on the retrospectives because they're "too busy" to get better!

Let's be real. Technology teams must do retrospectives. We should do them after software releases, major deployments, and operational issues. We should always be thinking about what we did well as a team and and as individuals, and what we could do better next time.

A problem, though, is that retrospectives can become finger pointing, complain-athons or benign sessions where everyone smiles and blames someone who isn't present (usually "the customer!") for any issues that may have occurred. A poorly run retrospective is a waste of everyone's time, and that's why they are often overlooked.

So what does a well-run retrospective look like?

Here are some suggestions:

Start with a well-researched timeline of the project. This is best provided by the project manager who should have a full record of all the events. There should be no commentary - keep it to the bare facts. Something like this:

Then ask each team member to come to the meeting with responses to four simple bullets:

  • List zero to three things that the team as a whole did well

  • List zero to three things that he or she as an individual did well

  • List zero to three things that the team as a whole can improve upon

  • List zero to three things that he or she as an individual can improve upon

I impose a couple of simple rules:

  • The most senior person in the room goes first and, even on a "successful" project must fall on his/her sword. The goal here is to set the tone that we are going to talk about what we can improve and as the most senior person on the project, you need to really think about everything you could have done better. This will tell people that the environment is safe to be honest.

  • You can't list more negatives about the overall team than positives.

  • You can't list more positives about yourself than negatives.

  • You can't talk about people who are not in the meeting.

We often focus too much on the negatives. Don't forget what went well. Major achievements must be recognized and embraced. It is as important to repeat the positive aspects of the project as it is to avoid stumbling over previously encountered issues.

Maybe the team got lucky and things fell into place that they hadn't expected -- this should be noted as "luck" but the team should discuss why they were lucky and in a future project could they manipulate the chances of being lucky again by using particular techniques that were used (maybe unintentionally) during the project.

Write up notes and send them to the team. DO NOT modify process documents or take any other process-heavy steps. The goal is to make the 1-2 hour session a good learning experience for everyone. If you back load the idea with a lot of follow up, there won't be a retrospective next time. Just allow the team to learn and grow organically.

When I first did this I was honestly shocked at the outcome. Everyone talked about what they needed to do better. There was no finger pointing. I found that I had to twist people's arms to talk about the good stuff. (This was an "ok" project; not outstanding but certainly not a disaster). But what really surprised and impressed me was how the experience pulled the team together. People started looking out for each other. The level of camaraderie went up. We saw almost instant improvements in cooperation, timeliness and quality of output. A team that had been maligned by months of missed and poor deliveries came together and became a top delivering team in the space of six months.