Whole Team
We continually improve our work habits.
Your team should constantly update and improve your development process. Retrospectives are a great way to do so.
The most common retrospective, the heartbeat retrospective, occurs on a regular cadence. (It’s also known as an iteration retrospective.) For teams using iterations, it occurs at the end of every iteration. For teams using continuous flow, it occurs at a preset time every week or two.
In addition to heartbeat retrospectives, you can also conduct longer, more intensive retrospectives at crucial milestones. These milestone retrospectives give you a chance to reflect more deeply on your experiences and condense key lessons to share with the rest of your organization. One example is incident analysis, which I discuss later in this book.
Other types of milestone retrospectives are out of the scope of this book. They work best when conducted by neutral third parties, so consider bringing in an experienced retrospective facilitator. Larger organizations may have such facilitators on staff (start by asking the HR department), or you can bring in an outside consultant. If you’d like to conduct them yourself, [Derby2006] and [Kerth2001] are great resources.
The whole team should participate in each retrospective, along with people who work closely with the team, such as a product manager. No one else should attend. It makes it easier for participants to speak their minds freely.
Anybody on the team can facilitate. In fact, it’s best to switch facilitators frequently. It keeps it interesting. Start with people who have facilitation experience. Once the retrospective is running smoothly, give the rest of the team a chance to facilitate.
The facilitator does not otherwise participate in the retrospective. Their role is to keep the retrospective on track and to ensure everyone’s voice is heard. If team members have trouble staying neutral, teams can trade facilitators, so that each team has a neutral outside facilitator. Be sure that each facilitator agrees to keep everything that happens during the retrospective confidential.
I timebox my retrospectives to 60–90 minutes. Your first several retrospectives will probably need the full 90 minutes. Give it the extra time, but don’t be shy about politely wrapping up and moving to the next step. The whole team will get better with practice, and the next retrospective is only a week or two away.
As [Derby2006] describes, a retrospective consists of five parts: Set the Stage; Gather Data; Generate Insights; Decide What to Do; and Close the Retrospective. In the following sections, I describe a simple, effective approach. Don’t try to match the timings exactly; let events follow their natural pace.
After you’ve acclimated to this format, change it up. The retrospective is a great venue for trying new ideas. See “Alternatives and Experiments” for suggestions.
A word of caution before you begin: Retrospectives can be damaging when used to attack one another. If your team is having trouble treating one another with respect, focus on safety and team dynamics first.
In his essay, “The Effective Post-Fire Critique,” New York City Fire Department Chief Frank Montagna writes:
Firefighters, as all humans, make mistakes. When firefighters make a mistake on the job, however, it can be life-threatening to themselves, to their coworkers, and to the public they serve. Nonetheless, firefighters will continue to make mistakes and on occasion will repeat a mistake.[Montagna1996]
Everyone makes mistakes, even when lives are on the line. The retrospective is an opportunity to learn and improve, and everybody needs to be safe to share their experiences and opinions. The team should never use the retrospective to place blame or attack individuals.
As facilitator, it’s your job to nip destructive behavior in the bud. To help remind people of the need for psychological safety, I start each retrospective by repeating Norm Kerth’s Prime Directive:
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. [Kerth2001] (ch. 1)
Ask each attendee in turn if they agree to the Prime Directive and wait for a verbal “yes.” If they don’t agree, ask if they can set aside their skepticism just for this one meeting. If they still won’t agree, postpone the retrospective. There may be an interpersonal issue that needs to be addressed before people can speak with the openness and honesty the retrospective requires. If you’re not sure what the issue is, ask a mentor for help.
Asking for verbal agreement will feel awkward for some participants, but it serves an important purpose. First, if somebody truly objects, they’re more likely to say so if they have to agree out loud. Second, if somebody speaks up once during a retrospective, they’re more likely to speak again. Verbal agreement encourages participation.
If everyone agrees to the Prime Directive, write the following categories on the whiteboard: Enjoyable, Frustrating, Puzzling, Keep, More, Less.
Ask team members to reflect on the events since the last retrospective and use simultaneous brainstorming (see “Work simultaneously”) to write down their reactions (the things they found enjoyable, frustrating, or puzzling) and preferences (the things they want to keep, do more of, or do less of).
If people have trouble getting started, briefly recap what’s happened since the last retrospective. (”On Wednesday morning, we had our task planning session…”) Pause after each point to give people a chance to write down ideas. Other people can chime in with their recollections as well.
As the ideas wind down, check the time. If you have extra time remaining, let the silence stretch out. Someone will often say something that they have held back, and this may start a new round of ideas. If you’re running out of time, though, you can move on to the next step.
Next, use mute mapping to sort the cards into clusters. When they’re done, use dot voting to choose one cluster to improve. (Mute mapping and dot voting are explained in “Work simultaneously”.) If there isn’t a clear winner, don’t spend a lot of time choosing. Flip a coin or something.
Discard the cards from the other clusters. If someone wants to take a card to work on individually, that’s fine, but not necessary. Remember, you’ll do another retrospective in a week or two. Important issues will recur.
Frustrated your favorite category lost? Wait a few months. If it’s important, it will win eventually.
The first parts of this activity are designed to elicit reactions and gut feel. Now it’s time for analysis. This can be done as a relaxed, freeform conversation. Take notes of key ideas and ask people who are quiet for their thoughts. Be sure to write down what participants think are key ideas, rather than imposing your own interpretation.
To get the conversation started, ask “why” questions. Why is the chosen cluster most important to improve? Why isn’t the current situation good enough? Why are things done the way they are? Allow the conversation to proceed naturally from there. Keep the pace relaxed and focus on exploring ideas rather than driving to solutions.
Now it’s time to come up with options for improvement. Ask the team to think of ideas for improving the selected category. This can involve any idea you can think of: performing some action, changing your process, changing a behavior, or something else entirely. Don’t try to come up with perfect or complete solutions; just come up with experiments that might make things better. It can help to think in terms of circles and soup: what the team controls and what they influence. (See “Circles and Soup”.)
Don’t go into a lot of detail. A general direction is good enough. For example, if “pairing” was the category selected, then “switch pairs more often,” “ping-pong pairing,” and “switch pairs on a schedule” are all valid ideas.
This can be done as a simultaneous brainstorming activity or a freeform conversation. If people need a break from conversation, though, try using a technique called “1-2-4-All.” In this technique, people start by thinking of options silently, by themselves. They write one per sticky note (or index card) and narrow down to their top three. Give them three minutes to do so.
Next, group into pairs. Each pair narrows down their six ideas into their top three. Give them three more minutes, then group the pairs into sets of four, and narrow down their ideas into the top two for the foursome. Give them four minutes, then have each foursome share their results with the whole team.
The group may coalesce around a single good idea. Other times, there might be several competing proposals. If there are, conduct another dot vote to choose one. This is your retrospective objective: the improvement that the whole team will work toward until the next retrospective. Limit yourself to just one, so the team can focus.
Once you have a retrospective objective, ask somebody to volunteer to work out the details and follow through. It won’t be that person’s job to push or own the objective—that’s for the whole team—but they’ll help people remember the objective when needed. Other team members can volunteer to help if they want.
Wrap up the meeting with a consent vote. (See “Seek consent”.) When everybody consents, the retrospective is over. If you can’t reach consent for some reason, choose another idea or start over at the next retrospective.
It’s all too easy to leave the retrospective and think, ”Well, that’s done until next week.” Make sure you actually follow through on the retrospective objective. If nothing changes, the retrospective didn’t work.
To help the team follow through, make the retrospective objective visible. If you decided to do something, add those tasks to your plan. If you’re changing your process, update your planning boards to visualize the change. If you want people to change their behavior, track it with a big visible chart. If you’re changing a working agreement, update your working agreements poster.
Check in on the retrospective objective every day. The stand-up meeting can be a good place to check in and remind team members to follow through.
Despite my best efforts as facilitator, our retrospectives always degenerate into blaming and arguing. What can I do?
Hold off on retrospectives, for now, and focus on team dynamics and establishing psychological safety instead. If that doesn’t work, you may need outside help. Consider bringing in an organizational development (OD) specialist to help. Your HR department may have someone on staff.
We come up with good retrospective objectives, but then nothing happens. What are we doing wrong?
Your ideas may be too big. Remember, you have only one week, maybe two, and you have other work to do, too. Try making plans that are smaller scale—perhaps a few hours of work—and follow up every day.
Another possibility is that you don’t have enough slack in your schedule. When you have a completely full workload, nonessential tasks such as improving your work habits go undone. (The sad irony is that improving your work habits will give you more time.)
Finally, it’s possible that team members don’t feel like they truly have a voice in the retrospective. Take an honest look at the way you conduct the retrospective. Are you leading the team by the nose rather than facilitating? Consider having someone else facilitate the next one.
Some people won’t speak up in the retrospective. How can I encourage them to participate?
It’s possible they’re just shy. It’s not necessary for everyone to participate all the time. Try starting your next retrospective with an icebreaker activity and see if that helps.
On the other hand, they may have something they want to say, but don’t feel safe doing so. In that case, focus on developing psychological safety in the team.
One group of people (such as testers) always gets outvoted in the retrospective. How can we meet their needs, too?
Over time, every major issue will get its fair share of attention. Give the retrospective a few months before deciding that a particular group is disenfranchised. One team I worked with had a few testers that felt their priority was being ignored. A month later, after the team had addressed another issue, the testers’ concern was on the top of everyone’s list.
If time doesn’t help, you can use weighted dot voting. Give people with underrepresented specialties more votes.
Our retrospective always takes too long. How can we go faster?
As a facilitator, it’s okay to be decisive about wrapping things up and moving on. There’s always next time. If the group is taking a long time brainstorming ideas or mute mapping, you might say something like, “Okay, we’re running out of time. Take two minutes to write down your final thoughts (or make final changes) and then we’ll move on.”
That said, I prefer to let a retrospective take its natural course in the beginning, even if that means running long. This allows people to get used to the flow of the retrospective without stressing too much about timelines.
The retrospective isn’t accomplishing much. Can we do it less often?
If your team is fluent in your chosen fluency zones and everything’s running smoothly, it’s possible that there’s not much left to improve. In that case, you could try conducting retrospectives less frequently, although you should continue to have one at least every month.
That’s usually not the case, though. It’s more likely that the retrospective has just gotten stale. Try changing it up. Switch facilitators and try new activities or focuses.
The biggest danger in a retrospective is that it will become a venue for acrimony rather than for constructive problem solving. Make sure you’ve created an environment where people are able to share their true opinions. Don’t conduct retrospectives if you have team members who tend to lash out, attack, or blame others.
When your team conducts retrospectives well:
Your ability to develop and deliver software steadily improves.
The whole team grows closer and more cohesive.
Each specialty within the team gains respect for the issues other specialties face.
Team members are honest and open about successes and failures.
The team is comfortable with change.
Every retrospective format gets stale over time. Change it up! The format in this book is an easy starting point, but as soon as you have it running smoothly, experiment with other ideas. [Derby2006] is a good resource for learning about how retrospectives are constructed and it also has a variety of activities you can try. Once you’ve absorbed its ideas, see https://www.tastycupcakes.org for more.
Some people find that an hour is too constraining to conduct a satisfying retrospective and prefer 90 minutes, or even two hours. Feel free to experiment with longer and shorter lengths. Some activities, in particular, will need more time. As you experiment, conduct a brief “retrospective on the retrospective” to evaluate which retrospective experiments should be repeated and which shouldn’t. Chapter 8 of [Derby2006], “Activities to Close the Retrospective,” has ideas.
In addition to trying new activities, you can also experiment with completely different approaches to process improvement. Arlo Belshee tried a continuous approach, where people put observations in a jar throughout the week, then reviewed those observations at the end of the week. Woody Zuill has an exercise he calls “turn up the good:” at the end of every day, conduct a five-minute retrospective to choose something that went well and decide how to do it even more. Get familiar with normal heartbeat retrospectives first, though, so you can tell if your experiments are an improvement or not.
Project Retrospectives [Kerth2001] is the definitive resource for milestone retrospectives.
Agile Retrospectives: Making Good Teams Great [Derby2006] picks up where Kerth leaves off, discussing techniques for conducting all sorts of Agile retrospectives.
“The Effective Postfire Critique” [Montagna1996] is a fascinating look at how a life-and-death profession approaches retrospectives.