The “sticky shotgun” retrospectivePosted: April 17, 2011
I’ve been meaning to write this since early last week, but my first two weeks at Betfair have kept me fairly busy. After a nice chilled weekend, I finally have the time to get this down!
So I started a new job at Betfair at the beginning of April and have gradually been introduced to a few different ways of doing things. On my second day, we had a retrospective for the team’s previous sprint – which obviously I didn’t participate in, so I had the benefit of seeing how they do their retrospectives before being actively involved in one. The approach was subtly different from what I’ve done before, and I thought it worthwhile to share with others that work in a Scrum team.
Martin explained how it worked (for the benefit of a few of us that hadn’t done it their way before) and used the term “sticky shotgun” – which I think describes it quite aptly. Here’s how it works…
Everyone is given a marker and a pad of PostIt notes (or “stickies”) and writes down whatever comes to mind from the previous sprint. When they’re done, they all go up and stick them on the whiteboard in the correct zone (hence the term “sticky shotgun”). They use five zones: Start, Stop, Keep, More, and Less.
After the sticky shotgun, the stickies are clustered together into groups of similar issues. As you might expect, there are bound to be a lot of similar issues raised, as everyone has worked on the same user stories within the same team for the last two weeks. Instead of going through each individually, grouping them speeds up the process. To make sure nothing has been misinterpreted, they are always checked with the author to ensure that they’re put together in the correct group. We then briefly discuss the issues and try to identify what needs to be done to solve them; or in the case of the “keep” issues, what was done that makes the item worth keeping.
After the grouping and discussion, everyone is allowed to select their three most important groups. This helps rank the groups in order of importance so the team knows what needs to be addressed first.
This approach seems to provide a few distinct advantages over the way I’ve done retrospectives in the past:
Firstly, it allows a greater degree of participation. Not everyone is comfortable voicing their opinions in a group – particularly when they’re talking about the areas that need improvement. Allowing each person to note their thoughts down independently ensures that their opinions are heard.
Secondly, it speeds up what can be a very time-consuming meeting. It is very likely that a number of people have similar issues. This method allows everyone to voice their opinions without needing hours of everyone’s time. It also clearly identifies those opinions that are shared by a large number of people on the team.
Thirdly, it prevents snowballing. Quite often, one issue sparks off another and another – and before you know it, you’re not really focusing in the right direction. The point of the retrospective is to raise the issues, not to solve them. This approach provides for a relatively short period of problem identification, followed by a short period of problem definition, followed by a final short period of problem prioritisation.
Overall, it was very interesting to see a different slant on retrospectives, as they seem to be the quiet brother/sister in the Scrum family that no one talks about. There are hundreds of discussions over how we write user stories, how we estimate and assign story points to our user stories, how we sell Agile to customers – but I don’t recall seeing as much discussion over retrospectives.
Ultimately, it is the retrospectives that help us to see what we’re doing right or wrong and where we can improve. So it’s definitely a topic worth talking about.