Promoting Double Loop Learning in Retrospectives

“The thinking that got us here isn’t the thinking that’s going to get us where we need to be.”  attributed to Albert Einstein

I have  this niggling concern about retrospectives.

I have no doubt that retrospectives that are too short, don’t result in action / experiment, or fail to delve beneath the surface are a waste of time. (I suspect many retrospectives fall into this category, since many people teach that an entire retrospective consists of Keep/Drop/Add or some variant there of. This is seldom sufficient for deep or creative thinking.)

But what about earnest retrospectives that focus on an area of concern, examine data, analyze underlying issues and result in action?  I worry that some of those fall short, too.  Why?  Because the thinking that got us here isn’t the thinking that will get us where we need to be.

People work out of their existing mental models. When they examine their current actions, they may achieve incremental improvements.  But they may  take a potentially useful new practice and kill it with 1000 compromises, shaping the new practice to fit the old mental model.

This can happen even when people are trying to learn a new way of working. The first OO program I wrote looked remarkably procedural– I was trying to wrap my head around the new paradigm, I hadn’t quite gotten there yet. In a retrospective, if people try to improve their agile practices, they may improve them right back to serial development.  Or, people may make a genuine effort to improve, but they only know what they know, and the possibilities for improvement they can see are within the bounds of their current thinking.

So the task, then, is to examine the thinking and expand possibilities.

Single and Double Loop Learning

Single loop learning asks, “How can we do what we are doing better.”

Double loop learning asks “Why do we think this is the right thing to do,” and involves scrutinizing values, thinking, and assumptions.single and double loop learning

Transformational improvement and significant learning come from making beliefs, assumptions, and thinking explicit, testing them, and experimenting.

Teams may need a little help to make the jump into the second learning loop, As teams are examining their practices, ask questions that help teams surface assumptions and test them.

  • What would have to be true for [a particular practice] to work?
  • [practice or action] makes sense when ___________.
  • [practice or action] will work perfectly when _________.
  • [practice or action] will work well-enough when_________.
  • [practice or action] will be harmful when__________.
  • What do we know to be true? How do we know that?
  • What do we assume is true?  Can we confirm that?
  • Why do we believe that?
  • What is untrue, based on our investigation?
  • What do we say our values are?
  • If an outsider watched us, what would he say our values are?
  • What is the gap?  How can we make the gap smaller?
  • How could we make things worse?

Chewing on a good subset of these questions usually helps a team see their assumptions, and take a different view on what has worked, what hasn’t worked as expected, and the reasons why.

Then, they are in a better position to choose a more effective action, or design an experiment that will help them learn what action to take.

9 Replies to “Promoting Double Loop Learning in Retrospectives”

  1. Thansk Esther for another great story!

    Getting actions out of a retrospective that are doable, and getting them done isn’t easy, as you mention already.

    The questions that you mention will certainly help to come to higher quality actions. It helps the team to learn which action to do when, how to do them, and why. This increases the chance that actions are done!

    Things I often do in retrospectives are:
    – Make the team aware that we look for actions that *they* can do. Empower teams!
    – Limit the number of actions: It’s better to have some “high quality” actions, than many actions that won’t be done
    – Use Root Cause Analysis to find causes (not symptoms) of problems; then define actions to prevent them from re-occuring
    – Evaluate the progress of actions, help the team to understand why some actions worked, and some didn’t (Guess you would call this double loop learning)
    – Use different techniques in retrospectives, depending on the issues at hand, mindset of the team, etc. When in doubt what to do, try something new!

    I also stimulate teams to use whatever means they already have to make their actions visible. Stick them to the wall at their workspace, put them on their planning board, use them as input in the planning game, etc.

    In a way I’m helping teams to develop some continuous improvement skills, being able to efficiently manage their improvements and delivering more value to their customers.

  2. Hi, Esther:

    Thanks for the great post!

    While facilitating the retrospective, i have been struggling with the step of generating insights. I quite often was not happy about the depth of insights the team got, and would like to intervene more and help them to dig deeper. Meanwhile, i had to pay attention to get retrospective done within the timebox. Your post helped me understand more clearly about the problem i face.


  3. Another excellent post Esther! It’s been quite a long time since I tried to extract relevant information from my retrospectives but I always had the desbelief look from the team. Tried some creative thinking techniques to no avail. Maybe a more straightforward approach would be a perfect fit. I’ll have a go. =D

  4. Thanks for this post Esther.

    We also found that our retrospectives are to short for going really deep. To solve this issue we now have an off-site every six months in addition to our retro’s. Here we aim for double loop learning as mentioned in your post. We use the ideas outlined in Scharmer’s Theory U. We have written a blog on the process and would appreciate any feedback you have.



    • Hi, Jorrit –

      I’m curious about how long the “too short” retrospectives are. I hear from a lot of people that they set aside 1 hour at the end of an iteration for a retrospective. That might be sufficient for a 1 week iteration, assuming that everything is working smoothly. But for an iteration longer than 1 week, 1 hour is not sufficient. In my experience, its nearly impossible to get something useful if you spend only one hour and your iteration is 2 weeks or longer. Better to skip the retro and go for relax over coffee for an hour.

      I find Theory U interesting. I remember Sigi Hinger talking about using it for retros at one of the Retros Facilitators Gatherings.

      I’ll go read your post now…

      Thanks for stopping by and commenting.


Comments are closed.