“A retrospective is therapy,” Cognizant Softvision Engineering Lead Greg Rice told me. “And therapy isn’t easy.”
Sprint retrospectives may not involve any personal breakthroughs, but they are a chance to work through the problems that inevitably arise as groups of individuals attempt to work as a unit.
No sprint leader wants a room full of stone-faced, resentful participants. Nobody wants a group that spirals into emotion-fueled mudslinging, either. A happy medium requires some serious skill on the part of engineering and product leaders, to ensure retrospectives yield real, actionable outcomes.
“If a team is frustrated about something, I think it’s good to get that out on the table, instead of letting it stew and not tackling it head on,” Ruth Liew, senior director of engineering at Meltwater, said. “It’s all about how it’s presented.”
Setting a structured game plan for retrospectives helps keep conversations on track — the focus should be on improving processes, not evaluating individuals, Liew said. Structured retros also signal to teams that you value their time — retros should not feel like an unnecessary 60-minute interruption on the calendar.
Action-oriented retros are a gift to teams, said UiPath CPO Param Kahlon. A retro is successful when participants walk away with concrete ways to more efficiently handle customer pain points and deliver new products.
“If, at the end of the day, people feel good about what they’re delivering to their customers, that’s team therapy in itself,” he said.
We spoke with Rice, Liew and Kahlon about what strategies they’ve found make sprint retros more actionable.
How to Make Sprint Retrospectives More Actionable
- Win buy-in by articulating and documenting the meeting’s value. Often, teams view retros as low priority.
- Set some ground rules. Make sure participants understand what their focus should be — and who can speak up.
- Sum up what happened in the last retro. Launching in without a summary makes prior retros seem pointless.
- Leave space for individual reflection. Moving to group discussion too early can erase diversity of opinions.
- If participants seem uncomfortable, break the ice. Offering criticism can be intimidating. Leaders should take the first steps.
- Resist the urge to fix things. Leaders may see a solution, but they should let teams figure things out themselves.
- Walk out with action items, but don’t assign ownership when it’s not appropriate. Usually the group owns action items collectively. Other times, it makes sense to assign ownership to team leads.
- Switch up formats to see what works. Retros should be ongoing experiments.
Win Buy-In by Articulating and Documenting the Meeting’s Value
Rice: For a lot of teams, retrospectives are on the agenda, but they’re really far down. And recently, it’s just been difficult to get teams to do them, for a variety of reasons. But agile-scrum is one of those things where, in my experience, if you don’t follow each part, it makes the whole less great.
Meetings are not easy, and speaking up in meetings is especially not easy. So, I think what a lot of people remember about retros is the effort of them, and there’s this sort of cognitive dissonance between what a meeting provides and what you have to go through. It’s like, “I don’t really like talking about stuff that didn’t go well,” or, “I don’t really like being presented with that experience,” which is yet another reason to have retros. Whatever your sprint cycle is, retros allow you the chance to address things that otherwise don’t get any sunlight. Ninety percent of problems could be solved by something resembling a retro.
But when people are very positive toward retrospectives, I think, like me, they’ve been on the receiving end of the positivity that comes from a well-led retrospective that’s treated with the regard it should have.
Kahlon: When you come into an organization and say, “We’re going to do a retro,” if a team or individual isn’t used to doing those, the first reaction is: “Great. This is going to be a place where we start the blame game. What are we going to get out of this?”
A great thing to do is to invite that person — who is maybe influential but doesn’t agree about the value of the retro — to be a fly on the wall for another team that does a retro. Say, “Hey, why don’t you come and witness how this team runs retros, which I think is a great example, and see if there are any learnings you can take.”
That worked very well in one situation in my previous life, where we had a team that was very diligent and very deliberate about retros, and other teams weren’t as interested. We invited one of those leaders to come to the sessions and listen to how it was going. And they felt like it was valuable, and they could use it as well.
Set Some Ground Rules
Kahlon: We start every meeting with some ground rules. If you’ve ever seen the debrief process Navy pilots use, basically the first thing you do is pull the rank off: “There are no ranks in this meeting. Everybody has equal voice and equal say, and we want to make sure that everybody has ideas.” If an engineer has an idea or a tester has an idea or a developer has an idea, they’re all equal.
Another is: “This is not about coming here and complaining about what others should have done. This is about constructive criticism, about seeing how we can execute better and make more impact as a team.” If you have personal feedback about somebody, there’s a different place to do that. Here, we are going to focus on how we function and organize as a team.
Not to say it always happens that way. But we set up those ground rules because we want people to perceive this as constructive.
Sum Up What Happened in the Last Retro
Rice: The worst thing is not summing up what you did the last time. You need to buzz through even crib notes from the last time and what steps have been taken to mitigate the problems.
If you don’t do that, that effort of people bringing things to the table is lost. Because there’s something important about somebody choosing to open their mouth about something, beyond just talking about features. And if you don’t revisit that, you’re not really honoring that process.
“People go, ‘Well, what’s the point of me even talking if nothing changes?’”
Summing up what the last retro accomplished — sort of tipping the cap to everything everyone just did — that opens the door to starting it again. And if you don’t do that, it can really affect things poorly, because people go, “Well, what’s the point of me even talking if nothing changes?”
Leave Space for Individual Reflection
Liew: Typically, we ensure that the retros encourage what we call divergence of thinking and convergence of thinking. What we want is to give everyone the ability to think about it on their own and share their opinions, rather than go down a path that encourages groupthink too quickly.
So, within a retro, we always incorporate some form of divergence, followed by convergence. For example, a very common format for retros is: What worked? What didn’t? What can we do differently? We’ll encourage divergence in the first two areas — what we did well and what didn’t work well — to get a lot of ideas on the table. [Liew’s team members write down their ideas on Post-it notes.]
Through that, you see common themes. Maybe three people said the same thing, or someone said something the others didn’t think about. Then, convergence can happen. We do dot voting, like, “Vote on the two that you feel the most strongly about.”
From there, we go into, “OK, what can we do differently?” And then we encourage divergence again. So we brainstorm and put down all the ideas we can think of. Then we talk about it and converge again on actionable steps and how we want to promote change.
In a group of individuals, you have many different personalities — people who talk a lot and people who are quieter. This technique helps get all ideas out on the table. Providing that space helps a ton.
Mature teams — teams that are really comfortable with each other and have been working together for a long time — tend to step away from the technique and use free discussion more, because everyone understands how everyone else contributes. But I think the misstep that happens is moving toward that free-flowing discussion before the team is ready.
If Participants Seem Uncomfortable, Break the Ice
Rice: If it’s all just delightful criticism, like, “I wish we dressed up more!” or stuff that doesn’t necessarily fold into the [processes up for discussion], there could be a big systemic problem. The culture or environment doesn’t feel right to bring difficult things up.
Yes, you could be working in a perfect environment — “We’re too good! The muffins in the break room are too nice!” — but you still need to have those minor criticisms. It might be, “I wish we had more time to spend doing a demo,” or, “Wouldn’t it be nice if....”
It could be helpful to start out with some self-criticism, as a team leader, where you offer something negative just to help people lean into it a little bit.
Resist the Urge to Fix Things
Liew: A technique we use a lot is asking open-ended questions to dig into the root of a problem. As a leader facilitating a retro, it takes a lot of practice to ask strategic questions and not start telling the team what to do.
“When, as leaders, we just tell people how to fix it, we don’t promote critical thinking, and that’s what we want to encourage.”
When, as leaders, we just tell people how to fix it, we don’t promote critical thinking, and that’s what we want to encourage. So, ideally, when you get to the end of the retro, the team feels bought into the outcomes. That’s why we use techniques like open-ended questions and individual silent thinking. For a retro to be truly successful, the team has to feel like it owns the outcomes and is empowered to act on them.
Walk Out With Action Items, but Don’t Assign Ownership When It’s Not Appropriate
Kahlon: We haven’t assigned one person to be responsible for [the action items generated in retrospectives]. I think it depends on what type of action is required. For example, we could decide that we need more clarity on the requirements, and that would definitely fall into the product-manager area of responsibility. We could also decide on something that’s very engineering-management centric. For example, we could say that the way we track dependencies with some other team is not very good. In that case, the action item would fall very specifically on one or two people who are working with that team and tracking those dependencies or following the overall engineering management.
We basically write the item up and say, “OK, this is going to be an action item that Param is responsible for because he’s doing the specification,” or, “The engineering lead is responsible for this because it falls into the domain they can manage and drive.”
Switch Up Formats to See What Works
Liew: Getting good at retros takes so much experimentation. Be comfortable knowing that you will have failures. You’ll probably have retros where you’re like, “Oh, this is going nowhere.” And that’s OK.
A couple of things can help [with disengaged teams during retros]. First, try out different formats. Sometimes, we notice a specific frustration the team has and focus the retro on that. You could even have a retro that’s more fun-oriented. We try to mix up the formats of the retros, because otherwise it’s going to feel a bit boring after a while, right?
Within our agile coaching team, every time we create a new template [for retros], we put it in a shared folder and try to make it easy for people who aren’t full-time coaches to just go into the bank and figure out which ones they want to try.
