Retro: My favourite meeting

If you ask people in business their favourite time of the week, I would imagine there will be a high percentage of answers that mention Friday afternoon. For many of us, we long for Friday afternoon to clock off and go home, putting the stresses of the week behind us, forgetting about them until Monday.

I’ve spent the last three years looking forward to Friday afternoons – a little before hometime – because that’s when we’d hold my favourite meeting of the week – Retro. “Favourite meeting” – I bet you didn’t expect to see those two words together!

If you don’t know what Retro is – and it has nothing to do with tie-dye, flared jeans or cassette tapes – it’s simply a short meeting where the team get together to pick over the highs and lows of the work that has been done this week, or in the current iteration if it’s longer than a week. Retro is one of the “ceremonies” in Scrum, and for me, it was the fuel that drove me forward week after week.

The purpose of a retrospective is to take stock, look at what went well, what didn’t go so well and perhaps some of the reasons why – and importantly – think about some actions you could take as a team to put these things right before the next iteration of work.

A number of team members mentioned – even in exit interviews – that our pre-COVID retros, where we’d all be in the same room writing on post-it-notes and having some “group therapy” – were their highlights of working at Relative. In the COVID era, some of the sparkle was taken away by working from home, but we achieved the same results using a shared document that everyone contributed to while on a Google Hangout.

Think about some of the conversations you have with colleagues about work. We love to vent our frustration when things don’t go to plan – complain about people not appreciating the effort we’ve put in, or someone outside the team causing chaos because they haven’t kept a promise. Now imagine you turn these gripes into a structured session where they can be captured and turned into actions so the same gripes don’t hold you back time and time again… that is what retro is for.

And it really works!

During one of our retro sessions, when the whole team was working on a particularly large project we kept finding that work was stalling and not making it into production. We worked on a board with a number of columns, similar to the one below.

Replicate JIRA Scrum Board – Klipfolio Help Center
An example Jira Scrum Board (not our board).

Our problem was that tasks were being moved from “Review” to “Test” and then abandoned, because nobody was taking ownership of the test process. Once a dev had “done” their task, and dragged it to “testing” they relinquished all ownership and moved on to the next task. Every day at standup, we’d talk about what we did yesterday, what we were doing today and if we had any blockers. But we were ignoring the fact that all of this work wasn’t actually making it to the “done” column.

During retro, we were discussing this frustration when one of the team suggested our standup was the problem – or at least part of it. Because we only talked about what we were doing, it was easy for things to get stalled and nobody to challenge them. He suggested we could switch our standup to a “walk the board” technique instead, where we start at the done column and mention tasks that have just moved to done first, then move backwards talking about each card in turn. This meant that instead of being pivoted on each team member, standup was pivoted on each card. It was impossible for cards to be ignored, forgotten or stalled. It gave us a tool to jog people into taking action to carry out testing on stuck cards and get them across into the done column. Following retro, we changed standups in the next sprint and the retro at the end of this sprint was a lot more positive. We got instant improvement.

When we first started doing Retros, we had no idea how to make it work. We sat around my desk with a blank document and I asked everyone if they had any issues. We all stared at eachother blankly – some people uttered a few casual gripes but tempered them with “it’s not really a problem” and we moved on. It felt a bit pointless, awkward and unproductive.

Through a bit of research, I discovered some nice techniques for Retro and after we’d done a few with our new format, it stuck, and we did it that way ever since. So, I’d like to share our approach, and perhaps you can take some parts of it and do something that works for your team.

First things first – when you’re having a retro, try to schedule it at the end of a sprint. Ideally, the last day of the sprint – while things are fresh in people’s minds. You want to feel the pain – you want to hear the frustration in their voice – and you want details. Don’t leave it days or weeks – you will lose the momentum and the value. I found it a great way to round off a Friday afternoon, after we’d completed the work and delivered to the client, we grabbed a coffee, huddled around the meeting room table and let it all out.

The Story Oscars

The important thing to start with is capturing people’s high points and low points in the current iteration of work. This is where you will really get the juice to fuel the rest of the meeting. We did this with the “Story Oscars”. We asked all the team members to nominate a story from this iteration as the “Best Story”, and one as the “Worst Story”. We then take each story in the “Best” category and ask the nominators why that was their best story. This is a chance to find out when things went really well; hear about some new techniques people used or when they got a chance to put some learning into practice for example – and even when they collaborated with someone and it worked well. This is a great time to spot new ideas for processes, tools or techniques that could be spread more widely in the team, or just measure the success of recent improvements.

With each story talked out, we find the one with the most nominations and crown it the “Best Story”. We then repeat the process for the “Worst Story” nominations, and this is where it gets interesting.

Worst stories take many forms – the one that wouldn’t go away – languishing in “in progress” for the entire sprint, the “boomerang” that was done and not done, and redone again, or the one that should never have been there at all. This is where the group therapy kicks in and people get to vent their frustrations in an environment where everyone can empathise with them. Our sessions never involved blame or any kind of internal strife – and this is important. Occasionally we had some rants about customer expectations or uncooperative external parties but as a team we rallied round and supported eachother as we let out our frustrations. As a facilitator I took the opportunity here to capture suggestions during this part of the session for how we might avoid these kinds of things in future, which I added to the board as placeholders for later.

Finally, we crowned our “Worst Story” – and moved on. It’s funny how this works sometimes – many times we had someone nominate the same story as their best and worst, and people often sympathised with colleagues and nominated story they hadn’t worked on as the worst because they’d seen the frustrations their colleague faced. If there was no clear winner, we asked if anyone wanted to switch their nomination, and finally we’d put it to a vote. If we still had no clear winner, I would choose one based on the “supporting stories”, and we’d capture as much information about the feedback as we could.

Squad Health Check

Next up is a squad healthcheck. In Squad Healthcheck we choose two topics at random each week and we dish a red, amber and green card to each member of the team. I would read out the topic, along with a description of what “red” looks like and what “green” looks like, and ask for a show of cards as to take the overall vibe of the team on that issue without forcing anyone to say any more about it.

Squad Health Check Card Deck by Henrik Kniberg – Agile Stationery
We used these awesome Squad Health Check cards from Agile Stationery

We’d capture red, amber or green for each of two topics (we had about 20 topics that we’d rotate each time), and provide an open forum if anyone wanted to discuss any further or make suggestions. Often they did, but I never asked anyone to justify their choice individually. This can be a bit of a tightrope. You don’t want to put anyone on the spot but it’s important to understand how things can be improved. In my experience, after a couple of retros people spoke freely when they saw the benefits.

Start, Stop, Keep

Finally, we had a table of “Starts, stops and keeps” like this:

This is one of our actual retro boards showing Start, Stop Keep and a list of actions

The idea of this is to take what’s been discussed and turn it into actionable changes in your process. Things we should “Start” doing – like “documenting setup process for new repos”, “Stop” doing – like “moving cards to ‘in-progress’ without confirming acceptance criteria”, and “Keep” doing – like “TDDing new classes”. The example board above was in our very early days, and we had a lot of suggestions. Honestly – we rarely implemented half of them but we kept records and honed the process as best we could. After twelve months, this board rarely had more than one or two notes on it and we felt like we owned the process.

Turning it into something useful

The final point is to distill all of this down into a set of actions. We usually created actions that were to be done in the next iteration, and assigned them to individuals there and then. People often volunteered, and we used this as the concrete output of our session. We captured everything – all of the post-its and comments – in a retro document which was published so the whole team could refer to it at any time.

What you do with all of this insight is important and the best way to use it is to start your next sprint planning session by reviewing the output of your Retrospective. What were the start/stop/keeps? What actions need to be done in this iteration? Refreshing everyone’s memory on Monday morning is a great way to turn all of this feedback into results.

Continuous improvement is natural to me now, and at Relative it was core to who we were. You don’t need to be perfect – you need to learn to spot your flaws and find ways to work on them. That’s what retro helps achieve, and it made me feel a sense of progress, a sense of improvement, camaraderie and positivity every single week. Instead of creating a toxic culture of griping and harbouring resentment, this little meeting turned all of that negative energy into something positive and constructive and left us all feeling good – even when it was a tough week.

Have you tried retros? Do you have any suggestions for activities that work well? I’d love to hear about it.