Too many agile retrospectives feel like an empty ritual, a box to tick rather than a valuable use of the team’s time. People leave the room feeling like nothing has changed, and the same problems will just resurface in the next iteration.
If your agile retrospectives feel like a waste of time or if your team members say less than flattering things about the process of agile retrospectives, this post is for you.
Continue to the post if you are a reader, or watch the video.
When retrospectives feel like a waste of time, the clear indicator here is that it’s not a great ROI of people’s time. The retrospective doesn’t feel meaningful or actionable.
And that’s because it’s not enough to simply discuss problems that might have happened during your sprint or your release; you need to turn insights into concrete action items. These items must have clear ownership, deadlines, and a plan for implementation.
But here, my friend, we’re entering a territory of one of the biggest mistakes I’ve seen scrum masters and agile coaches making: the retrospectives they run don’t have a goal. They are reactive.
So we’ll talk about the purpose of a goal in agile retrospectives, how it’s the best thing you can do to fix your wasteful agile retrospectives and I have a resource for you to download in the end of this post that you won’t want to miss!
Avoid Reactive Retrospectives
Notice I hinted START WITH A GOAL.
Most agile retrospectives I see teams running are actually what I call REACTIVE Retrospectives, and you should avoid them. They are not engaging, and they are in fact wasteful.
Here’s what I mean by that.
Most teams resort to retrospectives templates. They either use a complicated template or go through basic formats like “What went well, What went bad”.
Now here’s a wild proposition: what if instead of simply going through the motions of “Bad | Good” or “Start | Stop | Continue”, retrospectives became a space for deeper understanding of the problems and of elements of performance for a team?
Say your team is using scrum. Say your retrospectives are usually Glad | Sad | Mad. What’s happening here? Are you tackling the underlying issues of what happens inside the team? Or are you just chasing after the latest fire?
These types of agile retrospectives mean in one sprint, you’re discussing a difficult feature, a colleague’s bad behavior, and a broken build. In the next, it’s a new colleague being onboarded and a strange request from the sales team. This is noisy, and it doesn’t lead your team to meaningful improvement. You might fix a quick annoyance, but that’s about it.
I call these reactive retrospectives. And they’re wasteful in two ways.
First, in true agile fashion, if you have a problem, you should deal with it right away. Don’t wait for the next retrospective to fix it. Use the best data available at the moment the problem arises and solve the issue. Don’t create a debt or list of problems yet-to-solve.
Second, reactive retrospectives are scattered. You’re jumping from one unrelated issue to the next, without a sense of progress or direction. Like I said, today it’s the build, tomorrow it’s a colleague with a challenging behavior. It’s like playing catch-up, without ever really moving forward.
It’s a huge misunderstanding that people have that retrospectives are a place for solving problems.
They’re not! Agile retrospectives are a forum for improving. For getting better. And that can mean, yes, to improve on things we’re not good yet, but also, to double down on what we are already good at.
Improving does not equal solving problems. You can solve problems and never improve. Because you solve for the moment, you stay on the surface. Improvement is about tackling deeper aspects of the team performance: how they dot things, and also how they think about the things they do.
So how about breaking free from this reactivity? How about using retrospectives to drive real growth and understanding inside your team?
Proactive Retrospectives for Continuous Improvement
What I always teach teams and their leaders alike is to look at agile retrospectives as a process for continuous improvement of team performance and attack it with the seriousness of planning.
So, we start with a GOAL.
When you start retrospectives with a clear goal and follow a structured approach, you set your team up for success. You flip the script: let’s stop being reactive and start being proactive about team improvement.
But now here’s an important distinction: The key for effective retrospectives that drive continuous improvement, is to identify a meaningful theme theme that resonates with your team. Then, commit to following through on a goal derived from that theme for the next few iterations. A few sprints, a few releases.
How do you do that?
YOU may be the one noticing the trends from data. There is a reason why teams have team lead, team coaches, managers. It is in your role to keep this zoomed out view and looking for what the team might be missing while they’re busy and engaged delivering their work.
Now what are you looking at?
Everything is data: defects, cycle time, the types of user stories, feedback from other people. Check the tools you use. Jira, Azure Devops Board are not just for hosting your user story cards. Extract the data. Maybe some trends appear on your dashboards from the tasks.
So, you could suggest the themes based on your observation. It’s a valid starting point. Or you could show your team a list of possible themes and their importance to get them started and let them pick one they find compelling and move forward with it. Which has everything to do with the free resource I’m sharing with you as well in the end of this post!
If everything else fails, listen to your team’s concerns, ask powerful questions, and agree on a focus area that’s ripe for improvement.
Example of a Themed Retrospective
Let’s add some color by looking at an example.
Maybe your build is broken several times during the week. It’s a good candidate: a problem that keeps happening and the solution is not exactly to fix the build when it’s broken, but rather, avoid having it broken. It might seem at first that the conversation is about build issues. But I promise that if you start probing the conversation becomes about quality.
You don’t need a full hour to decide that you need to make sure your build always runs green. But you can use that as leverage for all the aspects of quality you might be missing out as a team and start with the most important ones.
Then you can make a dashboard: it’s about the tests that you do or don’t do. It’s about static analysis of the code. It’s about rushing and never having anyone do a code review. One by one those are quality elements that can be tackled. You add measures for a couple of those in your dashboard. You follow them until their trend is showing positive results. Then you ask yourself, what else do we need in order to maintain our quality above our minimum threshold? Over time you have test coverage, failure rate, release success rate and so many more KPIs in place, as part of the way your team develops.
And then the team notices: well, quality is solved. We know our way around it. We know how to get great software out of the door. Now the next issue is, despite the great quality, we seem to be slow. Our clients are not happy with how long it takes for us to deliver. So that can be your next theme for improvement. It seems it’s about speed at first, but prove again and you’re delving into value delivery. And since we already have a great dashboard and great practices centered around quality, if we speed up so much that we break things, we’ll know immediately.
How is that for timely feedback?
So you see, the agile retrospective is not about the little issues of the day-to-day of a team. Because that is not where performance is.
The key for stellar, effective retrospectives is to find a theme.
Themes for Continuous Improvement for Agile Teams
Now what could be these themes for continuous improvement?
As you can imagine, they range from technical aspects to human aspects. That could mean tackling technical debt, improving communication with adjacent teams, defining and measuring quality, or addressing any other critical performance aspect that’s holding your team back.
To help you out, I’ve come up with a free guide on 10 critical themes that can help you take your retrospectives to the next level and finally start generating improvement results for your team. You go from that stale, generic retrospective to stellar and engaging ones, because you’ll be addressing things that matter.
These are themes that come up time and again, especially in software development teams. In this guide you’ll get to know the 10 themes, understand their importance, and I offer a few questions you can use with your team to get started in exploring the theme in a very meaningful way, so that you can decide on a very valuable, meaningful goal for your retrospective.
I wrote this guide because I myself suffered back in the day on this struggle of making agile retrospectives a powerful process for continuous improvement, and it took me time to zero in on what effective retrospectives really look like.
Retrospectives are more than just “fun meetings”. On the other end of the spectrum, they are also not a boring meeting that teams cross off their checklist. So my goal is that you can restore retrospectives as a meaningful tool for team performance improvement.
Stale to Stellar Agile Retrospectives
Discover the 10 most common themes you can use with your team to drive agile retrospectives that have a meaningful goal towards real and continuous improvement.
Get the why behind the themes and questions to work with your team members.
In Conclusion
Excellent team performance makes the life of each team member easier in the long run, even if in the short term the interactions and questions may be uncomfortable.
The beauty of proactive agile retrospectives based on a theme is that they allow you to move beyond surface-level discussions and dive deeper into the themes that really matter.
By committing to a theme, you’ll create a sense of continuity and focus that’s missing from reactive, more generic retrospectives. You’ll be able to track progress, celebrate small wins, and make meaningful changes that stick.
If you would like to investigate deeper the relationship of agile retrospectives and continuous improvement, I suggest you watch my masterclass here.
