Hybrid Sprint Retrospective for Hybrid Software Delivery Teams!

Table Of Contents

Remote teams? In-person teams? Hybrid teams? Whatever the setup is, one thing that becomes cumbersome as the time grows is 🥁….The Sprint Retrospective.

As a manager, it becomes a bit tricky to facilitate, especially when you’re new to this. Giving everyone a chance to speak makes it a bit like a bustling marketplace, and going completely async makes you chase everyone to finish the document, and then compiling it is a bit of a puzzle!

But don’t worry, fellow managers! This post aims to help you conduct your sprint retrospective as smoothly as a well-orchestrated performance. Let’s turn that retrospective chaos into a harmonious symphony of productive fun! 🎼🎉

Basics 🎵

Let’s understand what is a sprint retrospective and why is it needed?

Sprint retrospective is a way to analyse how smooth is our team’s cadence to deliver something they commit to, predictably.

Sprint Flow. Source: Middleware App

So, usually at the end of every sprint, the team gets together to reflect on how their plan went and also what unplanned things they worked upon. Usually starting with the grid like below:

Source: Middleware App

Now, let’s get into tactical details of how to conduct the retrospective for your team.

Setup 🎼

Book a dedicated time on the last day of every sprint for 60–90 minutes based on your team size. All your members will need to participate, so keeping a video (zoom/g meet) call will help manage everything easily.

Prepare a fresh single retrospective document for every meeting. You can get started with this template.

Define the sequence 🎻

The format of the retrospective is hybrid (being in-person as well as filling out a document). The team is on the same call/room but has to communicate everything via the written document pre-shared with them. Think of it like your team members all sitting together in an orchestra, each contributing their part perfectly, but this time they’re typing instead of playing musical instruments! 🎻💻

The sequence of the sections here will be:

  • Categorisation of the tasks into the quadrant as described above (Planned/Unplanned, Successful/Failed)
  • Reflection on each task and mention “what went good” and “what went bad”
  • Problems in the sprint
  • Good things that happened apart from tasks in the sprint
  • Learnings from the sprint
  • Suggestions for the next sprint
  • Team conclusions: Problems and Suggestions that had consensus from the team.

The whole team goes section by section. When one engineer is done penning their thoughts, they write “[DONE]” in front of their name to signal that the team can move forward. Once all are done in a section, you move to the next one.

Play 🎶

At the end of every section, the conductor (the manager) of the meeting should summarise and write down the popular thoughts from the section. It’s like weaving all the different musical notes together into a beautiful composition! 🎵 So after each team member has penned down their thoughts, it’s time for the manager to spotlight the common problems and good stuff. Keep the ideas flowing and let the team’s voices blend in perfect harmony!

Reflect 🧏‍♀️

“Learn from the past if you want to predict the future.” — Confucius

Remember the “Conclusions”, you wrote on behalf of your team? After the sprint, you and the team would be working to resolve those problems, right?

Let’s validate it in the next sprint by asking your team for a show of hands when you iterate through the problems of the last sprint to know whether it was resolved or not. Only check off the problem(s) when the whole team agrees to it.

Since the symphony is made by everyone 🎶, it’s important to get their vote and buy-in to solve the problems and, soon you’ll see the problem list going away leading to the smoothest melody of your team’s success!

Recent on Middleware blog