Retrospective: Silence Is Golden, Until It Costs You

It was the end of the iteration. The team wrapped up their committed stories. After the review session, everyone agreed on the stories that met the "Definition of Done" (DoD) and closed them, tallying the total story points the team managed to complete in the iteration. Next stop: the retrospective session — a face-to-face session with everyone in the team, including the Product Owner and the team manager. In a nutshell, the idea is to walk through the events of the iteration: acknowledging the challenges and mistakes made, while at the same time recognising the team's achievements. The key takeaway is to improve the way of working (WoW) and practices, so there is growth and learning as a team.

Tired-looking team members, with weary eyes, gathered in the meeting room, some with coffee in their hands. A lot of the folks had been burning the midnight oil — the last push to finish the stories committed in iteration planning. The routine was to go round the table, so everyone had the chance to voice out the "good" and the "bad" that took place in the iteration. Typically, the "usual suspects" will be the outspoken ones, voicing their opinions. The rest, however, choose to be silent, often citing that they shared the same points brought up by the "usual suspects". Oh, how convenient! The team quickly went through all the "good" and "bad", creating action points to stop the "bad" from repeating and to ensure the "good" continues. Once again, a good retrospective, iteration closed, and the next one begins. All is good in the team — let's move on. Or is it?

Let's be honest here: a sugar-coated retrospective is not solving or improving anything. Remember, the fever is only a symptom; what caused the fever is the root cause. The fever will keep recurring if the root cause is not treated. A handful of team members who voice out while the rest remain silent is a tell-tale sign. The big question is: why?

Retrospective is just another Scrum ceremony

When the team treats the retrospective as just another box to tick, no one places any importance on it. They just get it done, tick the box, and move on. The moment this happens, learning and innovation become optional. The Scrum team slides into a vicious cycle where the only objective is to complete stories (by hook or by crook) every iteration. Never mind the fact that even a slight improvement could have saved the team from grinding day in and day out.

Nothing will change

The team might have started enthusiastically in the beginning. They actively voiced out improvement ideas and learning experiences. They might even have come up with 101 ideas on how to have better team workflows, tooling, and so on. However, no matter how good an idea is, if the execution falls short, there will be no positive result. Sometimes the improvement might involve the leadership team (process changes, budget approval), which can oftentimes fall on deaf ears. When the team does not see changes or improvements after a few retrospectives, they will stop trying.

Session dominated by a few

Key people in the team (translation: Product Owner, Scrum Master, senior team member) typically have a lot of opinions when it comes to team topics. They are also respected individuals in the team, so not many will challenge them openly. The moment a few people dominate the retrospective (or any other discussion, for that matter), communication becomes a one-way street. The rest choose to follow the herd, staying amicable for the sake of avoiding hostility.

Fear of retaliation

Ever encountered a situation where a person in the team voices out a strong opinion on a particular topic? The team acknowledges the issue at hand, but when it comes to action points for improvement, guess who is nominated to take the lead — and hence responsibility and ownership? Chances are, it will be the same person who brought it up in the first place. Whether the team realises it or not, this is a form of retaliation. If this practice is commonplace in retrospectives, it is a sure way of making sure most team members keep mum on issues and improvements.

If your Scrum team ticks even one of the above, it is time to act. A note of advice: if we leave the team alone, thinking it will figure out on its own how to improve the situation, think again. A mature Scrum team might be able to pull it off, learning from mistakes and adjusting to improve. However, there is also the collective blind spot. When a group of people is very used to how things are run, it becomes a habit — and habits die hard. It is better to nip it in the bud before it turns into the norm. The next question to ask is: how?

Retrospective: a core event, not a sideshow

The retrospective is a core event — a crucial foundation of Scrum's inspect-and-adapt cycle, very much ingrained in Agile. Scrum members must recognise its importance. The same message must be emphasised at all levels, from top leadership all the way to the ground. The only way for the team to grow is to continuously learn from mistakes and find ways to improve, so the same mistakes are not repeated. This is the very intention of having the retrospective, and why it is so important.

Agile call to arms: experienced Scrum Master or agile coach

This is a call for an experienced Scrum Master or a good agile leader/coach to step in. We need someone who can moderate the retrospective in an efficient and effective manner — someone with the depth and breadth when it comes to agile topics. Someone who can calm down the tough, and sometimes aggressive, "usual suspects", and at the same time encourage the "silent ones" to speak up. Essentially, someone who can read the room well and act accordingly to drive the team to a fruitful retrospective (read: check the symptoms, identify and treat the root cause).

Create a safe environment

The essence of the retrospective is to create a round table where team members are free to voice out without fear of retaliation. In this session, everyone should be treated as equal — be it the Product Owner, Scrum Master or senior person. The discussion should focus only on the topics, based on facts and evidence. Hierarchy and ranks must be left at the door. When the team perceives that they are in a safe environment, only then will they open up and share their opinions and thoughts without hesitation. While it is good to have experienced voices, it is even better to get different perspectives from everyone in the team.

Prioritised improvement: one step at a time

One common mistake the team tends to fall into is being overly enthusiastic in creating too many action points for improvement. While it is important to identify improvement plans, executing too many of them at the same time does more harm than good. The Scrum team is lean and small; focus must not be spread too thin. A well-run Scrum team will prioritise the action points that make the biggest impact, as per the Pareto Principle (i.e. 80% of results come from 20% of inputs). The team will only trust the retrospective when they see results — it is a simple ask. Aim for the small wins and the low-hanging fruit initially; the team will gain more confidence in tackling much more complex problems.

Management and leadership team support

In many Scrum setups, the team manager is treated as an "outsider" of the team. This is no surprise — if you were to go through any Scrum lessons or workshops, you would see the definition of the Scrum Team consisting of only three accountabilities: Product Owner, Scrum Master, and Developers. It is true that the Scrum Team is self-managing when it comes to the backlog and daily operations; the team manager does not participate directly. However, a team manager who is also a competent agile leader with lean thinking is a big advantage for the team. The manager will understand how to build a team with an agile culture in mind, be it team objectives, philosophy, or the training required. A supportive management team goes a long way in creating the very safety net the team needs to realise its full potential.

The leadership team plays a crucial role as well. At times, retrospective items might be beyond team-level scope. Improvement in the delivery workflow, for instance, will require the involvement of other Scrum teams in the business unit. Changing the release cadence (let's assume it is for a really good reason), which impacts customers, will require approval all the way from top leadership. Good support and engagement from the leadership team is the best testament that the retrospective is alive and kicking.

Transparency and honesty — building trust

Let's face it: the retrospective is not the silver bullet for all the team's problems. We should not treat it as a wish list that will be granted by a genie. Some problems might not have a straightforward answer, and solving them might take a long time. There are also retrospective items that nothing can be done about, and the team will need to accept that. Here is where transparency and honesty are of the utmost importance. If something cannot be done, or will take a long time to solve, there must be a good explanation of why that is so. Team members are an intelligent bunch; they can tell if the reason given is genuine or just a made-up tale. Transparency and honesty are a sure way of building trust in the team.

The retrospective is a crucial building block and is pivotal to team growth. If you manage to harness it properly and unlock its value, the gains the team will get are exponential. However, if you see it as just a Scrum ceremony, then you have failed to understand what Scrum is all about — and the beauty of how it should work.