Something you can do right now - Retrospectives

I've mentioned the practice of retrospectives in a previous blog about processes, but I think it's worth diving into some more detail, as it's something that you can do right now, without having to fully implement Agile or Scrum. 

The time commitment from you and the team is very little: normally just 10-15 minutes. If the team is operating in regular sprints, then it's normally done at the end of each sprint (every 1-2 weeks). Or if not, can run at any time, but it should be done throughout the project rather than just at the end. And every time you run one, there will be specific actions identified, that if done, will most likely result in tangible improvements to the team's performance.

Again, I'm not an expert in Agile or Scrum, but this is what I found works well.

How it used to be done (if at all)

Project Post-Mortem

Back in the day when I was a project manager, one of the project management best-practices at the time was to perform a project review at the end of the project. The goal of it was to assess how well the project went and whether there were any "lessons learned". I performed them at the end of several projects, and we came up with some great lessons - fantastic!

But by that point in the project, the team had already disbanded and moved onto the next project. And politically, the company didn't like to put the spotlight on issues that occurred, so the lessons would get brushed under the carpet. So guess what, when the next project came along, the same mistakes kept happening……. so don't just do it at the end of a project.

And if you are wondering why I have a picture of a grave here, they used to call the project reviews "Project Post-Mortem's" - no wonder they were seen as a negative thing.

What is a Retrospective?

If you have ever been on an Agile/Scrum project, one of the core practices is called retrospectives. Retrospectives are performed regularly (not just at the end of the project) to review the way that the team is working and identify improvements:

• Things that are working well, i.e., keep doing them!

• Things that are not working well that need to be improved. The cause of these issues are often:

1. The team isn't following the process, and because of that, they are being impacted by issues that the process was designed to address. In this case, the team may need reminding of the process, and/or receive training to make sure they understand the process so they can use it; or

2. The issue isn't addressed by the process. In this case, the team may suggest some improvements to the process that addresses the issue and agrees to try one of the improvements in the next sprint.

Then in the retrospective and the end of the next sprint, the team is able to validate:

1. The team is following the process this time, and the issue that occurred in the last sprint has not reoccurred; or

2. The team has tried the suggested improvement and ….

• It worked! The improvement should be captured in the process so that other teams can benefit from it, or;

• It didn't work, in which case the team will suggest an alternative improvement. As part of this, some research may be done to find out if there are any established best practices being used in other companies that may help. The team agrees to do an experiment in the next sprint to see if the improvement addresses the issue.

….. rinse and repeat……

What's magic about this is that improvements are identified throughout the project, and the project (as well as other projects) can benefit from the improvements immediately - you don't have to wait until the next project.

What does a retrospective look like?

There are a few formats out there, but this is what I use that seems to work well:

1. Divide a whiteboard into three sections with the following headings: "Likes", "Changes" and "Actions".

2. Each team member has blank post-it notes and a sharpie pen

   1. One idea per post-it note

   2. For "Likes", write down the ideas of what worked well and put a smiley face on it :)

   3. For "Changes", write down the ideas of what could be improved and put a sad face on it :(

      Note: the smiley and sad face icons are useful as often the team member will write down a number of ideas in one go and then put them on the board

   4. For "Actions", write down any suggested improvements to address any of the "Changes" ideas

   5. Then one person (I like to nominate one of the team members to do this and rotate that responsibility between the team members in each retrospective) will then start grouping the post-it notes in each section as there will be some overlaps/duplicates. Then that person will take the team through each of the groups of ideas to discuss them. Often we will ask the person who wrote up a particular idea to explain or clarify what they meant by it.  

   6. The team goes through the "Actions" section and agrees which of the suggested improvements should be made for the next sprint.

Done - onto the next sprint!

Tips and Tricks

• I know I've already mentioned it, but because I'm the process guy, I'm obliged to strongly suggest that the processes are documented and updated (and make sure that other teams are aware of them) after improvements have been validated to work, so that other teams can benefit from those improvements.

• In the following sprint, make sure that when the team is doing the retrospective, they consider each recent improvement, as a way to validate whether the improvement addressed the issue it was designed to resolve. If it hasn't, then the team should come up with another suggested improvement for the next sprint. This gets repeated each sprint until the team has been able to validate that an improvement has fixed the issue.

• Sometimes the team struggle to come up with new "Likes" and "Changes" and the same ones keep coming up each time. It can feel uncomfortable for you and the team, but as a facilitator, I keep quiet (which is something I struggle to do )and let there be some awkward quietness until one of the team members breaks the silence and comes up with a new idea no one had identified previously. And then the ideas start flowing again. It is as though the team gets a second wind, and they are now not just looking at the surface level and are thinking much deeper. It's quite magical :)

• And if that doesn't work, suggest to the team that rather than leaving it until the retrospective to come up with ideas on the spot, get them to note down ideas during the sprint and then bring the ideas along to the retrospective.

So what are you waiting for - give it a go!