Are your retrospectives failing? (part 2)

In Part 1 I looked at some background to what we are trying to achieve from retrospectives and the idea of self-transcendence. I covered our first reason for retrospectives not working - if just aren't happening, what can we as leaders do to help?

In Part 2 I will introduce four more reasons why retrospectives may not be working and what we as Agile leaders can do about it.

2. Lack of Psychological Safety

Central to any effective retrospective is a blame free environment. If we are to look openly at what has happened, we need to do so through a lens of learning not blaming. I have worked at several organisations where improvement was limited by people's desire to "look good". In some cases this has been lack of confidence by individuals, perhaps "imposter syndrome". Sometimes this has been fear preventing people from speaking openly. In some cases people have learned that deflecting blame and taking credit for others' successes is the way to advance.

As an Agile leader, your role is to build a culture where people can speak freely and share ideas openly without fear of repercussions. This will need you to embody these ideas in your own behaviour and to reward them in others. Any retrospective should start from the principle identified by Norm Kerth, often referred to as the "Prime Directive".

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. “Project Retrospectives” – Norm Kerth

There is a challenge specific to being an Agile leader here. You want to ensure your teams do the best they can with retrospectives. But including leaders in team retrospectives will imbalance the discussion. People may not want to discuss openly. They may wait for guidance rather than giving their own ideas.

Once your team have learned what they need to do, you will need to leave them to self-manage. A retrospective should involve all of the team but no-one in authority. That does include any skills represented in the cross-functional team, including Product Owners, who are part of the team, not managers of the team.

Read: The Prime Directive - https://agileplays.co.uk/the-prime-directive-for-retrospectives/

Read: Psychological Safety - https://agileplays.co.uk/what-do-we-mean-by-psychological-safety/

3. Accepting the situation

Another frequent problem that is observed in team retrospectives is that they continually return to the same issues. The retrospective becomes a repetition of things that make the team unhappy. The same items are raised every retrospective.

If a retrospective is a mechanism for change, then raising the same issues each time must show that something is broken. There is no change occurring.

Typically this shows the team have accepted the current situation. However painful, they do not believe they can change it, or that it will ever change. This mindset will not lead to effective retrospectives. A retrospective must start from the idea that the team can make change. Otherwise, why hold the meeting?

Kaizen is about changing the way things are. If you assume that things are all right the way they are, you can't do kaizen. So change something! - Taiichi Ohno

The team will likely need coaching to support their empowerment. They may also need help to develop actionable steps to make change. Once they see their decisions are having an effect, they will adopt the process and start proposing and progressing more change.

Read: Teams and cohesion - https://agileplays.co.uk/why-does-team-size-affect-cohesion/

4. Symptoms not problems

There is some skill involved in making retrospectives actionable. When discussing what went wrong (or right) most people's first reaction is to focus on symptoms. What did we observe occurring? Unfortunately it can be difficult to frame actions based just on these symptoms.

For example, the team completed less than expected in a Sprint. This isn't desirable - it would be great to align expectations and results. However, what action are we to take? "Complete more in the Sprint" is scarcely actionable. If it were that easy, we would have done it.

In any retrospective, it is important to push towards root causes. Why is the symptom occurring? Lean emphasises the importance of asking "Why". The Toyota "5 Whys" technique was designed to repeatedly ask "Why" to push down to more underlying causes. The idea of the name is that you may typically need to ask "Why" five times to really understand the root cause. If you haven't used this approach before, try it - it's slightly uncomfortable to start with but very effective.

A relentless barrage of 'why’s' is the best way to prepare your mind to pierce the clouded veil of thinking caused by the status quo. Use it often. Shigeo Shingo

Why did our team complete less than expected? Perhaps there were a lot of support issues. Maybe these were because of poor feature design in a recent release. Perhaps that was because of poor designer/developer interaction. And perhaps that was due to investing too little time in initial feature design discussion. Now we have something actionable.

Read: Lean principles - https://agileplays.co.uk/seven-lean-principles-to-promote-flow/

5. Unwilling to experiment

A good retrospective will identify problem areas. But identifying the problem is not enough. A retrospective has little or no value without action. Retrospectives follow the Shewhart cycle popularised by Deming which forms the core of all improvement activity - Plan, Do, Study, Act.

The team need to be informed by the problems they have identified and plan specific actions. The actions are then executed and the results of the actions examined. Has the action had an effect on the problem?

Teams often get paralysed by trying to find "the solution" to a problem. Before they start they want a guarantee that the action they take is "the right one". However, this certainty is rarely available. More normally, the team need to see each action as an experiment. The team believe the action will head in the right direction. They execute the action and look for a positive outcome.

Teams are often very uncomfortable with the level of uncertainty involved in experimentation. They may also be inexperienced in the basic approach. As an Agile Leader you will often need to coach and support teams in taking this approach.

Read: Rapid feedback - https://agileplays.co.uk/decision-making-in-agile-development/

Read: Waste in Lean - https://agileplays.co.uk/what-is-waste-muda-in-lean/

Good Practices

As we have seen, there are many places where Agile retrospectives can be ineffective. What can you, as an Agile leader, do to support your teams to ensure they make the most of this powerful tool?

It is tempting to get involved in retrospectives directly, attending and steering them. This may have some value initially when you are getting the process to run. However, retrospectives are about team autonomy and achieving self-transcendence. They are not a process which you can run directly without distorting them.

Your role as an Agile leader is twofold. You may need to teach the basics of good practices in order to allow the teams to perform effective retrospectives. This is likely to only last a short time. And then you need to coach the teams to ensure their retrospectives are effective, supporting them in empowerment. Your key role is to ensure a culture of psychological safety which allows them to thrive and develop.

Balancing autonomy and direction is always a challenge in Agile leadership. If you're concerned about progress, ask the team to talk about the problems they have identified, the experiements they have performed and what they have learned. Use this as a coaching and discussion opportunity.

I help scaling tech organisations with systems and structures to achieve repeatable delivery.

If you want to discuss how I can help your organisation, drop me a message or let's meet up for a coffee.