In my experience, the retrospective is the most underutilized and straightforward ceremony in Scrum. I’ve sat in numerous retrospectives, where issues were raised, no actions were discussed, and no attempts to address the issues were made. I’ve also sat in ones, where no issues were raised, but everyone knew what the issues were. It was like being part of a Cargo Cult and as a result, the issues often persisted throughout the projects.

Another version of this is one, where the retrospective is simply dropped. Arguments often used are: “We tried and it didn’t work”, “Nobody ever raised any issues”, “We argued all the time” and last but not least: “It’s a waste of time”. To me, all of these arguments represent a failure of logic. If we examine each of these arguments, we find they represent a fundamental misunderstanding: “The ceremony is the problem”. It’s not. The retrospective is about openness, constructive communication and, most of all, the desire to improve the process.

Understand the ceremony

The retrospective is where we take stock of what happened during the last sprint, what could be improved, and what we like. In some of the retros I’ve been in, it became a laundry list of complaints, and I’ve certainly brought my own lists at times. This often leads to counter-productive meetings, where no action is taken, which is why teams decide to drop it, because “it’s a waste of time”.

A good retrospective starts with everyone answering simple questions. An example could be: “What should we start, continue and stop doing?”. A more positive one could be “I Like, I Wish, What If”. I’ve come to appreciate the latter for its positivity, and focus away from simply stating complaints, to providing suggestions for improvement. This is, truly, in the spirit of the 12th Tenant of Agile. This is what retrospectives are all about, and keeping the discussion constructive is the key to a good meeting.

Establish ground rules

Establish ground rules, and review them at the beginning of each retrospective. It sets the right mood for the meeting and also reminds everyone of the process. I like the approach of starting with reiterating why the retrospective is important, then describing the format and any rules and lastly going over the process. I have provided an example below, but feel free to put your spin on it. It shouldn’t be lengthy or complicated.

Welcome everyone. We have these retrospectives, because we want to continue to improve our process and in order to improve it, we need feedback and open communication. We will provide feedback in the form of completing the sentences: “I like”, “I Wish” and “What if”. All feedback should be provided in this format. We do this, because we want the focus to be on improving, rather than on what has gone wrong. You will have 10 minutes to fill out as many sentences as you want, and we will then discuss all the tickets during the remainder of the meeting. Please fill out the sentences quietly, and take the time to reflect, if you need it.

In the above example, quiet is requested. I prefer this, because it allows me to reflect, and even if people seem to finish before the 10 minutes are up, you should still let the timer run out. People might, in the quiet, suddenly remember something they want on the board. Sitting in silence for a few minutes feels weird the first few times, because it doesn’t feel productive. But doing things slowly and methodically isn’t a waste of time, it’s a signal to your team that rushing is not something we do in the retrospective. Here, we take the time to think, reflect and listen.

Take feedback, not attendance

Feedback is how we improve, and the retrospective is the crucible, through which all sprints must pass. Participating in this process, for a team, can be daunting. Giving critical feedback to your manager, client or team is not something everyone is comfortable with. If someone doesn’t participate during a retrospective, it’s important to be aware of this person. If it continues over multiple retrospectives, take the time to ask them - outside the retrospective, maybe over lunch - how they feel about the process. They may not feel comfortable in the group, with the format or even the setting. This is feedback too, and they may feel more comfortable sharing their comments with just you, rather than the whole group. But even so, you should ask and consider what can be done to make this person feel comfortable participating with the group.

Group dynamics can be difficult. As someone, who can easily take up a lot of speaking time during any meeting, I mostly wait until everyone else has had a say, before weighing in. Especially during retrospectives. In roles such as Lead developer, or Systems architect, I am aware my words often carry more weight. If you have one of these roles, consider voicing concerns you see others hold back, or perhaps lending the weight of your words to others. The responsibility for having a good retrospective is on the whole team, and everyone should be interested in improving the process.

Actions speak louder …

Take action after each retrospective. From the sentences produced during the retrospective, you should be able to establish what can be done to improve, and you should act on it. What kills a lot of retrospectives is when action is not taken on issues raised, or when there is no follow-up on agreed-upon actions. It’s vitally important these actions happen. And at the following retrospectives, the action items from previous retrospectives should be brought up for a quick status. Communicating what has been done to either fully or partially take the actions agreed upon during a retrospective, reinforces the team’s willingness to participate in the ceremony and process, because they see it making a difference.

Sometimes, a thorny issue is raised. An example from my own experience was when a client’s employee would always be late for meetings. Sometimes they wouldn’t even show up or asked to re-schedule 10 minutes into the meeting, without actually showing up for it. The attitude that “the customer is always right” is almost omnipresent with agencies, and dealing with a problematic client can be confrontational. It’s helpful, in these situations, to bring it up during the retrospectives, a setting focused on the improvement of the whole team, including the PO. If the approach is: “How can we improve on this” rather than: “Can you just show up for meetings on time”, most people are more receptive. It also signals - to the team - that everyone is part of the team, and they shouldn’t hold back, just because the issue is with a manager or client.

But what if the problem is not inside the team, but rather something the team depends on, like deliveries from other teams? Cross-team or ‘Overall retrospective’ is designed to handle just such events and allow teams to deal with cross-team, organizational or systemic problems within the organization. The idea comes from LeSS (Large-Scale Scrums), and I recommend looking more into it, if your organization runs multiple Scrum teams. I have included a small diagram below, to give you an idea of how the overall retrospective works.

Overall retrospective by LeSS.works

Guard against the Cargo Cult

When using the retrospective, it’s easy to fall into the trap of simply listing grievances or problems. To me, this is not what it’s for. The retrospective should always be focused on improving future performance, by evaluating past performance. Let’s be clear though, performance is many things. It’s human to be results-oriented and in a competitive world - where everything quickly becomes a discussion about budgets and time constraints - taking the time to stop and reflect can seem less important than simply moving on to the next task. However, the retrospective is a window into what the team is thinking and feeling and, in my experience, the welfare of the team is correlated with the results the team produces.

Establishing a culture and cycle of feedback can be a benefit to everyone involved, but only if actions are taken based on that feedback. If a team member makes a constructive suggestion on how to change something for the better, try it out and see if it is better. If not, you can simply go back to the previous method in the following sprints, and now everyone understands that this is better. It’s an explorative process of adaptation and adjustment to run Scrum. It’s an agile process.