I am currently available for freelance/contract work. Book a meeting so we can talk about your project.

Getting sprint retrospectives right is hard work

Posted on

After working on my guest article on Next.js last week, it’s time for another side project. I am taking a page out of my own book again by turning my personal notes into a helpful tool. This time, the project will be all about planning sprint retrospectives. If your sprint retrospectives feel like a waste of time, I want to fix that for you.

I am by no means a fan of Scrum. What was once a set of guidelines helping teams focus on what is important is now a lot of boring meetings. Coaches sell Scrum as a silver bullet that turns an unproductive team into a productive one. Going from “no Scrum” to “only Scrum, all the time” immediately doesn’t usually go down very well. When applied without consideration, many develop a distaste for its rigid structure.

It wasn’t the idea behind the Agile Manifesto that all teams need to have the exact same recurring meetings. The word “meeting” doesn’t even appear anywhere in its short text. The only mention of something meeting-like is in this sentence:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

When trying to increase a team’s productivity, ignore most Scrum ceremonies. Don’t start out doing daily standups, estimation meetings, and sprint reviews immediately. You can always add them later, if the team finds them necessary. You only need one regular meeting to help any team improve: the retrospective.

In a retrospective, the team talks about how they are doing and what they can do to do better. It gives them the tools and permission to change how they do their daily work.

Retrospectives are often misunderstood as a waste of time. Newcomers see them as their weekly chance to complain for an hour before going back to their desk. While naming problems is part of the meeting, it ignores the more important second half of the quote. The team has to “tune and adjust its behavior”. While a raging bitchfest can be therapeutic, it is pointless if we do not work on fixing our problems.

The agenda of a successful retrospective follows these five phases:

  1. Set the goal: what do we want to get out of this meeting?
  2. Gather data: what did we do during the last iteration?
  3. Develop insights: why did things happen the way they did?
  4. Decide on actions: what can we try to have more good and fewer bad things happen?
  5. Close the retrospective: how can this meeting itself be better next time?

A retrospective is a complete waste of time if it stops after the second or third step. At this point, all we did was air our dirty laundry. That only puts the team in a negative mood and makes them feel powerless.

For a retrospective to be useful, we have to leave it with a concrete plan on how we’re going to fix what needs fixing. In the spirit of iterative improvement, those actions can be super tiny. We won’t fix a process that is completely broken in one or two weeks. If we tried, our inevitable failure would only make us feel more powerless.

Luckily, we don’t have to attempt to move mountains. We can focus on one small change in each iteration. Over the course of a few months, these tiny improvements will add up to a huge difference.

Engaging the participants in different tasks in every retrospective keeps their creativity high. Instead of asking the same three questions every time, I find it helpful to change the activities up a lot. One week might go heavy on the sticky notes. To switch it up, we’ll use dice and poker chips next week. The week after that we could build something out of modeling clay. The more enjoyable the meeting is, the more valuable I have found the outcome to be. There is no rule that says meetings have to be boring and repetitive.

That’s where my latest side project comes in. Planning a completely new agenda for every retrospective takes a lot of time. My latest tool will help you plan more interesting retrospectives faster. I have a prototype up and running and will likely have something to share in a week or two.

If your retrospectives feel like a waste of time, check if you’re following the phases all the way through. After a good retrospective, a team should have an action plan and feel optimistic. If you’re not, you might be skipping a step or two.

Debug
none
Grid overlay