Nobody watches a Formula 1 race and thinks the pit stop is a waste of time. The car needs fresh tires and quick fixes to keep going, and that makes sense to everyone. For a team, the retro is some kind of pit stop. Yet, when sprint pressure kicks in, the retro is often the first meeting to get cancelled. In my experience, it is the one that decides whether a team keeps getting better or just keeps getting busier. Here is why retrospectives matter, and what the research says about it.
According to Scrum, the retrospective closes every sprint. The team looks back at how the sprint went, not just what was built but how it was built: Team collaboration, processes, tools. Then it agrees on concrete improvements for the next sprint. A retro is not a status update. It is the team’s time to bring up day-to-day tensions and obstacles, and to fix its own ways of working.
It sounds logical and simple, and it is. But it is also the event that is easiest to skip. There is a deadline, the backlog is full, the first team members are declining the retro invitation and "Okay, let’s do it next time" sounds perfectly reasonable. Still, there are good reasons not to skip it. Some of them are hard to measure, but you can feel them in your daily collaboration. Others we can back up with data.
Broadcom analyzed anonymized data from thousands of agile teams. Teams that regularly hold sprint retrospectives showed 24 percent more responsiveness and 42 percent higher delivery quality, with less variability. Honest consideration: this is a correlation, not proof. Good teams may simply be more likely to do retros. But it fits what I see in practice.
Researchers from SINTEF and NTNU, who study retrospectives in large-scale agile projects, point out that many practitioners consider them the most important agile practice. And a case study following agile teams over five years found something worth remembering: teams regularly running retros were significantly more satisfied and implementing more improvements. Interesting fact to be mentioned: The satisfaction depended on enthusiasm of team members and on whether earlier improvements had actually been implemented.
Two main takeaways: First, retros are successful if they have regularity. Secondly, retros work when they lead to change, people stop caring when they don't.
The magic of a retro is not in any single meeting, but in the rhythm. One small improvement per sprint does not look like much. After ten sprints, it is a different team. It is a steady flow of improvements that allows teams to maximize their productivity and collaboration. Skip the rhythm, and problems will not disappear immediately. They pile up quietly, until they show up as missed deadlines, tense discussions or demotivated team members.
I have seen this myself with one of my previous teams. We ran retrospectives regularly, but the same topics kept coming up. When things got busier, the team decided to skip them: “We don’t have any issues anyway, and we collaborate perfectly fine.” So we skipped once, twice, maybe even three sprints in a row. As the Product Owner, I was monitoring the team’s efficiency and KPIs, and they started to slip slowly. I didn’t see the connection to the skipped retros at first. But when we opened the topic of the declining numbers, it became clear.
What we found was that it would have taken only small adjustments in how we worked together. For example, there had been a misunderstanding between two team members, and they had simply stopped talking to each other. We could have solved all of this in a single retro. Guess what: from then on, it was the team that asked for the retro.
Looking back, that story was about more than a skipped meeting. Retros do something no board or dashboard can: they give people a place to be heard.
When team members see their feedback is taken seriously and leads to actual change, they stop feeling like a resource and start feeling like owners. That is where a successful retro starts, on the people side. When team members have a voice and see that something actually changes, trust grows, and with it the safety to say the uncomfortable things. Without that trust, a retro stays on the surface. I’ll go deeper into the topic of “Psychological safety”, how to involve and motivate different personalities and deal with difficult moments in my next blog post.
The second success factor is how you run the retros. Change the format now and then, so the retro does not turn into a ritual. Follow up on the actions you agreed on, because nothing kills motivation faster than an action item that quietly disappears. Make sure the introverts have a voice too, and do not overwhelm the team: two or three topics that you discuss properly beat ten that you only scratch.
After all we know now, what’s the quick wins for you and your next retro session?
1. Start with last time's action items. Which were done, which were not, and why? It is the fastest way to show that the retro matters. You’ll see that this is a fast and easy way to show that a retro really matters.
2. Give everyone a voice. Let people write down their thoughts before the discussion starts, so the introverts do not get drowned out. Timeboxing each topic and if needed each person’s turn also helps, so the most talkative voices do not take over.
3. Change the format. If the team groans at Start-Stop-Continue, try a Sailboat or the 4Ls. You’re immediately catching the team’s attention if they have to think a bit differently or if you ask different questions.
*Sources:
https://solutionsreview.com/business-process-management/broadcom-the-impact-of-agile-quantified/
https://www.sintef.no/en/publications/publication/0198cc62f324-c45ad611-6d9f-4497-b14f-6e96dba9d1f5/
Share article
