An essential part of agile is continuous improvement. No matter how good an agile team is today, its team members feel compelled to seek ways to become even better in the future. This search for continual improvements is the purpose of the iteration retrospective.
Unfortunately, not all retrospectives are perfect. Teams often struggle to get their retrospectives just right. In this article, I’ll describe the four most common problems I’ve seen with retrospectives, and I’ll offer advice on overcoming each problem.
Problem #1: People Aren’t Honest or Trustworthy
One of the most common complaints about retrospectives is that people fail to bring up real issues or admit to their problems. If people aren’t going, to be honest in a retrospective, the argument goes, they’re a waste of time.
That’s actually probably true. But the solution is not to abandon retrospectives. Rather we need to focus on getting people to be more honest and open during them.
There are definitely some steps you can take to increase honesty and trust among your team members. These include doing the following:
Create a Safe Environment
Create a safe environment. People won’t speak up in retrospectives unless they feel safe in doing so. That means getting everyone to agree that what happens or is said in a retrospective, stays in the retrospective.
Attend enough retrospectives and you’ll see tempers flare occasionally and you’ll hear things that shouldn’t be repeated. In a recent retrospective, a programmer vented about how long it was taking the “damn DevOps group” to deploy.
He shouldn’t have said it that way. But, on the other hand, it was nice he could vent and get that out of his system knowing that it wouldn’t be repeated verbatim to the DevOps group.
I don’t think swearing has any place in a retrospective. I’ve certainly heard it, though. Keeping it out is part of creating a safe environment. So is making sure people know their comments won’t be repeated, and they won’t be judged for stating them.
Model the Behavior You Want
If you want others to speak truthfully, you certainly need to do so. I think this is especially true if you are a Scrum Master or coach trying to get a team to open up more in retrospectives.
If team members see you being hesitant to speak the truth, they’ll be hesitant as well.
Make Sure all Criticism Is Constructive
I don’t think anyone likes to be criticized. Even if we know it’s for our own good, we don’t really like it. I have an editor who reads my blogs and fixes them all up before you see them. I don’t like it when I open up a document she’s edited and see everything she tells me I did wrong. But I like the impact her editing has on the quality of these articles.
One thing I love about her edits is that she almost always gives me a suggestion along with the criticism.
A criticism without a suggestion is often just complaining. Encourage team members to provide constructive criticism when criticism is called for.
Follow Through on Commitments
To generate trust, follow through on all commitments you make. Do this for commitments made during a retrospective or any other time. Additionally, ensure that others do the same. Retrospectives can quickly feel worthless if people commitment to changes they don’t deliver on.
Admit When You’ve Made a Mistake
I was wrong. I made a mistake.
So many of us have a hard time saying either of those sentences, yet it is often so important for others to hear them.
If you’ve made a mistake, admit it. Perhaps you recommended changing the team’s sprint length. And two sprints later, it’s clear that was a bad idea. Admit it. Then let go of the decision and move forward.
I mentioned earlier the importance of modeling the behavior you desire. Admitting when you’re wrong or have made a mistake is an important way of doing that.
Problem #2: Retrospectives Are Boring
I love listening to music. I enjoy most genres and enjoy both live and recorded music. But there’s something special about live music.
When I was 19, I dated a girl, Daiva, whose mom owned a ticket brokerage. In those pre-internet days, she’d buy tickets to concerts and other live performances, and then resell them, hoping to make money on the price difference.
Occasionally she’d be stuck with a couple of unsold tickets the night of a performance. The best thing about dating Daiva was that her mom would sometimes give her these unsold tickets. She and I would then go to the concert. The only thing better than live music is seeing it on a free ticket.
Once Daiva’s mom gave us free tickets to see the heavy metal band Judas Priest. We were both fans. In fact, we’d already purchased tickets to see them perform the night before. This meant we’d see Judas Priest two nights in a row.
The first show was great. We were standing most of the concert, horns up, and singing along with Rob Halford.
The show the next night was...the same. I don’t just mean the band played the same songs. They played them exactly the same way down to the smallest detail.
During one song, singer Rob Halford walked to the right side of the stage, put his foot on an amp, leaned forward, made a fist and then rested his elbow on his knee and put his chin on the fist. He executed this exact move and pose both nights.
The entire concert was choreographed down to the smallest detail. And this made the second night boring.
The same thing will happen to your retrospectives if they’re conducted the same way each and every time.
It’s fine to have a few standard ways you like to run retrospectives, just like it’s fine for a rock singer to have a few go-to moves that are repeated each concert. But you can’t do the retrospective the exact same way every time and expect people to remain engaged.
There are two general ways to vary your retrospectives: either change the questions you ask or change how you ask the questions. Let’s look at each.
Changing the Questions
Changing the questions you ask team members during the retrospective is a great way to freshen up stale retrospectives. If you’ve been asking, “What went well and what didn’t?” change that perhaps to, “What should we start doing, stop doing and continuing doing?” or any number of other variations.
Even better, change the context in which you ask questions. The website TastyCupcakes is well known for offering unique games and activities for retrospectives. For example, that site describes Retrospective Sailing, which puts common improvement questions into the context of sailing a ship. Participants are asked to identify sails, that helped the team move toward some goal, and anchors, which slowed the team on its journey.
At its core, this is just another way of asking what a team is doing well and not. But asking those questions in a different context (sailing, in this case) can sometimes help.
As an even easier way to change up your retrospectives, Adam Weisbart offers Recess. Each month, Weisbart mails you a physical box containing everything you need to run a fun, engaging retrospective. He’s had boxes that ask a team to imagine itself on a mission to Mars or fighting off 
zombies.
I know it sounds crazy, but it really works! I’ve seen people actually start looking forward to these meetings, and more importantly, they follow through on the action plans they create with Recess.
I love being able to outsource retrospective creativity to Weisbart and let him come up with a new idea for me every month. I then get a box from him with everything I need, even a playbook — it saves tons of prep time, everyone has fun, and it gets results.
If you’re interested in checking it out, I’ve arranged 75% off your first kit for you. Just use this special link and the discount will be applied at checkout: https://RecessKit.com/mountaingoat
Change How Questions Are Asked
Less dramatic than changing the entire structure or context of a retrospective is simply changing how you ask questions. Suppose your retrospectives usually entail a Scrum Master asking everyone, “What should we do differently next sprint?”
Mix that up--instead of asking that question of everyone at once, call on individuals and have each person name one thing.
I do a lot of retrospectives in a simple Start, Stop, Continue format. There are many ways to mix that up. I might start by asking everyone to just yell out anything to start, stop, or continue. Next retrospective, I might ask the same but ask each person one at a time to answer. Next time, I might tell a team we’ve come up with a lot of things to start recently but very few things to stop. And so I’ll either ask each person to give me one thing to stop.
Mixing up the questions, their context, and how you ask can definitely help prevent retrospectives from becoming as boring as a rock band that choreographs every move of a concert.
Problem #3: Retrospectives Aren’t Effective
There are enough agile teams around the world who will attest that retrospectives are effective for them. So if you feel your retrospectives are not effective, you have to look at how you’re running them.
Retrospectives, when done well, are an effective way of identifying and choosing new ways to improve.
I really don’t think there’s a lot of room to argue against that. An argument can be made, however, that retrospectives are not cost-effective for a given team. That is, the improvements that result from the retrospective aren’t big enough to justify the time spent.
This is quite possible. Although of all the teams I’ve met who have told me they’re perfect and no longer need retrospectives, I’ve never agreed. All teams can improve.
The World’s Best Team
But let’s consider the case of the World’s Best Team. They have the trophies and magazine cover stories to prove it. This team conducts a retrospective, but because they are so staggeringly phenomenal, the retrospective takes an entire day. And in it, team members identify an improvement that will make them 0.0001% more productive.
That retrospective was still effective--an improvement was found. But it wasn’t cost-effective. And it was a huge exaggeration. All teams should be able to identify a more significant improvement than that with less effort.
A Realistic Example
More realistically, though, suppose a team of eight spends an hour in a retrospective. That’s an investment of 480 minutes. Whatever improvement they identify needs to be able to pay back 480 minutes of savings for that retrospective to have been worth the effort.
This sounds like a lot of time but many improvements can easily pay that back. The investment is paid back, for example, if the team identifies an improvement that will prevent miscommunications that cost a person day or two at each occurrence.
As teams get really good it can be worth paying attention to likely payback on identified improvements.
Improving Payback on Retrospectives
One easy way to improve a team’s payback on retrospectives is to consider doing them less frequently, especially if the team is doing iterations that are one or two weeks long.
I know I’m going to get some hate mail over that but hear me out.
Suppose your team hates retrospectives. I mean they hate them. You’ve noticed team members are scheduling root canals on retrospective day just to get out of the meeting. And I mean unneeded root canals just to get out of the retrospective.
And this team realizes that by merely changing from two-week to four-week iterations they can eliminate half their retrospectives. And so the team opts to move to four-week iterations just so they can do fewer retrospectives.
Far fetched perhaps, but it does illustrate that a team doing a retrospective every four weeks is fine if their iterations occur every four weeks. Why shouldn’t a team doing, let’s say, two-week iterations be allowed to do a retrospective every other iteration since that’s still one every four weeks?
I think they should be allowed to do that.
I don’t encourage it. And most teams who want to do retrospectives less often are the teams that most need retrospectives. But, for a highly proficient team with significant agile experience, I think this is a valid way of keeping retrospectives both effective and cost effective.
Problem #4: Retrospectives Don’t Work for Distributed Teams
Let’s face it: Just about everything is harder with a distributed team. The fact that something is hard should not be used as a justification to stop doing it.
Yes, retrospectives are more challenging to do well with a distributed team. But that’s likely all the more reason to do them.
There are a few things you can do that help.
First, I think video is a must for a distributed retrospective. Don’t try to do a retrospective just with a conference call.
Second, any sort of collaborative editing tool can be used for the meeting. Encourage all participants to type new ideas into the tool. That should not be the sole responsibility of the Scrum Master or other facilitator.
Third, keep your retrospectives short and frequent. Do this despite what I said in the previous section about maybe doing retrospectives once a month rather than every two weeks once a team is great.
Long meetings are never fun, but they’re particularly painful when not in person. Even worse, if the team is spread across very distant time zones, it’s quite likely that part of the team is staying late to participate. Team members in that city are unlikely to bring up big issues that will just keep them in the office even later. So, short retrospectives are better.
Fourth, do anything you can to keep retrospectives fun, especially when meeting remotely. Common practices such as having each person share something they appreciate about someone else on the team can help here. If someone always brings food to the retrospective in your office, find a way to get snacks delivered during the retrospective to people in other cities.
Fifth, during a distributed retrospective it may be worth the extra effort to ask team members to assign responsibility among themselves for the various changes that have been agreed upon.
I don’t normally do this with a collocated team, reasoning that they’ll discuss it and figure it out collaboratively throughout the iteration.
But things seem to fall through the cracks more often with distributed teams, so a little time spent discussion which team members will take responsibility for working on each change is worth it.
You may not be able to do this, but I have to suggest this as a final tip: Fly people together occasionally. I wouldn’t necessarily fly everyone together just for a retrospective. But because retrospectives are the last thing in an iteration, you can fly people together for a review, retrospective and planning meeting. It’s definitely worth doing occasionally.
What Do You Think?
Have you encountered the same four problems I’ve described? How have you dealt with them? What other problems have you faced with retrospectives and what did you do to overcome them? Please share your thoughts in the comments section below.
