The unexpected power of retrospectives

What we were doing wrong and what happened when we started doing them right.

Retrospectives became more common since companies started adopting agile practices because they are a fundamental part of the process itself, retrospectives seem easy:

Retrospective is a meeting […] to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects. [from wikipedia]

Sounds easy, Right Well… wrong! Doing good and useful retrospectives is hard and the reason for this lies in an unexpected place: the complexity of human behavior.

What Wikipedia and agile books don’t tell you is that there are some requirements for a retrospective to be useful and most of the times none of those is satisfied when you perform a retrospective:

• attendees must feel always free to express their opinion
• attendees must be able to identify doable actions
• attendees are aware of the meeting focus

I’ve directed and participated in retrospectives where we wasted time analyzing issues, finding root causes, and discussing diverging opinions about what caused an issue or, worse, where there was no opinion to discuss.

Then, one day, while I was in Santa Clara at O’Reilly 2013 Velocity conference I had an eye-opening experience: I participated in Dan Milstein session (https://conferences.oreilly.com/velocity/velocity2013/public/schedule/detail/28251) about how to do post-mortems with humans, not robots.

He nailed it! That was what we were not deeply understanding: the power of shame. Think about a big, bad issue you had in production (I know you experienced at least one), whoever was involved in that problem is most likely feeling bad and fully or partially responsible already. He dreads the idea of entering a meeting whose goal is to gather up all the issues, the mistakes, the embarrassing things we overlooked. What will people think about him? How much will the trust in him be reduced? Will he be fired?

never underestimate the power of shame, especially if your team is amazing, there will always be someone that fears the judgment of the other participants

I digested that session for a few weeks and then started a slow but steady change in my (and our) way of acting. I realized that leaders often mistake the goal of a post-mortem: it’s all about empowering participants to find their way of self-healing, not about deciding what to do to solve issues.

We, as leaders, are tempted to fall into the trap of thinking that our colleagues (or partners) do not understand the real magnitude of the problem and we feel we have to repeat that to them and, worse of all, we might also instinctively search for a culprit, find who is the cause of the damage.

That’s just the worst thing we can do. The first step is to realize that there is no person that can be changed, there will not be actionable results in focusing on individuals, we have to rationalize that we need to identify what happened, why it happened to let each one of the actors to define who and how he/she should act to improve it. What about what will we do? That’s less important, remember your goal is to let people find their way to start the improvement cycle, not to tell them how to do it.

Do retrospectives instead of post-mortems

Invest time in reviewing all important events, not just those who were not successful: retrospectives should become a common practice, not a moment where we discuss what’s wrong. It’s equally part about what went right, how we as a team did well in not falling into old mistakes or how well we managed a risky deployment, a well-made decision about how to communicate a change and all the other big or small successes that happens over a certain period.

Celebrating success can be very hard and you will be amazed about how many successes there are at any given time. Celebrating success in retrospectives enforces the fact that such a meeting is not about blaming someone or focused on criticizing team performance or decision making.

celebrating success is a key factor to improve restrospective quality

Abruptly stop anyone that starts taking or giving blame

I’m sure you saw this already: you are discussing the origin of a mistake/bug/bad decision and someone comes out an “I didn’t see that email”, “It was my bug in the code” and things like that.

Stop them immediately and clarify that we are not interested in finding who caused that, it’s not helpful and it’s irrelevant. If you didn’t see the email, was the email the right communication channel for that? If that bug shipped, was the test suite good enough?

Focus on things you can control, like tools and processes, not human mistakes.

So, how do we do it?

We do retrospectives after each major product release and we include very different stakeholders: engineering, support, quality assurance, product manager, documentation manager…

We prepare a list of “questions” that is sent to all participants in advance (at least one or two weeks before the real meeting, in our case), the answers are collected and shared before the meeting happens. This might sound similar to the Amazon meeting rules (https://www.inc.com/justin-bariso/jeff-bezos-knows-how-to-run-a-meeting-here-are-his-three-simple-rules.htm) because we also require to write human-readable statements with arguments to support them and we request everyone to read them before starting the meeting.

We separate the meeting into 4 phases:
General introduction
Preparation: what happened during the preparation of the release
Release: what happened during the release
Post-release: what happened after the release

The goal of the general introduction is to state the expectations we had: was it expected to be easy? Hard? Big? Different in any way from the previous ones? Sharing the expectations is useful to let everyone experience the fact that everyone might have looked at this release differently and understand the other colleagues’ expectations.

The goal of the preparation phase is to identify mostly process-related issues, was the way we prepared good enough? Was the communication good enough? Were there too many stakeholders? Were they correct or are we addressing too many recipients?

The goal of the release phase is to review how the actual release process/day went, for all the stakeholders. Where there any surprises? Which ones? Why? What went as expected? How was the communication during release managed? Was it good for everyone?

The goal of the post-release phase is to evaluate the public response to the release. Which issues did we find after the release? Which issues did the customers find? How did we react?

We ask participants to write down the following elements before the meeting:

• What happened: what we have seen, without any opinion or hypothesis, only facts
• Our perception about the root cause: include opinions and hypothesis

During the retrospective meeting we discuss only about:

• Root cause: ensure everyone agrees on it
• What action we need to do to prevent this from happening again

The last point is the most difficult to identify: the goal is to define small changes that can be done asap, not huge refactoring or long activities that would be nice to do but that require planning, design, and or resources we might not have.

Please note that the action is not about what we need to do to fix the issue, it’s about what we need to do to prevent it from happening again. It might be an improvement in communication, in process, in tools and often only marginally about the code, ultimately never about the individuals.

What good retrospectives did to us

After we started doing retrospectives as a systematic way to identify improvement points we steadily saw an improvement in communication, process efficiency and in a broader way we improved our team building. Everyone feels more free to express his opinion without the fear of being bashed for that and everyone is also learning (regardless of meeting type) to focus on facts, not opinions, avoid judgment and to focus on what matters: what we can do instead of what we think should be done.