Retrospectives…that good ol’ Scrum ceremony that few people get right. I have observed other Scrum teams and Scrum Master’s in action - what is it with retros that people just don’t understand?

Perhaps it’s not really knowing what the outcomes of this ceremony should be, or a fear for it becoming more of a “therapy session” than a productive meeting.

I recently observed a retrospective at an organisation who were “doing Scrum” for some time, yet always used the same technique and couldn’t really see what they were doing wrong. They had 3 columns on a whiteboard - “Yes|No|Tasks” - each team member was given post-its to put in the first 2 columns, despite there being around 30 different issues in the second column the team managed to come up with a mere 2 tasks to take forward. When I questioned the team why there were only 2 tasks, the response was that their manager didn’t have enough time to take on any more.

Hold up…isn’t agile meant to be all about self-organisation and teams feeling empowered in every step of the agile process?! It was this observation exercise that inspired me to write this blog post.

Let’s do a little bit of history. When I first started out as a Scrum Master my team knew one and only one retrospective game:

Behold the “moaning grid of webdev” as I have renamed it. The grid above brings back such bad memories for my team of boredom and lack of interest that I have given it its own name. Don’t get me wrong, this grid is great for new teams and forms the basis of my retrospective games - but using the same game every time you have a retrospective is soooo boring.

So what did I do?

I noticed very quickly how the developers in my team simply weren’t engaging with the grid, and decided to try to make it a bit more fun. I still bring back the grid now and again when time is short or we’re not feeling particularly artistic that day. However, it’s important to ENGAGE your team, to make retros something they look forward to, to involve everyone - every member of my team have had the opportunity to choose the game and to draw it - the so-called “taking ownership” aspect that agile teams NEED.

So what kind of games can you play?

Anything that is relevant to team. Let them come up with the ideas, it doesn’t have to be anything sensible - we’ve done everything from an orange to a space rocket. They all follow the same kind of principle but help the team to really become involved and contribute towards the ceremony.

An example implementation:

1. Draw your object in the centre of a whiteboard (make sure it’s large enough for all participants to see clearly)
2. Draw 4 arrows coming out of the object pointing in the direction of a compass (North, East, South, West)
3. Collaborate with the team to come up with what the 4 arrows should say. These should be relevant to the object, and each direction should represent one of the grid squares from the image above
4. If you don’t have a clear “actions” direction, don’t worry - this is often better to be separate, just make some space at the bottom of your whiteboard to allow you to write these down
5. For each action, assign either an individual or a couple of people to the action. If it’s the whole team’s responsibility, everyone should be assigned
6. Assign a suitable timeframe for each action. If it’s an ongoing thing such as ensuring tests and documentation are completed, make sure to check up on the progress of this at future retrospectives
7. At your next retrospective, go over the actions from the previous sprint and follow up with anyone who hasn’t progressed their action yet

Of course, once you get more comfortable with the above you can adapt it to suit your team better - after all isn’t that what agile’s all about? Please don’t forget to get the entire team involved to prevent it becoming a Scrum Master vs team type therapy session - ain’t nobody got time for that!