Retrospectives

Learning From Work

In the spirit of looking back and learning, I thought it’d be nice to dive into a few different practices of learning from the work we do. In this issue, we’re going to have a look at a number of different techniques and tools to learn from work – that might be learning from failures, learning from success, or simply learning from daily work. Learning from failures is a really powerful approach, but we should also recognise that, in general, more things go right than go wrong, so learning from success and general daily work provides great opportunities for continuous improvement too. We don’t learn the secrets of a great marriage by only studying divorce.

In this respect, and for ease of language, I’m going to use “retrospective” as a catch-all term for any practice that involves looking back and learning. In different domains, this set of “retrospective” practices includes things such as debriefs, “lessons learned”, post-mortems, After Action Reviews, Washups and more.

There are various triggers for retrospective practices:

• Learning from projects
• Learning at intervals
• Learning from failure and success
• Learning from daily work

Retrospectives are a foundational practice of psychological safety.

Psychological safety is a necessary foundation for an effective retrospective: we’re not going to surface the messy details of work if people don’t feel safe to be candid about what actually happened, and what they did, thought, said or believed. We cannot close the gap between “work as imagined” and “work as done” in a psychologically unsafe environment. Likewise, the more we practise these techniques, the more we exercise the “group learning from work” muscles, the better and stronger we get at it. By doing these more often and demonstrating that there are no negative interpersonal consequences from being candid about work, we both foster greater psychological safety and also get even better at learning, and turning that learning into action.

What Went Well / What Didn’t Go Well

This is the retrospective that I see used most often across multiple domains. It’s simple to use, and can surface effective learning and improvement opportunities if it’s facilitated well. However, in my experience this is usually used at the end of a project, programme or deliverable, or in many teams it may be employed at a certain cadence – maybe every month, or at the end of a sprint, or during a quarterly meeting, for example. Due to that, this often focuses more on the things that happened more recently – if the project was a year long, remembering something that happened in week 2 is challenging at best! We are best placed to learn from things as soon as possible after they happened, because we have the greatest situational awareness closer in time to the event. 

(An exception to this rule is where the event was particularly traumatic, and we need time to process the trauma before we can objectively learn from it)

The Real-Time Retrospective.

Recognising that we often learn most effectively from events the closer we are to them, the real-time retro is a super simple practice for almost any team.

It’s really just a line. Maybe on a wall, or on a virtual board such as Miro, this enables us to identify things that are going well, things we’ve learned, or give people kudos (a sticky note placed above the line), as well as things we need to fix or address (placed below the line). The key points here are that these things are raised as soon as we become aware of them, and importantly, the things below the line are addressed as soon as possible. Placing something below the line is analogous to pulling the Andon Cord. 

Stop, Start, Continue

This is very simple to run, and helps to quickly identify things you can stop doing, start doing, and continue doing. This practice suits a high-cadence, light touch, rapid practice of continuous improvement: try doing this once a week, for just 15-20 minutes at a time.

The After Action Review

The After Action Review is a powerful tool, originally created by the US Army. It’s since been adopted heavily in the UK healthcare system to maximise the learning potential from events that don’t go to plan or have unexpected outcomes (positive or negative). It’s conducted as soon as possible after the event, and asks the following questions: 

• What was supposed to happen?
• What actually happened?
• Why was there a difference?
• What can we learn from this?

The AAR should take anything from 15 minutes to an hour or so, and focuses on learning, not blame. If someone admits a mistake, or even a violation, it’s taken as an opportunity to establish ways to mitigate that in the future. It can be helpful to explicitly read out or display the Local Rationality Principle to help address concerns of blame, and focus on systemic learning over individual mistakes.

The Sailboat Retrospective

This is an easy way in for teams or groups who are not that familiar with retrospectives, or is a fun opportunity to do something a bit different, to see if it surfaces different learning. You can use the template above, or simply draw on a whiteboard. Ask each group member to draw themselves on the boat, and then you can use sticky notes or similar to describe the goals and aspirations of the team (on the island), and the risks (the rocks) that you need to be aware of or steer clear from. The wind that’s helping you move forward may be skills, tools, ideas, or other people and teams. The anchors that are holding you back may be a lack of skills, tools, budget, or something else. This exercise is more about making the implicit, explicit, and beginning to use our collective self-reflection muscles before we move on to more powerful retrospective approaches.

Ishikawa Diagram (or Fishbone Diagram)

This is one of those more powerful and granular retrospective practices. Fishbone diagrams were created by Kaoru Ishikawa, who pioneered quality management processes in the Kawasaki shipyards, and attempt to discover the potential causes of a specific event. There are different categories that you can use for each fishbone, depending on your context, such as:

• The 6M’s: mortal, machine, material, method, mother nature, and measurement. Most commonly used in manufacturing. (Note, this usually uses the term “man”, but I prefer to be gender neutral and use the term “mortal” instead.)
• The 8P’s: procedures, policies, place, product, people, processes, price, and promotion. Most commonly used in the service or retail industries. 
• The 4S’s: suppliers, systems, surroundings, and skills. 

Of course, don’t let doctrine become dogma. Use and adapt this approach for whatever suits your own context, and change the terminology to suit your environment and team. Resist the temptation to find a “root cause”, because once we think we’ve found it, it can prevent us from diving any deeper into the other causal factors. In the vast majority of cases of failure or defects, there is no single root cause, but a set of factors that came together in a particular way (similar to the Swiss Cheese model of failure). 

Causal Pies

To really demonstrate that there often is no single “root cause”, this is a great multi-factorial causal investigation tool, inspired by an epidemiological method used to to demonstrate the causes of (usually) non-communicable diseases. 

Kenneth J Rothman, in 1976, came up with a model that demonstrates the multifactorial nature of causation. Rothman is a professor of epidemiology at Boston University, and used “Causal Pies” to show that disease can occur due to multiple factors, and different sets of factors can cause the same disease to occur. I’ve adapted this concept to help teams to understand how similar failures can occur given different circumstances in complex environments. 

A single factor that contributes to failure is shown as a piece of a pie, like the triangles in the game Trivial Pursuit. After all the pieces of a pie fall into place, the pie is complete, and failure occurs. Individual factors are called component causes. The complete pie, which is termed in epidemiology a causal pathway, is called a sufficient cause. A component that appears in every single pie or pathway is called a necessary cause, because without it, failure does not occur. There are multiple whole pies that can lead to the same failure – and this helps us recognise that just because the same failure occurred more than once, the causes for it may be different each time. The key is to identify the causes that we can control or mitigate for.

Note in the image above that component cause A is a necessary cause because it appears in every pie. But this should not mean that it is the “root cause”, because it is not sufficient on its own.

The Stinky Fish

Thanks to Gustavo Razetti for this one (I’ve adapted the template). This is a great practice for teams to self-reflect on their interpersonal relationships and dynamics. It’s called the Stinky Fish because the longer you leave it, the stinkier it gets! This practice requires a certain level of psychological safety in order to do, but is a great power-up for teams who want to improve their interpersonal practice. 

Download retrospective templates for all the above from psychsafety.com

Some extra points to note on retrospectives:

Continuous improvement is subject to continuous improvement – every retrospective should have a little time at the end to identify improvements to the retrospective itself! Be aware of our tendency to rely on counterfactuals or hindsight bias: “if only they’d done X”, or “they should have done Y”, and of course as the name suggests, this can only be applied in hindsight. As soon as we hear ourselves or someone else saying “should have”, we should check our perspective and use concepts such as Local Rationality to help us frame the situation as it was understood in the moment.

Look for, and amplify, weak signals. Weak signals may be seemingly unconnected to other information, a piece of data that makes little sense on its own. It might be an unexpected or unexplainable alarm or spike in data, or an observation by a team member. Remember the deja vu cat in the Matrix? That was a weak signal.

Retrospectives don’t always need to be synchronous. It’s certainly possible to run most of these virtually, and it’s also possible to create frameworks for asynchronous retrospectives too, by asking people to reflect and provide insights to a shared document. In some cases, this can be even more impactful, as it reduces the perceived time pressure to come up with a solution, fix, or resolution. Just don’t let them drag on too long.

Define the scope and parameters of the retrospective well. If it’s about a project, keep it to the project. If it’s about a failure, keep it to that. It’s easy for teams to unintentionally derail into other areas, so have someone facilitate it well and keep it focused.

Do retrospectives regularly. Make them a habit. If they don’t go well to begin with, it’s ok, you’ll get better over time – learning from daily work is a practice, and a muscle, that improves the more we use it. As the great Dory would say, “Just keep swimming”.

Highlight positives. This is super important – we must be careful not to drift into a Safety-I mindset where we’re only looking at what we did wrong and trying to fix it, at the expense of examining what we did well and doing that more. 

Act on the learning. Failing to actually act on the learning is probably the most common failure I see in the practice of retrospectives – all the effort that goes into learning, and coming up with improvements, ideas and changes, and then daily work gets in the way of actually making the change. Sometimes called “improvement theatre”, this can eventually demoralise a team and result in retrospectives not happening at all.

Who should attend? We should, on the whole, avoid having people present who can, by dint of seniority, power or influence, reduce the psychological safety in the retrospective space. People are less likely to be candid about their experiences and mistakes if someone like the CEO, customer, or a senior stakeholder is in the room.

Recording retrospectives. This is a tricky one, and rather contextual. In general, I avoid recording retrospectives in order to better foster an environment where people feel safe to speak up candidly and without fear that anything they say could be used against them. However, if everyone genuinely agrees to it and wants to, recording a retrospective can help to make sure we note any and all salient points. 


Bonus mention to Exit Interviews (thanks Balazs Szakmary). Whilst these aren’t what immediately comes to mind when you think of “learning from work”, they’re a very powerful way of gleaning very important information that may otherwise be forever lost to the organisation. One of the most powerful aspects of exit interviews is that a significant element of risk has now been removed – you can no longer be sacked, lose out on promotions or bonuses at this point, so those particular barriers to speaking up have been lifted. However, there is still risk, or at least perceived risk, particularly in smaller and close-knit industries, and we may perceive a risk to obtaining a good reference afterwards as well.

Related Articles:

The Andon Cord
The Local Rationality Principle
Human Error
Normalisation of Deviance
Deming’s 14 Points
Agile
Learning From Failure
Safety I and Safety II
Work as Imagined vs Work as Done
The Swiss Cheese Model

These retrospective exercises, and many more, are contained within the psychological safety Action Pack along with more detailed guidance, templates and resources to use with your teams and organisations. Download it now.

2024 Workshops

We’ll soon be announcing the next round of online workshops for early 2024, including Intermediate, Advanced, Management, Measurement, Practice, and the new Train-The-Trainer multi-day workshop. You can’t book them yet, but email me if you want to be on the wait list to find out first when they’re scheduled!

Psychsafety.com courses all now come with Credly Badges! After completion of the course, you’ll receive an email to claim your badge, which you can use to evidence your CPD and share on your LinkedIn profile.

If you’ve previously attended any psychsafety.com workshops, you can request a badge for each workshop you’ve attended!

Note: in addition to affordability based pricing, we offer one free scholarship place on every workshop we deliver. If you would like to request one of these free spaces, email me (tom@psychsafety.com). The scholarship is intended for those for whom any payment at all is out of reach. Preference is given to people in lower-income countries and from disadvantaged or under-represented groups. 

Psychological Safety at Work

I love this by Maria Popova at the Marginalian, on how to apologise and the complex interpersonal dynamics inherent in close relationships:

“To tell the truth despite its untenderness —“it is important to do this, because we can count on so few people to go that hard way with us” — is to be savaged by the unequaled soul-ache of having caused hurt while trying to do the right thing.“

Here’s a piece by Edward Russel at Skift, showing that more than 55% of pilots hesitate to report mental health problems due to fear of career repercussions. The costs of being out of work and receiving treatment, along with the FAA’s expensive and uninsured psychiatric evaluations, discourage individuals from reporting mental health issues or seeking appropriate help. This results in “a culture right now, which is not surprising to me, that you either lie or you seek help,” said Jennifer Homendy, chair of the National Transportation Safety Board. This is a great example of good intentions resulting in negative impacts. It’s important that flight crew feel able to speak up about their mental health without it impacting their career as a result – because the alternative is for them to lie or keep quiet about it, resulting in potential disaster.

Staying in aviation, this piece in The New York Times, by Emily Steel and Sydney Ember, discusses the challenges faced by air traffic controllers in the United States. Those challenges include severe staffing shortages and resultant worker fatigue: a nationwide shortage of air traffic controllers has led to many of them working six-day weeks and 10-hour days, which has resulted in a fatigued, distracted, and demoralised workforce, increasing the likelihood of dangerous mistakes. Indeed, there has been a 65% year-on-year rise in “significant”  air traffic control lapses, with multiple incidents occurring weekly from September 2022 to September 2023. Due to these challenging conditions, many controllers are choosing to resign or retire early, which only exacerbates the shortage and puts additional pressure on the remaining workforce.

There is an academic paper doing the rounds at the moment which attempts to suggest that in some contexts, teams can be “too” psychologically safe. It would seem that the authors mistakenly frame psychological safety as complacency and comfort. In contrast to this definition, in The Fearless Organisation (which is 233 pages long), Amy Edmondson states on page 17 “Psychological Safety is Not About Lowering Performance Standards“. I can only imagine the papers authors didn’t make it that far through the book, and I’m actually somewhat surprised the paper made it through peer review. If research begins with a faulty premise, how can we trust the findings?

Additionally, because the paper is behind an academic paywall, the vast majority of people actually practising leadership and management will only be able to access the executive summary, or just the title, rather than the entire paper.

A deeper, collaborative, critique of the research is in the works, because my fear is that articles like this speak to leaders who prefer authoritarian leadership – it’s easy to read the executive summary of this and believe that it justifies protecting a toxic workplace culture, which could result in disaster.

The paper summary from Wharton is here: https://knowledge.wharton.upenn.edu/article/the-downside-of-psychological-safety-in-the-workplace/

This week’s poem:

Who’s Who, by Benjamin Zephaniah, who sadly died this week. 

I used to think nurses
Were women,
I used to think police
Were men,
I used to think poets
Were boring,
Until I became one of them.