Are your agile retrospectives feeling stale and unproductive? If so, it’s possible that YOU as the scrum master or team coach are making one of the 3 the mistakes I’ll discuss in this post.
If your are a reader, keep on reading. Otherwise, here’s the video. Don’t forget to check the resource in the end of this post!
We can complain all we want about scrum, but it’s thanks to it that TODAY, one of the most famous practices for team performance is the agile retrospective.
Yet if you’ve coached an agile team for a long enough period of a time, I bet you’ve had your team feel or even tell you that retrospectives are not that useful or that they are not interested in it. Maybe, like me, you heard a bunch of developers come to you and say “yeah, we wanna work with you, just don’t do that ‘kumbaya’ thing”.
While it’s easy to just blame the developers thinking “they just don’t understand the retrospectives spirit”, I invite you to put yourself in their shoes. If they’ re pressed for time, and time is money, that meeting called a retrospective better have the best ROI possible for people to want to attend it. And the simple truth is that there ARE ingredients that make it or break it for retrospectives.
And if you want to figure out which of the 3 issues is most likely impacting your retro, at the end of this post I have a resource waiting for you.
The origins of agile retrospectives
Before we dive into the 3 mistakes, let’s just get a quick step back to level-set on retrospectives.
While most people know retrospective thanks to frameworks like Scrum and SAFe, they don’t own or did not invent the retrospective. In fact, people doing eXtreme Programming ( which started in the late 1990’s) were already dong retrospectives at the end of their iterations and at the end of releases.
Then came the agile manifesto and you could make a case that agile retrospectives as we know today originated from the insight in it, when they’ve posited the agile principle #12:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
But even then, the idea behind the retrospective is not new. It was inspired by the notion of continuous improvement that you can find in much older schools of thought for management and product delivery as in Lean and Systems Thinking. I could mention Theory of Constraints, Kaizen, PDCA, Six SIgma, to name a few.
But putting it simply, despite having many different “flavors”, continuous improvement is an incremental cycle of improvement to products, services, and processes. It means you were at a certain stage of performance, and you want to get to the next, whatever that might look like.
And retrospectives are simple the most famous agile practice that represents that in the agile space.
So, picture a meeting where people join in to talk about what needs to be improved. As you can imagine, or know by experience, a lot of things can go wrong! Listing all of them would bring them to almost a hundred items! So keep this organized and make things easier for you, I’ve put them into categories. And those 3 categories of mistakes you are making with agile retrospectives are the bulk of what make them ineffective and unappealing to your teams.
The 3 mistakes that break agile retrospectives
The 3 categories are
- Lacking a meaningful Improvement goal.
- Not following a set meeting structure.
- Not using facilitation skills.
Let’s look at each of them and their impact.
Mistake #1: Lacking a meaningful goal
Let’s look at the first one.
Meandering conversations? lack of actionable insights? Or worse: actions for every single retrospective, yet the team doesn’t feel like they’re moving forward with improvement?
First, any conversation, unless it’s with friends or at a bar, should start with the end in mind. The end game for retrospectives is the improvement for the team. A meaningful, concrete change in the way teams do things.
When you don’t’ have a goal or you just sift through the little annoyances that happened in your sprint, chances are you are talking about anything and everything. The build that was broken, someone who didn’t show up for 2 days, a new requirement. Too many things, too little time. And not everything holds the same importance.
You’ll end up lacking truly actionable items for your retrospective. Without clear and achievable action items, your team might struggle to make progress and see tangible results. It feels like fighting fires or venting. And it feels like improvement is a target that changes every single day.
Mistake #2: Not following a meeting structure
The second problem is that you are not structuring your retrospectives. While you don’t want retrospectives to feel constrained, there is something to be said about the need for a structure to run a retrospective as a proper meeting, so that it’s not simply a broad conversation that may or may not generate insights.
I want to make a note, though, that very mature and autonomous teams can have retrospectives the look like simple conversations, yet they are very on-point and useful. But this is a skill the team itself will build, so don’t start from there. Simplicity is the art of shedding the unnecessary. You can’t start fully “shedded”.
Most people make this mistake, thinking this is the fun, team building meeting. And with that wrong assumption, they fail to design the retrospective.
A great agile retrospective has a structure, that code has already been cracked for you. Retrospectives have a beginning, a middle and an end, and in an upcoming post I’ll do a deeper dive on it.
Let’s put it this way, the structure in a retrospective is helpful for the team and for YOU as the facilitator as well. With structure, people come to expect what happens and why it happens. You get to promote a sense of organization, productivity and allow for clear communication among the team members. And you give yourself solid points to intervene when things go off track, like people dominating a discussion, or avoiding ramblings.
Mistake #3: Not facilitating the agile retrospective
And that leads me to the third mistake you are making which is not acting as a facilitator. Maybe you are shying away, you are not very comfortable with your facilitation skills. Maybe because the retrospective lacked a goal, plus you didn’t structure the retrospective, so now you have to pull too much weight in keeping the retrospective on track.
Whatever the reason, without proper human intervention, so much dysfunction can take place. You might have people playing the blame game, instead of collaborating on problem solving. You might have a lack of what we call a safe space, which is where people get to be as honest as possible in their contribution so that we can pursue the very best alternative. Without a safe space, valuable insights and improvements might go unnoticed.
Tips to make your agile retrospective powerful
Whether you are new to retrospectives or not, these mistakes are quite common, so let go of that shame. I’ve made every single and most scrum masters and coaches and managers do them. Powerful and effective agile retrospectives are not easy to design and run!
So now the question is how do you fix those mistakes?
I wanna be very clear that there is no easy fix. But I’m going to give you some tips to start figuring out in your particular case what that could be happening and the guide in the end of this post should help with that. For now, we’ll scratch the surface of solutions and in future posts I’ll give you more material to continue to investigate and fix these mistakes.
1. Set a meaningful goal for your agile retrospective
You probably saw this coming. If you haven’t’ already, you’ll make sure you’ll never run agile retrospectives that don’t have a goal. Before the retrospective or very early on, you set a goal with the team. A meaningful goal that they want to pursue. If you can’t find a goal, you need to seriously ask yourself and the team, why that is.
Effective agile retrospectives are a tool for improvement and improvement is achieved towards a goal. A meaningful, tangible, measurable goal. A goal that’s agreed upon and helping the team to filter through the noise of everything else that could also be better but that is not as important now and in the near future.
2. Use the 5 phases of a retrospective to structure it
The second thing is that way before people enter that room virtually or physically, your retrospective must be anchored on a structure, a sequence of events that help people go from ground rules to broad thinking, to analytical, to decision-making and commitment. In a way a retrospective is almost like a planning moment, with options, with prioritization, with saying NO…. A planning meeting! Just that what you’re planning for, is the improvement.
Word to the wise: I know I used the word meeting a lot, but the most interesting way you can think about retrospectives is to consider it a process. And that will make your life easier in case you need to run them online and even asynchronously.
3. Brush up on facilitation skills (and use them)
Lastly, you can’t just be a scarecrow static in a corner or a cheerleader during an agile retrospective. You are responsible for helping people understand and follow the flow of the retrospective, you have a strong influence on making people participate more, or less, in the case of those people that take all the space they can get.
Your facilitation means you know different ways to make people engage in direct and respectful conversations, navigate disagreements and conflict that naturally arises (and that is not inherently bad). A facilitator has an active part to play in agile retrospectives. Neutral in opinion, but active in guidance.
Successful retrospectives will make people WANT to exchange their views and KNOW that they’re not penalized for disagreeing or offering sometimes unpopular opinions. That’s the magic you bring as a facilitator.
Conclusion
I mentioned the 3 most common categories mistakes you are making with your agile retrospective and that’s why your team might be getting less than ideal result with it. These are so common that I bet if you ask any other scrum master or agile coach they will tell you they’ve been there. You are not alone and the good news is…
These are all fixable!
However, trying to solve all 3 categories of problem at once is probably not the smartest strategy. Pick one to improve. Do the homework, just like your teams would do: which one seems the most ripe for improvement? To help you with that investigation, I have a quick questionnaire and guide to help you figure out where to go next.
Agile Retrospectives Quick Audit
Investigate your agile retrospectives and discover which of these 3 pesky mistakes keep hindering its effectiveness and stalling your team performance.
