When I hear Agile teams complain their retrospective is not working I often see these three patterns:
- “We run retrospectives when we need to” which is a bit like going to the dentist only after you feel tooth pain
- “Nobody speaks up” where people do not contribute to the conversation
- “Nothing gets done” where no action items are defined or completed
In this article, I’ll share reflections and the next step you can take today to shift those three patterns.
Retrospectives don’t work when run inconsistently
I often hear, “We run retrospectives when we need to,” which is a bit like going to the dentist only after you feel tooth pain. Instead, you want to get your teeth checked at regular intervals to prevent decay. Moreover, teams where retrospectives are only run “when needed” tend to associate the retrospective with a blame session: “Something went wrong so we ran a retrospective,” which leads to a lack of meaningful contributions.
Successful retrospectives are run regularly so the team can practice sharing (positive and negative) feedback and run group reflections that lead to follow-up actions.
If leaders don’t see the value in spending team time reflecting on how to improve, they have a massive blind spot. And it’s only going to create deeper resentment within the team and leadership.
Convince leaders
You may be able to convince leaders of the value of reflection and continuous improvement using one of the following metaphors or something similar:
- Running successful retrospectives is like cleaning your house
If you always procrastinate cleaning your house, chores (and dirt) will accumulate and cleaning will become a daunting task. Instead, if you clean up regularly, the task becomes more manageable. - Running successful retrospectives is like a family vacation
How would you decide what to do on your next family vacation? If you never stop and reflect on how the past vacations went, you’re bound to only recall certain (biased) events. What happened during our last family vacation? Let’s break it up one salient event at a time. What was good about that vacation? What could have been better? What could make the next family vacation the best one yet? Now change “family vacation” with “iteration” and tada!
Make sure you have buy-in from the team and leaders to regularly dedicate time for an iteration retrospective.
Often I see teams where the retrospective is run at a regular cadence, but the value is hard to explain because the team doesn’t contribute or there are no actionable next steps. Let’s look into those two patterns next.
Retrospectives don’t work when the team doesn’t make meaningful contributions
Most of the teams I join run retrospectives at regular intervals but the team doesn’t always make meaningful contributions. This pattern emerges in a few flavors:
- Complete lack of contributions
- A feel-good fest
- A few loud participants overtake the stage
How to tackle the lack of contributions
Some folks misunderstand a “lack of contributions” with “everything is just fine.” This is a big mistake.
There is a chance folks do not contribute because they are afraid of negative repercussions from managers or powerful team members. On a new team, I start by anonymously assessing that. You can ask how folks feel about the retrospective. Here are a few retrospective “types” to help you identify issues.
- Explorers: want to learn as much as they can and leave no stone unturned
- Shoppers: want to participate and leave with one action item in their cart
- Vacationers: not interested in the retrospective, happier to be here than working at their desk
- Prisoners: they’ve been forced to participate and don’t find the retrospective to be useful
(This is an example of an ESVP in Miro. I learned the activity in Diane Larsen’s and Esther Derby’s book “Agile Retrospectives.”)
Ignoring that a retrospective has a majority of prisoners and vacationers will lead to poor results. Acknowledge the lack of engagement/psychological safety and try to ask: “How can we make sure this retrospective is gonna be useful for you and the team?”Allow anonymous suggestions. You might have to postpone the retrospective to find the best way to address the suggestions. Maybe you’re on to something big. Perhaps there is powerplay and there is a retrospective participant that shouldn’t be there.
And remind the group you will collect feedback at the end of the retro to ensure improvement in running the next retrospective.
How to tackle a feel-good fest
Sometimes I see teams that run retrospectives at regular intervals, but all they talk about is what they did on the weekend or how everything is awesome.
There is value for the team to bond and talk about weekends and hobbies. But that’s not the focus of an iteration retrospective.
When I observe this pattern, I acknowledge the positive intent in sharing our personal weekends, and I remind the group of the purpose of the retrospective: “for the team to reflect on how to work more effectively together and adjust accordingly” (this is from Principle 12 of the Agile Manifesto).
When all events or topics are on the positive side, you can end up in a rut where you might wonder if you still even need a retrospective. You can tackle this in at least two ways:
- Ask how the team got to these good events or patterns. What could be done to radiate these even more?
- Use creative destruction and prompts like the following:
- “Imagine the next iteration is the worst one yet, what’s happening?”
- From there ask, “Is anything similar we’re doing today?” and “What can we do to improve that?”
This is an activity known as TRIZ. Another one is “future backwards” by Cognitive Edge The Future Backwards – The Cynefin Co, and Cynthia Kurtz’s Working with Stories, where you create a dystopian future timeline that traces back to the current timeline.
Change up formats and prompts to avoid habitual thinking.
How to tackle a few loud participants that overtake the stage
Start by having empathy for those individuals and thank them for their contributions. Then ask for other contributions with prompts like the following:
- “I’d love to hear from folks that haven’t contributed yet”
- “We’ve heard the backend developers’ perspectives, are there any front-end developers’ opinions?” Or “We’ve heard from developers, does the PM and designer have an opinion on this?”
You can go as far as calling people’s names out, but keep in mind that putting people on the spot like that might backfire.
A few more strategies follow:
- You can also change the communication medium from open conversations to using video chat (or a physical sticky note) to give people more time to think solo before contributing.
- For meatier topics, another strategy you can use is to get people to talk about that topic in pairs (in a breakout room) and bring back a summary of their conversation and ideas.
Retrospectives don’t work when there is a lack of commitment to action items
The purpose of a retrospective is “for the team to reflect on how to work more effectively together and adjust accordingly.” The most common way to “adjust” is through creating action items (some call them experiments).
If the team never adjusts after a retrospective, there is something wrong. What can you do about it?
When topics are presented in the first part of a retrospective, you should have the group define clusters and prioritize what the most important topics for the team to tackle are, so they can work more effectively in the next iteration.
Asking to vote on the most important it’s just too vague for an iteration retro typically scheduled for one hour.
Once there is a priority, you (or someone else) will need to set a timebox for discussion. Depending on context and time constraints at the end of the timebox, I tend to offer an extension of the timebox and ask what the next step to address this could be.
If somebody suggests something, I try to capture it as a SMART action and ask how it is Specific, Measurable, Achievable, Relevant, and Timebound.
This helps define an action item that is more likely to be completed. Often I like to put a name or two on the sponsors, so individuals will be responsible for tracking its progress. I often ensure the team has a way to track progress (e.g. with a chatbot reminder).
If your retrospectives are not working, your teams and organization aren’t learning. You want your team to continuously learn and take action on the patterns that can make you work more effectively. Failing to do that will leave the team with a lack of agency
Three patterns make your retrospective work
These top three patterns outlined above make your retrospective work. To recap, here they are again:
- Run retrospectives at a regular cadence
- Make sure all folks are contributing
- Have meaningful action items defined and completed
Continue to iterate and gather feedback to adjust your retrospective and make your teams even more effective.
A retrospective template
Would you like a Miro template to support your iteration retrospective? I have created one (completed with a 5 minutes explanation video) on the Miroverse here.
