Agile Zone is brought to you in partnership with:

Esther Derby helps create great work places where people can do their best work and make products their customers value. Not so very long ago, she made her living writing code. She's co-author of Behind Closed Doors Secrets of Great Management and Agile Retrospectives: Making Good Teams Great. You can read more of her thoughts on management, organization, teams, and agile methods at www.estherderby.com Esther is a DZone MVB and is not an employee of DZone and has posted 73 posts at DZone. You can read more from them at their website. View Full User Profile

Promoting Double Loop Learning in Retrospectives

04.07.2013
| 2756 views |
  • submit to reddit
“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.

Published at DZone with permission of Esther Derby , author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)