A Case For The Vital, But Often Avoided, Sprint Retrospective Meeting

I want to talk to you about sprint retrospectives, but first I have to tell you a story about self-assessment.

When I was in 5th grade, I started taking saxophone lessons (laugh all you want, we all know it’s the coolest instrument). I had this great teacher, an old jazz musician who had retired from his days playing in clubs to teach music. He taught me life skills: Persistence, dealing with disappointment, paying attention to details. But the best lesson he taught me was the value of self-assessment.

One day, he asked me to buy a tape recorder (those were still a thing back then) and bring it to my next lesson. The next week, he recorded me as I played a song we’d been working on for weeks. As soon as I finished, he said, “Alright, let’s give it a listen.”

I was confused—I just played it, I know where I messed up. What’s the point of listening to what I just played?

But here was the problem: what I thought I played was nowhere near what I actually played.

The recording revealed all sorts of mistakes. Sour notes, changing tempos, false starts. It was horrifying.

The tape recorder quickly became my least favorite possession, but its value was clear to me even back then: Sometimes what you know for sure to be true—just isn’t so.

And that vital perspective you gain from self-assessment is why you need sprint retrospective meetings if you want your scrum team to stay in tune and succeed.

What Is A Sprint Retrospective?

A sprint retrospective is basically this: At the end of every sprint, the team should gather to discuss the process. What worked? What didn’t? How can we remove roadblocks in the next sprint? Before gathering everyone in a room and airing out your grievances, it’s important to understand the roles and goals of a sprint retrospective.

One of the key tenets of Agile development is the idea of continuous improvement in team productivity. Every sprint should be a bit more efficient than the last. The only way to do this is to understand where the weaknesses in your process lie and implement strategies to overcome them.

Hence, the importance of a retrospective meeting.

Michael Silvi is a lead consultant at Stride, a software development consulting firm in New York City. He’s been helping teams implement Agile and scrum teams for seven years, and emphasizes a formalized structure (which we’ll get into below) for retrospective success. Below he shares his expertise on the structure, roles, and goals of an effective sprint retrospective.

Why Are Retrospectives Overlooked?

Back when I was a student learning to play the saxophone, I hated the tape recorder because it forced me to listen to all the ugly mistakes I was making. Sprint retrospectives will do the same thing, and it takes maturity and confidence to confront your mistakes.

“You need to be in a high trust environment,” says Silvi. “You’re airing out dirty laundry, so without a high level of trust, many teams avoid retrospectives.”

There’s also the pressures of the business cycle. Silvi says that teams are under lots of pressure to deliver on time, and thus are of the belief that taking any time to pause and reflect will slow down the process. Or perhaps the team has tried retrospective meetings in the past, but lacked an efficient process to fully harness their potential, and decided it wasn’t worth the time.

But this short-term thinking leads to long-term problems.

“If you’re not taking time to talk about problems, there could be some systemic issue that you’re ignoring and not getting at the root cause,” says Silvi.

Without discussing problems with a team’s work process, you’re bound to keep repeating the same mistakes. The simple act of examining your work, identifying problems, and agreeing on a solution can have profound effects.

Silvi describes working with a team that waited six months to implement regular retrospective meetings. They continually ran into the same problems every sprint: “We didn’t have enough of a partnership with the product team. I would work on a story and have no context for why I was doing it; I was just told to do some work,” he says. “Without product knowledge, I built the wrong thing, did more work than needed, and had to delete that work to get it right.”

Besides just being a waste of time, repetitive problem areas are a killer for team morale. By holding retrospective meetings, the team was able to build that product team relationship, add context to their work, and avoid these situations.

Hosting An Efficient Sprint Retrospective

There are a number of methods for hosting a sprint retrospective, but there are a few key roles and rules you’ll need to be successful no matter what.

Roles and Attendees

Facilitator: The facilitator keeps the meeting on track—redirecting off topic conversations, asking guiding questions, and keeping an eye on the clock. They should be an impartial party to the meeting, driving it but not participating.

While your instinct might be to assign this role to a manager, Silvi recommends against this, as it can make people hesitant to point out mistakes. “Ideally you have someone outside the team who’s impartial. If you can’t have that, I like having someone junior or mid-level, since it gives them a chance to develop leadership, but without the baggage of hierarchical power.”

Attendees: The retrospective shouldn’t be an “open to all” type of meeting; only those who really need to be there should be involved. Silvi also cautions against having senior leaders in the room, as people can feel uncomfortable discussing mistakes in front of them.

Other rules for success:

• No phones, no laptops. Everyone should be focused on the discussion.
• No notetaking, beyond deciding on action items as a team for the next sprint.
• And (this is a big one) no assigning blame.

Silvi likes to start retrospectives by reciting “The Prime Directive,” a sort of credo created by software consultant and author Norm Kerth:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

Silvi goes around the room and has each team member audibly confirm their agreement to this statement. “You don’t want people pointing fingers. You want everyone buying into the fact that we’re all trying to get better.” Ensuring that everyone in the meeting is assuming positive intent means that everyone is approaching the discussion from a positive place.

Deciding on a Topic

A common pitfall (besides assigning blame) in retrospective meetings is attempting to do too much. Inevitably, there will be a long list of processes that your team will want to improve, but attempting to fix them all in one sprint isn’t realistic. Your team needs to decide as a group a single issue and how to fix it.

Silvi’s preferred method for accomplishing this goal is a process called “mute mapping,” which he limits to 30 minutes to keep the meeting moving. Each team member gets a stack of sticky notes to write down observations about the sprint, along with a happy, sad, or confused face on each. “A happy face might be for something like, ‘I like how we collaborated on this task,’” says Silvi. “Sad might be something that didn’t go so well, ‘We didn’t agree on the implementation.’ Confused might be ‘I don’t know why this thing isn’t working.’”

Next, the team works together to cluster the notes into categories. If there were three sticky notes all dealing with team communication, those would get grouped together. Next, Silvi has every team member vote on which category to address in their next sprint. He facilitates this by giving everyone three stickers, which they use to “vote” on the category they most want to see fixed.

“It’s important that the team votes on a category they can actually do something about,” Silvi warns. “I once had a team that all voted on something they had no control over, and we wasted time talking about how to fix something we couldn’t fix.”

Discussion

Once you’ve tallied the votes, you’re ready to discuss a problem. The facilitator plays a big role in this portion of the meeting, as group discussions have a tendency to go off topic. Silvi uses “five whys”—listening to a problem statement then asking “why” five times—to get to the root of a problem.

“We’re wasting time building things that weren’t needed.”

“Why?”

“Because we didn’t know they weren’t needed.”

“Why?”

“Because we didn’t communicate with the product team before starting the work.”

“Why”

And so on.

After this exercise, Silvi uses a technique called the “coaching funnel” to move from problem discussion to actionable steps:

1. Start with the problem: “We’re wasting time building things that weren’t needed.”
2. Talk about the goal: “No features built that must later be deleted this sprint.”
3. Discuss options to fix the problem: “We could require more detail in feature requests.”
4. Discuss the best options
5. Finish with action items: “Update the feature request form to include more detail.”

Once these action items have been agreed to, they can be recorded and implemented in the next sprint, helping the team run smoother and quicker.

Small Steps To Big Improvement

There’s no denying it: Retrospective meetings can be intimidating, especially if you’re new to the process. That tape recorder from my childhood music lessons never became my favorite part of learning an instrument, but it did help me get better, quicker. And that part is fun and rewarding.

Remember, you’re not trying to solve all your problems at once. The beauty of scrum is incremental improvement. By continuously fixing small items, your team will be happier, more productive, and spend less time dealing with recurring headaches.

Silvi leaves us with this bit of advice: “If each sprint you talk about just one problem and fix it, you’ll be amazed at how good your team can become.”

Good or bad, we'd love to hear your thoughts. Find us on Twitter (@trello) or write in to support@trello.com

Next: How To Get Started With Scrum and Trello For Your Team At Work