Making Agile Retrospectives Productive

They say that those who ignore history are doomed to repeat it. That applies just as well when your history comes in two-week sprints as it does when you measure the time between cultural revolutions. If you don’t pay attention to what has worked and what hasn’t and don’t decide what action to take in order to improve, you will quickly find yourself facing the same problems over and over.

One of the greatest advantages of an agile workflow is that it makes time for intentional reflection to encourage constant improvement. The retrospective ritual, traditionally held at the end of a sprint, gives the team a chance to discuss everything that stood out in the previous sprint. This includes looking at what went well and what didn’t, and making course corrections.

But carving out time from a busy production schedule for a retrospective meeting that doesn’t produce features for the product can be a tough sell in a fast-paced and competitive industry. Here are a few possible objections that are worth listening out for, and ways to address them.

“Retrospectives are a waste of time”

One of the issues that people new to agile often worry about is the time spent following the rituals of the process. It’s not that difficult to get folks on board with a planning meeting, and even a short daily stand-up (just be sure that your stand-ups aren’t slowing you down). But when you come to something as touchy-feely sounding as a sprint retrospective, there may be a tendency to try to cut corners for the sake of efficiency.

Structured planning can help address this concern. Plan out in advance how the team can make sure all issues are raised and acknowledged. Be considerate and make sure that the retrospective meeting stays within its defined limit. Track progress constantly as you go through the steps you’ve planned out for your meeting, and let people know as you are going just how far along you are.

Be sure to reserve an adequate amount of time for the ritual, and get everyone to block that time out in his or her calendar so you have total participation. A good time for the retrospective meeting can be right after the sprint demo, when everyone on the team is already thinking about what they accomplished during the sprint. By following a pre-planned structure that involves everyone, produces a clear result, and provides a record of what happened, you can help make it clearer how productive the retrospectives are.

“We don’t want another gripe session”

Nobody enjoys sitting in a room and listening to people complain. When the retrospective starts to feel like a gripe session instead of an open discussion of issues, that can mean that the process isn’t doing a good enough job of raising the visibility of positive accomplishments and feelings.

An unstructured discussion in a team that’s having problems may not have anywhere to go but down in a great spiral of accusations and complaints. The scrum master running the meeting needs to make sure that there is time reserved for people to recall and share the positives. Sometimes not everyone will have anything positive to say, but everyone should be given the opportunity, because the team learns as much from what works well as they do from what they believe might need to be changed.

Make sure that the positives as well as the negatives are given fair attention in the action items and the retrospective notes that are captured and shared with the team afterward. By putting time into the process specifically to draw out positive feedback, it’s possible to shift the mood of a retrospective from combative to constructive, without stifling discussion of any serious issues.

“Nothing really changes”

One of the most common issues that comes up when teams are new to the retrospective process is failing to learn from the issues raised at a retrospective. When the issues being raised seem to be the same from ones meeting to the next, that could be a sign that there isn’t enough learning and iterating happening.

Taking the time at the beginning of the meeting to look at the action items from the last meeting can be a good way to avoid this problem. Once the team has been reminded that an issue was already raised, the discussion can turn away from rehashing it, and focus on why there wasn’t any change in behavior. Start your meeting with a recap of what actions the team decided to take at the previous retrospective, and after the meeting be sure to send out notes to remind everyone what they just discussed and decided.

Never end a retrospective meeting without a list of behaviors that the team has agreed to try out, and make sure that list is the first thing you pull out at the beginning of the next retrospective. If it helps, use a template like the Retrospective Blueprint provided in Atlassian’s Confluence package to maintain a consistent format and keep the notes visible and accessible. If the team is comfortable with the idea, you can even post the list up in the area where the stand-ups are done, so everyone can note any deviations as soon as they start to happen. Sooner or later, people will start to realize that these are real commitments that they are making to each other.

“We just do what we’re told”

In some retrospectives, the team may feel intimidated if managers and senior people participate too actively, or try to make their opinions outweigh the voice of the team. While there is often a good reason for management to dictate policy for the group, the impact of those policies on the team’s ability to operate and make progress in an agile manner should be part of an open and balanced discussion at a retrospective meeting. The greatest value can come from the process if the team is provided with a safe space, and people feel comfortable raising their concerns.

Sometimes it may be necessary to create a process that allows individuals to submit their negative and positive comments anonymously. If that’s the case, the scrum master should pay attention to the conversation dynamics in the meeting, and see if there are personal or hierarchical issues getting in the way of the team discussion.

Management often sets the tone for a team, and a manager who is not comfortable hearing criticism can inhibit the retrospective process to the point that it stops adding value. It’s important for the manager of a team following an agile process to buy in to the value of hearing what people have to say, and to remain open to trying new approaches to old problems in an iterative manner. Agile works best when it runs in harmony with a supportive management structure that recognizes the benefits that can come from defending a safe and transparent work environment for everyone on the team.

“We’ve learned everything already”

After a team has been working together for several sprints, they may be tempted to stop doing retrospectives, or some members of the team may attend them less frequently. In some ways, it can be seen as a good sign when the suggestion comes up that retrospectives are feeling irrelevant because there’s nothing to complain about. But following the rituals is critical to keeping problems from seeping through the cracks.

The suggestion to stop doing retrospectives can be an indication that the retrospective meeting itself is getting boring, and is in need of a shake-up. There are some great resources online, such as the Retrospective WIKI, that may give you ideas for new ways to structure the retrospective to make it more engaging and productive. Changing how retrospectives are run, and making them fun, is worth the extra effort.

Letting a team dismiss the retrospective as part of the agile process stops the learning, and allows what was once agile to become simple policy. Without the self-awareness that a team gets from actively discussing what is and is not going well in every sprint, problems and resentments can build silently, undermining the transparency of agile.

“Oh yeah, right, we forgot about that.”

After the retrospective is done, the product of the ritual should be a clear set of action items for the team to try out over the course of the next sprint. These should flow naturally from the topics raised, and the discussion they inspired. By the end of the meeting, the scrum master should have the full list of proposed action items compiled, and have presented them all to the team for general consent.

During the sprint, it’s important to remind people of the action items whenever situations come up that are relevant. Some teams choose to post a list of action items up on the wall next to the place where they hold their daily standup, so they can be seen regularly. As a team gets more comfortable, people may start to use gentle social pressure to advocate for others to adhere to the action items that matter most to them, creating a natural peer pressure toward improvement.

Wrapping Up

Making time for the retrospective is critical to the iterative improvement of an agile process. It’s not enough to follow the day-to-day rituals if you never give the team a chance to reflect on what went well, what didn’t go as well, and how they can improve that. It’s also important to get everyone to participate actively in the retrospective process. The perspectives of those who sit quietly on the sidelines and observe can sometime shed a clearer light on an issue than those of the vocal minority.

Running an effective retrospective should be an enjoyable experience. Look for ways to make it something people look forward to. Remind people during the sprint to keep the action items from the last retrospective in mind, and to keep track of issues — both positive and negative — that they want to go over at the next retrospective.