Tom Nason Team : Project Manager Tags : Technology Web Development Business Management

The importance of retrospectives

Tom Nason Team : Project Manager Tags : Technology Web Development Business Management

Learning from experiences is important both at work, and in our lives outside of the office. If you cook a nice meal and then add a bit more chilli than your live-in stakeholder can handle you're going to have a bad time, and it’s unlikely that you'll make the same mistake again.

So if you’re team has a rough week, do you have a beer and do your best to forget about it? Conversely, if you have a productive week, do you simply cross your fingers and hope it happens again?

Retrospective sessions help us learn from our experiences and improve the way we work both independently and as a team. Getting together and discussing “how things went” is one approach, but for the session to be truly valuable we need to add a little structure to the conversation.

Establishing a positive culture

Getting started with retrospectives can be a little tricky, and without proper direction the meeting is at risk of becoming a negative “gripe” session. The key here is to guide the conversation in a positive direction. It’s about solutions to problems, not the problems themselves.

The sentence below provides a great introduction. Print it out, stick it on the wall, and read it out at the start of your first few sessions. Refer to it as soon as things take a negative turn, or if there’s even a hint of finger pointing.

Regardless of what we discover, 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.

Structuring the conversation

There are a number of approaches here but I'm a huge fan of simplicity and have found the following questions to be a great starting point. The plan is to get input from everyone, so go around the group and be sure not to miss anyone out. Great ideas often come from those who aren't immediately involved in the particular part of the project being discussed.

  1. What did we do well?
  2. What could we have done better?
  3. What should we do differently next time?

Note the emphasis on the team rather than focusing on individuals.

Documentation

There’s really no point sitting down to perform a retrospective if we don’t track our progress.

There are obviously a number of ways to write up our findings for future reference but I would recommend starting with sticky notes. Get everyone to write down a summary of their answer to each of the above questions in silence. Then ask them to present each as they stick them on a board separated in to three columns, one for each question.

Answers might be technical in nature, or more process oriented. Don’t hide from the tricky stickys. If a team member feels that you aren't working well together, discuss it, address any issues and track your progress.

Remember that it is just as important to track and remind ourselves of the things that worked well, not just the things we’d like to improve.

If possible keep all of the notes on a board near your working area and start each session with the same notes. If you start seeing repetition in the latter two columns make sure you are prioritising these when discussing solutions.

Working in a larger organisation where multiple teams are working on similar projects concurrently? Take the time to compare boards with the other team leaders. It is entirely possible that you have already solved some of each other's problems.

Timing

How often should you perform a retrospective? Ideally at the end of each sprint, if you’re working in an Agile environment. Otherwise schedule them approximately two weeks apart and adjust as required. You'll likely find that they take a little longer at first but over time you shouldn't need more than an hour.