Double-Loop Learning

The Retro That Keeps Having the Same Retro

I once sat through a retrospective where the team identified “unclear requirements” as their top impediment. Good catch. Solid action item. The product owner committed to writing more detailed acceptance criteria.

Two sprints later, same retro, same impediment. “Requirements are still unclear.” New action item: add a refinement session mid-sprint. Two more sprints. Same impediment. New action item: create a requirements template.

The team wasn’t stupid. They were diligent, experienced, and genuinely trying. They kept fixing the problem. The problem kept coming back. And nobody in the room ever asked the question that would have actually changed something: “Why do we believe that more documentation will solve a communication problem?”

That question - the one that challenges the assumptions underneath the fix - is the entire contribution of double-loop learning. Chris Argyris, an organizational theorist at Harvard, spent decades studying why smart, well-intentioned professionals consistently fail to learn from their own mistakes. His answer, published in the now-classic Harvard Business Review article “Teaching Smart People How to Learn” in May 1991, was uncomfortably simple: they’re solving the wrong layer of the problem.

Argyris had been building toward this idea for years. The theoretical foundation appeared in Organizational Learning: A Theory of Action Perspective, co-authored with Donald Schon in 1978. That book laid out the distinction between single-loop and double-loop learning in rigorous detail. But it was the 1991 HBR article that made the concept accessible - and that made it sting. Because the people Argyris was talking about weren’t the struggling performers. They were the stars.

The Model Everyone Draws Wrong

Here’s the thing about double-loop learning. Most people, when they first encounter it, draw a thermostat analogy and call it a day. That’s fine as a starting point. But the model has real teeth once you get past the diagram on the whiteboard.

Single-Loop Learning (the Thermostat)

A thermostat detects that the room is too cold. It turns on the heat. The room warms up. Problem solved. If the room gets cold again, it turns on the heat again. It never questions whether 72 degrees is the right target. It never wonders if the building should have better insulation. It never asks whether the people in the room would actually prefer 68 degrees and a sweater.

Single-loop learning works the same way. You detect an error - a gap between what happened and what you expected. You adjust your actions to close the gap. You leave your goals, values, assumptions, and mental models completely untouched.

This is not a bad thing. Most of daily life runs on single-loop learning, and it should. You burned the toast, so you lower the setting. The deploy failed, so you fix the config. The standup ran long, so you add a timer. Efficient, appropriate, and completely insufficient for the problems that actually matter.

Double-Loop Learning (Questioning the Thermostat)

Double-loop learning adds a second feedback path. Instead of just adjusting your actions, you examine the governing variables - the goals, values, assumptions, and mental models that determined your actions in the first place.

Back to that retro. Single-loop: “Requirements were unclear, so let’s write better requirements.” Double-loop: “Why do we assume that written requirements are the right mechanism for shared understanding? What if the real issue is that our PO and engineers don’t have enough direct conversation? What if our definition of ‘clear’ is actually ‘detailed’ - and detail isn’t what’s missing?”

The second loop doesn’t just fix the action. It rewrites the strategy that generated the action. And that’s where actual organizational learning happens - not in adjusting behavior, but in revising the beliefs that drive behavior.

The Gap Between Espoused Theory and Theory-in-Use

This is Argyris at his most incisive, and it’s the part that makes people squirm.

Espoused theory is what you say you believe. “We value feedback.” “We want to hear dissenting opinions.” “We’re a learning organization.” Theory-in-use is what your behavior actually reveals about your beliefs. And the two are often wildly different.

A manager who says “my door is always open” but responds to bad news with visible frustration has an espoused theory of openness and a theory-in-use of defensiveness. A team that says “we learn from failure” but spends every retro assigning blame has an espoused theory of psychological safety and a theory-in-use of self-protection.

Here’s the kicker - and this is vintage Argyris: most people are completely unaware of the gap. They genuinely believe their espoused theory is their theory-in-use. They’re not being hypocritical. They’re being human. The gap is invisible to the person living it, which is exactly why it’s so hard to close.

(This is also why coaching exists as a profession. If people could see the gap themselves, they wouldn’t need us.)

Double-loop learning means surfacing that gap. Making the theory-in-use visible. And then deciding - consciously, deliberately - whether to change it.

Defensive Routines - Why Smart People Are the Worst at This

Now for the part that should make every agile coach lean forward.

Argyris observed something counterintuitive: the smarter and more successful the professional, the worse they tend to be at double-loop learning. His 1991 article focused specifically on consultants, lawyers, and MBAs - people who had built careers on being right.

Why? Because smart people have the most sophisticated defensive routines. They’re experts at constructing logical arguments for why the problem is somewhere else. They can reframe any feedback so it confirms their existing mental model. They treat every challenge to their assumptions as a debate to be won rather than information to be absorbed.

Argyris called these defensive routines “skilled incompetence” - the use of real skill to avoid real learning. It’s not malice. It’s protection. Being wrong feels threatening when your identity is built on being right.

I’ve watched this play out in coaching engagements more times than I can count. The senior architect who treats every sprint review as an opportunity to defend their design decisions. The VP who asks for honest feedback and then explains why every concern is already being addressed. The Scrum Master who runs textbook retrospectives that somehow never surface anything uncomfortable. (If every retro ends with “let’s keep doing what we’re doing,” that’s not a healthy team - that’s a defensive routine wearing a facilitator hat.)

The pattern Argyris identified is what he called Model I behavior: unilateral control, suppression of negative feelings, rationality as a weapon, and winning as the implicit goal. Model II - the alternative - looks like genuine inquiry, public testing of assumptions, joint problem-solving, and treating information as something to learn from rather than something to manage.

Most organizations espouse Model II and operate on Model I. That gap - between what we say we value and how we actually behave under pressure - is the central challenge of organizational learning.

What This Changes About Your Coaching

Retrospectives (the Big One)

Most retrospectives are single-loop learning engines. And that’s the polite way to put it.

The standard retro format - what went well, what didn’t, what do we change - almost always produces action items that adjust behavior without examining assumptions. “We missed the sprint goal because we underestimated the work.” Action item: estimate more carefully next sprint. Single loop. Done.

A double-loop retro asks different questions. Not “why did we underestimate?” but “why do we believe estimation accuracy is the thing that determines whether we hit sprint goals?” Maybe the real issue is that the sprint goal was imposed rather than negotiated. Maybe the team takes on stretch work to avoid the discomfort of saying no to stakeholders. Maybe “missing the sprint goal” isn’t actually a problem - maybe it’s a signal that the team is doing exactly the right amount of ambitious work.

The practical move: after collecting retro items, pick one recurring theme and ask, “What assumption are we making that keeps this problem alive?” Then sit with the silence. It will be uncomfortable. That discomfort is the sound of a second loop trying to open.

Root Cause Analysis

Five Whys and fishbone diagrams are popular tools - and they’re great at single-loop depth. They trace the causal chain from symptom to action. “The deploy failed because the test suite didn’t catch the regression because the test coverage didn’t include that module because nobody prioritized writing those tests.”

Double-loop root cause analysis goes one level deeper: “Why does our culture deprioritize test coverage? What do we actually value more than quality? And is that the trade-off we’d consciously choose if we named it out loud?”

Most root cause analyses stop at the process layer. Double-loop pushes into the values layer. That’s where the real leverage - sorry, the real traction - lives.

Coaching Leaders

Leaders are particularly susceptible to the Argyris trap because they’ve been rewarded for having answers. The entire incentive structure of most organizations trains leaders to project certainty, minimize vulnerability, and frame setbacks as “learning opportunities” without actually changing anything.

When coaching leaders one-on-one, double-loop learning gives you a concrete tool. Ask them to describe a recent decision that didn’t go as planned. Then ask: “What belief did you hold going in that turned out to be wrong?” Not what went wrong - what did you believe that turned out to be wrong.

That’s a fundamentally different question. And the answer - when they’re honest enough to give one - opens a second loop that no action item ever could.

Agile Transformations

Here’s a confession from the coaching trenches: most agile transformations are single-loop all the way down.

An organization tries Scrum. It doesn’t produce the results they expected. So they adjust: add SAFe for scaling, hire more coaches, create an agile center of excellence. Still not working? Adjust again: try Kanban, restructure teams, implement new tools.

At no point does anyone ask: “What assumptions about how work gets done are we carrying over from the old model? Are we trying to be agile within a management philosophy that is fundamentally incompatible with agility?”

Double-loop transformation asks whether the governing variables - the org’s actual beliefs about control, trust, planning, and accountability - are compatible with the practices they’re adopting. If the organization believes that predictability is more important than learning, no agile framework will survive contact with that belief. The framework will get bent to serve the belief, not the other way around. And then someone will declare that “agile doesn’t work here.”

(Spoiler: it’s not the agile that doesn’t work. It’s the unexamined assumptions underneath.)

What It Looks Like in the Room

Darren had been Scrum Master for a platform team at a mid-stage SaaS startup for about eighteen months. Six engineers, a product manager who’d been with the company since the garage days, and a newly hired engineering manager named Sheila who was still figuring out the culture.

The team shipped reliably. Velocity was consistent. Stakeholders were mostly happy. But their retros had developed a pattern that was starting to bother Darren. Every two or three sprints, the same theme surfaced: “We keep getting pulled into production support mid-sprint.”

The action items were always reasonable. Sprint four: create a support rotation so the same people aren’t interrupted. Sprint seven: negotiate a support SLA with the customer success team. Sprint ten: build better monitoring to reduce the volume of support tickets. Each fix helped for a sprint or two. Then the theme came back.

In sprint twelve’s retro, the sticky notes went up and there it was again. “Unplanned support work.” Two engineers groaned audibly. The product manager started drafting the next action item before the discussion even started.

Darren tried something different. Instead of asking “what should we do about this,” he put a different question on the board: “What do we believe about support work that keeps this problem alive?”

Silence. Then Sheila, the engineering manager, said slowly, “We believe it’s an interruption.”

“Is it?” Darren asked.

More silence. One of the senior engineers pulled up the support ticket data from the last quarter. Forty-two percent of the team’s actual output - measured in commits, not story points - had gone to production support. Not occasionally. Consistently. For six months.

“That’s not an interruption,” the product manager said. “That’s half our job.”

The room shifted. The team had been treating production support as a disruption to their “real work” of building new features. Every action item had been designed to minimize the disruption - rotate the burden, reduce the volume, create barriers between support and sprint work. Single-loop fixes aimed at protecting the sprint from reality.

The double-loop question was different: “Should production support be inside the sprint, not outside it?” And underneath that: “Why do we believe that building new features is more valuable than maintaining the platform our customers are already paying for?”

Over the next hour, the team redesigned their approach. They allocated forty percent of each sprint’s capacity to production support - explicitly, visibly, in the sprint plan. They stopped treating support tickets as interruptions and started treating them as first-class backlog items. The product manager adjusted how he communicated velocity to stakeholders, framing the team’s output as “platform health plus new capability” rather than just new features.

Three sprints later, the “unplanned support work” sticky note didn’t appear. Not because the support work went away - because it wasn’t unplanned anymore. The team had changed the assumption, not just the action.

Sheila caught Darren after the retro. “That question you asked - ‘what do we believe’ - I’ve never heard anyone ask that in a retro before.”

“Yeah,” Darren said. “Turns out the thermostat was set to the wrong temperature the whole time.”

(Dad joke? Maybe. But also exactly how Argyris would have put it, if Argyris had been a Scrum Master instead of a Harvard professor.)

Go Deeper

• Argyris, C. (1991). “Teaching Smart People How to Learn.” Harvard Business Review, May-June 1991. The essential starting point. Short, sharp, and uncomfortable in all the right ways.

• Argyris, C. & Schon, D.A. (1978). Organizational Learning: A Theory of Action Perspective. Reading, MA: Addison-Wesley. The theoretical foundation. Dense but foundational - this is where single-loop, double-loop, and deutero-learning are formally defined.

• Argyris, C. (1990). Overcoming Organizational Defenses: Facilitating Organizational Learning. Boston: Allyn and Bacon. More accessible than the 1978 book, with practical focus on defensive routines and how to interrupt them.

• Schon, D.A. (1983). The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books. Schon’s companion work on reflection-in-action. Pairs beautifully with Argyris’s organizational lens.

• Senge, P.M. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday. Senge built directly on Argyris and Schon. Chapter 10 on mental models is essentially double-loop learning applied to strategy.