JournalJun 2014

Running faster retrospectives to help your team learn and grow quicker

It’s only natural that left to our own devices, people will get caught up in the day-to-day and not necessarily take the time to look back, analyse, and figure out how to improve. If that’s the case, you can find yourself repeating the same mistakes over and over again.

One of the most valuable tools I’ve discovered in the past couple of months to help avoid this, and get the fastest and most helpful insight into a situation in our team, has been the ‘mini-retro’.

This has been hugely helpful for our team, so I thought it would be helpful to share both our process, and a template that you can use for your own team.

So, what is a mini retro?

You might well be using retrospectives already–if you’re working with an agile process, then holding a retrospective at the end of each sprint is a widely accepted way to encourage continuous improvement, and make sure everyone is taking the time to regularly look back, analyse, and improve for the next time around.

A mini retro is slightly different–it’s effectively an ad hoc retro, which can be called by anyone on the team. For us, it’s usually triggered by a negative event – something which didn’t go as planned. It’s reactive, fast, and focused on asking ‘what is the problem?’ and ‘what can we do to improve this, next time around?’.

  • The goal is to get a fast analysis of a problem. It supplements broader, scheduled retrospectives at the end of a sprint or project, and is an extra tool to help support your team.
  • A regular retro would also retrospect on what went well. Technically there’s space for this in our mini-retro if you want to cover it–it’s not specifically excluded, but since the retro is triggered by something which didn’t go as well as hoped, our key focus is trying to improve this for next time.
  • Our goal isn’t to lead a deep retro–convenience is key, and it should be built into your workflow, via a reusable and easily accessible template.

Why use them if you’re already doing scheduled retrospectives with your agile sprints?

I’ve found that one of the biggest problems with relying on sprint retrospectives, is when you need to get a different kind of feedback, or when you need a retrospective that doesn’t fall neatly into a development project sprint.

A mini-retro can be called for any decision or situation–for example, a meeting you might have had with a client; or a problem that came up on an internal task. It can catch those events which would otherwise slip under the radar and fail to be caught by a sprint retro. It’s also very valuable if you don’t run a properly built agile process on every project you do.

And even if you are doing agile, with sprints and retrospectives, it’s sometimes necessary to get faster feedback, rather than waiting till the end of the sprint. Sometimes that feedback would arrive too late, otherwise.

They really shine:

  • When you’re tackling new tasks or working with new or inexperiencd team members – giving more frequent feedback, as early as possible, can be especially valuable here.
  • When the problem isn’t necessarily related to the whole team. The mini retro should be visible to them, but they don’t necessarily need to engage, I’ve found mini retros to be useful even in resolving tricky situations between 2 team members. If the team and the company has the right cultural approach, i.e. “problems happen–let’s try and make both our lives easier next time and do this better”, then a retro can be hugely positive, even if it’s triggered by a very negative event.
  • When you’re dealing with a potentially ‘finger-pointing’ situation. The retro is a calm place to have a positive discussion, without resorting to blaming each other. It’s hard to understate the value of this. It can stop conflict in its tracks, rather than letting it simmer for days or weeks.
  • When you want to properly break down a specific event, like a meeting which didn’t go as well as planned, and learn as much as possible from it. Here, ‘freshness’ of recollections can be really important – the sooner you record the ‘symptoms’ or problems, the more detail you’ll be able to collect. Even a few days after the fact, our recollections tend to be a bit fuzzy.

My suggestions for implementing them:

Our approach isn’t dramatically different from a regular retro, but we’ve modified the structure and tone of the discussion to allow us to get the learns we need, as efficiently as possible.

The discussion format that works for us, is:

  1. What didn’t go so well?
    Add problems, symptoms, and things which weren’t as good as hoped for. Do this first.
  2. Learning & Reasoning
    Try to figure out why the problem might have come about. What have I learned from this situation?
  3. Improvements
    How can we improve this for next time?

And the process is something like:

  1. Some sort of problem comes up on a project – for example, a client meeting didn’t go as well as planned, and has left a project in a tricky position which needs to be resolved.
  2. Either you (as the team lead) or one of the team members involved, initiate the retro, and duplicate the template, add a subject line (to point discussion in the right direction) and send a link to those people involved, who you think can contribute.
  3. All involved drop ‘symptoms’ and issues into the first column of the template–as many as we can identify. We avoid trying to ‘solve’ each of these symptoms on first-pass.
  4. Once we’ve added the symptoms, we can then either individually add our analysis (learning and improvements) into the template (useful in geographically distributed teams), or we can line up a quick chat to fill in the gaps together.

The goal is to come up with actionable takeaways, and shared learning, that can be put in place right away.

  • The value is in their speed – use a template so that people can create a retro at any point, and get feedback fast
  • Use a lightweight platform – we use Google Docs, since that’s our tool for all written content. Make it easy to contribute.
  • Empower anyone to create and lead a retro–they are not ‘top down’–if you embrace 360 degree feedback, it will allow you to identify many more problems and also get the whole team thinking about proactive changes to the way they work.
  • Put the focus on identifying all the weaknesses you can spot together, and then coming up with ways to improve this for next time. It’s not about perfect, final solutions, but rather, continuous improvement.
  • Create the right cultural approach and instill a desire to get feedback at all points–rather than a cultural defensiveness.

Our template

You can see/download a copy of our template as a Google Doc, here—hopefully you’ll find them as positive as we have at Hanno.

Photo credit: psd

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.