Having worked at the BBC for over a year and a half, I have participated in many retrospectives, run at the end of sprints (2 week iterations in agile scrum projects) or at the end of a project. They are a forum to reflect on what the team thinks is working well, what is not working so well and what could be better. As a result of the meeting, actions (informed by the points and issued raised) are taken forward into the next two weeks or the next project as improvements.

Retrospectives are usually facilitated by the scrum master or project manager. However, my current team takes a round robin approach to selecting the next chair from everyone in the team, whatever their job role.

Last sprint it was my turn, which meant I had to decide on the content of the meeting.

There are many ways to run a retrospective; every one I’ve been to has been slightly or vastly different. The most common is where team members contribute their thoughts on what the team should ‘keep doing’, ‘stop doing’ and ‘start doing’. Usually pieces of paper with these headings are stuck onto the walls and people write their ideas on sticky notes and place them under the appropriate sections. The stickies are grouped, then discussed. In this case, actions mainly come from ‘start doing’. There are also lots of resources aimed at making retrospectives fun. One of my favourites is the car analogy. Everyone is asked to draw a car they think represents the team and then explain why. You tend to get rusty old cars and missing wheels. Everyone is then asked to enhance their drawings and explain again. Now you see turbo engines, nitro and other sports car features! These are rather generic, but you can also focus on individual areas. By this, I mean you can focus specifically on e.g. improving current issues, stopping bad habits, adding new techniques or resolving blockers. This can be useful for tailoring actions to the current needs of the team.

To decide on the needs of my team, I took a look back at our usual process. The main content of our retrospectives is some mix of activities similar to those mentioned above. From these, we write a bullet pointed list of actions onto an A1 piece of flipboard paper and stick it up next to our agile board. During the next retrospective, we assess the progress made towards each action. Usually, some progress has been made on most actions, but few actually completed and some never even begun. This made me think: is this because the actions aren’t worthwhile enough in the eyes of the team? I.e. do the advantages outweigh the effort of completing the action and is the action’s outcome actually that useful? Consequently, I decided to focus on blockers; as the ‘unblocking’ actions would have a direct, immediate and useful impact on the team, I hoped people would feel more inclined, enthusiastic or even eager to work towards the goals.

To demonstrate my above points, I began the retrospectives by reviewing the most recent actions. I coloured coded the progress made: red for none, yellow for some and green for complete.

For my first activity, I used elements from a technique called the timeline. I drew a two week, Monday to Friday timescale and got people to sketch out what they had been working on. This was mainly to remind everyone of their recent work, but also provides a good way to evaluate the length of time spent on different tasks.  I briefly ran through board with this in mind.

Next, I had people think of anything that made those tasks more difficult; issues that blocked progress, slowed down the pace of work or distracted from the task at hand. These were written on sticky notes and placed around the corresponding tasks. Visually, the amount of sticky notes can show tasks (i.e. a release) that had many problems. I talked through each area and asked people to elaborate.

I then asked for a volunteer to pick out a blocker they would really like to see unblocked. To the volunteers surprise, I threw a balloon at him and instructed him to blow it up! Balloons you ask? My way of bringing a little fun to the meeting, but, bear with me, they are far more than that. As a group, we discussed and decided on an action for that blocker which was then written on the balloon. Finally I asked my volunteer to also write his name on the balloon. I explained that this assigns him responsibility for the action – not necessarily completing the action himself, but making sure someone does. I believe assigning someone to a particular action, which we haven’t done in the past, is likely to improve the level of progress made towards it.

We repeated this for as many balloons as people had blockers they cared about. Some people took multiple balloons and some took none. I felt this was fair because people were volunteering themselves, not being forced into unwanted extra work. I purposely only took 10 balloons into the retrospective. I wanted to limit the number of actions that emerged so that completing them in two weeks would be realistic. Unfortunately, as time was running out towards the end of the meeting, not all of the actions were fully discussed amongst the team members. It did not occur to me at the time, but it would have been useful to quickly recap each balloon just so that everyone had a clear, common understanding.

After the meeting finished, I pinned up each ballon underneath our scrum board. I think the visibility of the actions is another contributing factor to a retrospectives success. Previously, the list was visible but slightly round a corner.

The reason I choose to use balloons: they are a good metaphor for blockers. I used red balloons because the colour is known to signify ‘stop’ or ‘bad’ and placing them beneath the scrum board posed a (somewhat) physical blocker to engaging with the board’s tickets. And of course – the best part – popping the balloons! Completing an action and unblocking the blocker is analogous to that satisfying feeling of deflating the balloon. Once popped, we replaced it with a green card (the colour of ‘go’) detailing what we did to complete the action.

This was the board at the end of the two week sprint. As you can see, not all of the balloons are popped, but there are more completed tasks than usual. What is not obvious is that progress was made (again more than usual) on all but one of them. As an improvement, I would suggest placing small yellow sticky notes (colour for ‘get ready’) next to the balloon for each step of progress made, so the progress is visible and quantifiable.

In retrospect (note the pun), focusing on blockers and using balloons did not have the drastic impact as I had hoped. However, there was a definite enthusiasm to getting those balloons popped and, as stated, more progress and completions than usual.

Overall, I enjoyed running my first retrospective and feel it was a success. We have decided to keep the balloons more generally for all actions as opposed to just blockers.