Are your retrospectives failing? (part 1)

Most software organisations are probably performing retrospectives. Most Agile approaches (from Scrum to XP to SAFe) highlight retrospectives as a key activity.

"The Sprint Retrospective concludes the Sprint." - the Scrum Guide

And yet in my experience many teams struggle with effective retrospectives. If retrospectives are so important (and who would deny the importance of self-improvement?), why are they often not successful?

In this article I want to step back a little from the much-discussed topic of how the team run a single retrospective event. I will focus more on what outcomes are important and how, as an agile leader, you should approach contributing to effective retrospectives.

Part 2 is at https://www.dhirubhai.net/pulse/your-retrospectives-failing-part-2-jay-alphey-xl5we

Continuous improvement

If we are to improve retrospectives, we first need to consider why we bother with them. Retrospectives are a key part of continuous improvement. Some organisations try and design a perfect process from the start and then fix it in stone. There are three problems with this approach:

• Creating the process would require extensive research, pushing you into a up-front planning "waterfall" approach. In a complex environment it is questionable whether it is even possible to take this approach, but it is certainly intensely challenging to maintain momentum through the planning.
• Rolling out the process in a single "transformation" is highly disruptive and incredibly difficult to organise. Even if a perfect process could be developed (which is doubtful), the transition of a whole organisation will introduce many issues.
• No organisation is static. Our hypothetical "perfect process" is only perfect for today. As the organisation evolves, the process will need to evolve, and fixing the process is not a viable approach in a fast-moving world.

What we need therefore is a mechanism to evolve process, to learn and to improve. And this is probably more important than the original process itself.

What matters is not your process, it's your process for improving your process - Henrik Kniberg , "Lean from the Trenches"

Why the retrospective is run

Retrospectives, as the name suggests, are looking backwards at what has happened, in order to learn from the past and do things differently. We could run these triggered by a specific issue such as an escaped defect or a failure, or even a successful delivery. This would be similar to what classical projects often refer to as a "postmortem" - a retrospective as a response to an event.

I would strongly advise event-based retrospectives, especially to understand major failures or successes. These learning points are a key factor in quality systems.

A typical Agile retrospective, however, is not about an event, but about a team. It is a regular occurrence aiming not for correction of a specific error, but continuous, recurring improvement. This approach is a part of continual improvement which is included in most Agile approaches.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. - Principles of the Agile Manifesto

The end goal of a retrospective is for a team to improve. But also for a team to own their improvement. This ownership is a key capability which a team needs to develop. Takeuchi and Nonaka refer to this as "self-transcendence" and consider a key part of any self-managing team.

Teams appear to be absorbed in a never-ending quest for "the limit.": "The New New Product Development Game" - Takeuchi & Nonaka

Read: Self-transcendence - https://agileplays.co.uk/self-managing-teams-self-transcendence/

Not only about the "how"...

How a retrospective is run is important. Let's not underestimate the challenge of getting a team to come together every iteration and create valuable, meaningful change which makes them continuously stronger. An approach which is sustainable over years of improvement.

However, this is a topic which has been much discussed elsewhere. There's a perennial debate about formats such as whether the retrospective uses the popular "Start, Stop, Continue" format.

• (For those less familiar with retrospectives), "Start, Stop, Continue" is a popular template. A retrospective is about improvement, and this focusses on where we should add something new, where we should take something away, and what we think doesn't need change for now.
• (For those more familiar with retrospectives), even a good template becomes stale, and retrospectives are often improved by a different split (what made you Mad, Sad or Glad?) or a different approach (Three Little Pigs - what parts of our product are sturdy bricks, what are sticks and what are only straw).

I'd strongly advise anyone who is in a team running retrospectives to read some of the great advice out there from experts such as Aino Vonge Corry , whom I was fortunate to meet at Agile Cambridge a couple of years back.

Listen: Aino discussing retrospectives - https://open.spotify.com/episode/3Pi1Xq4Jf8uCfhB8ig9FM6

1. No Retrospective

The most obvious failure point is for a team not to run a retrospective at all. Not infrequently I've seen teams who are not using retrospectives. Assuming that you have introduced retrospectives (and agile development) into the wider organisation, the teams will be aware that they exist. As a leader you need to be concerned why a specific team aren't running them.

One likely possibility is confidence. The team may have no experience of retrospectives and simply not know where to start. This is a great opportunity for you to both teach and coach. Teaching to explain what these are, what the good practices are and what you would expect from the team. But teaching is rarely enough. Agile teams are self-managing, and need to run their retrospectives. As we have noted, it's not easy to do this. Even with the right knowledge, the team need to be willing to self-manage. And that's a coaching opportunity.

One of the biggest reasons (in my experience) for teams not running retrospectives is that they are unwilling to take ownership of their own improvement. Confidence is a large part of that, but understanding self-management is also key. As a leader you need to set expectations around what independence teams should have. Over-reliance on a leader to set goals and to make change will hinder a team's ability to self-manage.

Another frequent reason that teams don't run retrospectives is that they feel too busy. If they are constantly pressured to deliver features, something will give. Retrospectives may be the most visible item which has been abandoned, but likely if you look closely there will be a raft of other quality failures as a result of this pressure. As a leader you will need to emphasise the importance and relevance of retrospectives and the importance of quality over quantity of deliverables.

It's also not unusual that teams have tried but abandoned retrospectives. As a leader you will need to re-energise them. Perhaps they never learned to use them effectively, in which case teaching and coaching in how to run them may be needed. Or perhaps they fell into some of the traps which I explore in Part 2.

Read: Effective Retrospectives - https://agileplays.co.uk/effective-retrospectives-in-agile-development/

Read: Self-managing teams - https://agileplays.co.uk/what-is-a-self-managing-team/

In Part 2 I will look at four other areas where teams may be having difficulties making retrospectives work and how you as an Agile leader can help them.

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.