Well Run Retrospectives for Scrum and Agile Teams

Posted in Agile, Scrum, and Leadership - 0

I often see Scrum teams struggle with the retrospective. Retrospectives are not easy. They take time, they take commitment, and they take courage. When the pressure’s on, they’re often the first thing to go. In the rush to deliver a product, having a meeting to vent your frustration can seem like a waste of time. And if that’s all your retrospectives have become, I agree. You are wasting your time.

That doesn’t mean, however, that you should axe retrospectives. On the contrary, if your Scrum and agile retrospectives have become meaningless, it’s even more important that you do them, and do them right. Why are retrospectives so important, you ask? And what are some key components of an effective retrospective in a Scrum / agile project? Let’s answer both of those questions.

Give Retrospectives Their Due Diligence

Retrospectives are a key part of a Scrum team’s inspect-and-adapt cycle. Every other part of the sprint (sprint planning, daily standups, the sprint review, product backlog grooming) focuses on delivering working software. The retrospective is the sole opportunity for team members to examine how they work and how they are working together. It’s a time for them to learn how to improve, how to work more efficiently, and how to deliver at a higher velocity and with superior quality. Retrospectives are a constant reminder of the need to continuously improve, to always be moving forward. Because when a team stands still, it falls behind.

Retrospectives in Scrum have a more subtle benefit as well. They give teams the opportunity to change behavior and team culture. They are a safe place for team members to share, constructively, feedback with others on how their actions (or inactions) impact the quality, morale, and attitude of the team. Left alone, these small problems fester, like an unattended cut. Retrospectives, on the other hand, allow teams to attend to their small wounds quickly, reducing the chance of infection.

Plan an Effective Retrospective

So, we can agree that retrospectives are valuable. But how do you run them effectively, so that they don’t degenerate into an unproductive complain-and-moan session?

Choose a Facilitator

In Scrum, the ScrumMaster will typically facilitate  the meeting, and in XP, it's the coach. That being said, however, any Scrum team member can act as facilitator. You might also occasionally want to bring in an outside facilitator, especially with new teams or those experiencing dysfunction. to ensure the retrospective is focused and effective, the facilitator should plan ahead in regard to meeting format, room setup, and supplies.

Physical Setup

New teams often struggle with staying on schedule during the meetings. As such, I often remove the chairs from the room. I want to prevent people from sitting so that they focus on moving through the parts of the meeting without endless discussion. I have been in too many retrospectives where everyone is leaning back in a chair, debating with no real outcome. I have found that removing the sitting aspect of the meeting helps keep people on track. If you want to keep your seat and have a more subtle reminder of time marching on, you could also display a timer that counts down each time block, perhaps flashing yellow or red as each section of your meeting approaches its close.

Ground Rules

Many meetings are derailed simply because there are no ground rules. Basic ground rules that should be posted in the room and verbally shared at the beginning of each meeting include the following:

  • Be respectful.
  • Do not interrupt.
  • Put away laptops and phones.
  • Park long discussions in the designated lot.
  • Recap what you hear to ensure understanding.
  • What is said here stays here.

Run the Retrospective

The ScrumMaster and all team members should attend each retrospective. I do not recommend inviting the product owner regularly, because I have seen too many times where the product owner hijacks the retrospective to tell the team members where they went wrong, took a bad approach, didn’t listen correctly—you name it. Occasionally, it might make sense to include the product owner, but for most retrospectives, the attendees should be limited to the team and ScrumMaster. In the end, do what works best for your team.

Collect Data

Because the room has already been set up, the meeting can begin as soon as everyone arrives. However you choose to run the meeting, the first 15 minutes or so should be dedicated to data collection. This could be everyone writing on whiteboards, open-space style sticky notes (with people calling out their issues), or a scribe being responsible for writing down ideas on whiteboards. 

Prioritize Data

Once the ideas have been collected, they need to be prioritized. You can use virtual currency. It can be anything. I have seen people use ping-pong balls, play money, even just plain “units.” The important thing is to make sure that everyone has the same amount and everyone has the right amount. People spend their currency on the items they want to discuss that were gathered in data collection.

Make a Plan & Choose a Driver

Now that things are prioritized, the team needs time to discuss the high priority issues and make decisions. Timebox this part of the meeting based on the amount of time you have left and the number of items you need to discuss. Bring an egg timer if people have a hard time getting to the point. Once everyone understands the issue, ask, “Is this something we are going to mitigate/fix or not?” If no, discuss why not. Then, move on to the next one. When I facilitate retrospectives and I encounter an issue that the team decides not to fix, I write it down in my notes to capture on the team wiki. That way, when the team comes back and says, “Why didn’t we ever fix this?” I can tell them exactly why we decided not to do it. I find it just helps with dealing with noise later on.

End the Retrospective

Once you have a list of actionable items, or the time has expired, it’s time to close down the retrospective. I like to end it with a one-to-five quick rating of “how was this sprint?” and “what do you think next sprint will be?” One is bad; five is good. People can answer any way they want, but I try to weed out any ill will in the team that may require some discussion. I care about the answer, sure, but I’m more interested in how people answer. What I look for is nonverbal clues that may indicate that what people are saying does not match what they are feeling. I don’t call it out in the meeting; instead I approach the person one-on-one, tell him what I observed, and just ask if there is anything wrong. If the person says that everything is fine again, I’ll let it go and just observe the team over the sprint.

Don’t settle for once-a-sprint vent sessions. Do the work, make the plans, and follow-up on issues from every retrospective. Read more about how the retrospective in Scrum plays a role in the first year in my book The Scrum Field Guide: Practical Advice for Your First Year.