Appreciative Inquiry (4D Cycle)

The Retro That Changed Direction

I was facilitating a retrospective for a team that had just come through a rough quarter. Missed commitments. A production incident that became a two-week recovery. A departure that nobody saw coming. The usual retro playbook - “what went well, what didn’t, what should we change” - felt like it was going to land with the emotional weight of a performance review.

So I tried something different. I opened with: “Tell me about a moment in the last three months where this team was at its best.”

Silence. Then one of the senior engineers said, “The Wednesday after the outage. We paired up across the whole team and rebuilt the monitoring dashboard in a single day. Nobody told us to. We just did it.”

That unlocked everything. The conversation shifted from cataloging failures to understanding what made their best moments possible. By the end of the hour, they had three action items - not built on fixing what was broken, but on creating more conditions for what already worked. That’s Appreciative Inquiry in a nutshell.

David Cooperrider and Suresh Srivastva first articulated this approach in their 1987 paper “Appreciative Inquiry in Organizational Life” at Case Western Reserve University. Cooperrider’s doctoral work had started with a conventional problem-diagnosis study of the Cleveland Clinic, but what he found was that the most generative conversations - the ones that actually produced change - happened when people talked about what was working, not what was broken. He and Srivastva argued that organizations move in the direction of their inquiry. Ask about problems, you get more problems. Ask about strengths, you get more strengths. Cooperrider later refined the framework with Diana Whitney into the 4D Cycle that coaches use today, published comprehensively in their book Appreciative Inquiry: A Positive Revolution in Change.

(Yes, it sounds suspiciously optimistic. Stay with me.)

The Four Ds and the Thing That Comes Before Them

Appreciative Inquiry follows a cycle of four phases - Discovery, Dream, Design, and Destiny. But before any of those start, there’s a critical step that most people skip entirely. Think of it as the steering wheel that determines where the whole cycle goes.

The Affirmative Topic (The Positive Core)

Before you run a single workshop or ask a single question, you have to choose what you’re inquiring into. In AI terms, this is the Affirmative Topic - and it’s where the whole thing succeeds or quietly falls apart.

An Affirmative Topic is a positive framing of what you want more of. Not “How do we fix our broken deployment process?” but “What does exceptional release confidence look like for us?” Not “Why does cross-team communication keep failing?” but “When has collaboration across teams produced something none of us could have built alone?”

Here’s the thing - and this is the part that trips up a lot of coaches the first time they try AI. The topic isn’t just a reframe. It’s a genuine redirect of attention. Cooperrider’s core claim is that human systems grow toward what they persistently ask questions about. The Affirmative Topic is your choice of direction.

In my classes, I tell people: if you get the Affirmative Topic wrong, you’ll run a perfectly structured 4D cycle and end up somewhere nobody wanted to go. Spend real time here. Interview stakeholders. Test the wording. Make sure it points at something the organization genuinely wants to grow toward - not just a clever inversion of their biggest complaint.

Discovery (“What gives life?”)

Discovery is the phase where you collect stories of the organization at its best. Not hypothetical best. Actual, lived, specific best.

This is done through structured interviews - usually one-on-one or in small groups - using questions designed to surface peak experiences. “Tell me about a time when you felt most alive and engaged in your work here.” “What was happening? Who was involved? What made it possible?”

The magic of Discovery is that it produces data, but not the kind most organizations are used to. Instead of metrics and gap analyses, you get narratives. Rich, specific, emotionally grounded stories about real moments of excellence. And those stories contain the DNA of what the organization is capable of when conditions are right.

A practical note for coaches: the interview protocol matters enormously. Vague questions (“What do you like about working here?”) produce vague answers. Specific questions (“Describe the most energizing collaboration you’ve been part of in the last year - walk me through what happened”) produce material you can actually build on. Cooperrider and Whitney’s interview guides are worth studying even if you adapt them heavily.

The output of Discovery is usually a collection of themes - recurring conditions, relationships, and practices that show up across the best stories. These themes become the raw material for the next phase.

Dream (“What might be?”)

If Discovery asks “what is the best of what is,” Dream asks “what could be if those best moments were the norm instead of the exception?”

This is the visioning phase. Teams take the themes from Discovery and imagine a future where those strengths are amplified. What would this organization look like in three years if the conditions that produced our best work were present every day?

Dream is where AI gets genuinely creative. You’re not problem-solving. You’re not gap-analyzing. You’re painting a picture of a preferred future, grounded in evidence of what’s already possible. The distinction matters - this isn’t wishful thinking disconnected from reality. It’s an extrapolation from demonstrated capability.

(I’ve watched rooms full of skeptical engineers get genuinely animated during a well-run Dream session. There’s something about being asked “what would amazing look like?” instead of “what’s wrong?” that unlocks a different kind of thinking.)

In practice, Dream often involves small groups creating provocative propositions - bold, present-tense statements of the desired future. “We release with confidence because every team member has contributed to the testing strategy.” “Our cross-team handoffs are seamless because we’ve invested in shared understanding, not just shared documents.” These statements become the bridge to Design.

Design (“What should be?”)

Design is where vision meets structure. The provocative propositions from Dream become the basis for concrete organizational choices - processes, roles, relationships, systems, and practices that would make the dream achievable.

This is the most architecturally familiar phase for agile practitioners. You’re essentially asking: “What would we need to build, change, or formalize to make this vision real?” The difference from conventional change management is that you’re designing toward a positive vision rather than designing away from a problem.

Design produces what Cooperrider calls the “social architecture” of the desired future. That might include new team structures, revised workflows, communication practices, decision-making protocols, or learning systems. The key constraint is that every design element must be traceable back to the strengths identified in Discovery and the vision articulated in Dream. You’re not importing best practices from a consulting playbook. You’re building on what already works here.

One thing I’ve learned the hard way: Design is where AI can lose momentum if you’re not careful. The energy of Dream is infectious. The detail work of Design is - well, it’s detail work. Good facilitation keeps the connection between “this is what we dreamed” and “this is the structural change that makes it real” visible and vivid throughout.

Destiny (“What will be?”)

Destiny - originally called “Delivery” in some early formulations - is the implementation and sustaining phase. It answers the question: “How do we bring this to life and keep it alive?”

Unlike traditional change management plans with Gantt charts and milestone reviews, Destiny in AI tends to be more emergent. Teams self-organize around the design elements that resonate most. Pilot initiatives launch. Early adopters start modeling new behaviors. The approach trusts that people who co-created the vision and the design are intrinsically motivated to make it real.

This doesn’t mean Destiny is unstructured. Good AI practitioners build in regular check-ins, storytelling circles, and progress-sharing sessions. The emphasis stays appreciative - “What’s working in our implementation? Where are we seeing the new practices take root? What’s one story from this week that shows we’re moving toward our vision?”

The cycle is iterative. Destiny feeds back into Discovery as new peak experiences emerge from the changes being implemented. The 4D Cycle is not a linear project plan - it’s a continuous learning loop. (Which, if you’re an agile practitioner, should sound very familiar.)

One more thing worth noting about the full cycle: the timeline varies enormously depending on scale. An AI summit for a 500-person organization might unfold over several days with dozens of facilitators. A team-level application might compress the whole cycle into a couple of focused sessions. I’ve run lightweight versions in a single two-hour workshop - Discovery and Dream in the first hour, Design and a few Destiny commitments in the second. The structure scales. The questions stay the same.

What This Changes About Your Coaching

Retrospectives (The Big One)

Let’s be honest - most retrospectives are deficit-focused. Even the ones that start with “what went well” spend 80% of their energy on “what didn’t” and “what should we change.” The underlying assumption is that improvement comes from identifying and fixing problems.

Appreciative Inquiry flips that assumption. What if improvement comes faster from identifying and amplifying strengths?

Try this in your next retro: instead of the standard three-column format, run a mini Discovery. Ask each team member to share one specific moment from the sprint where the team was at its best. Collect the themes. Then ask: “What would it take for next sprint to have more moments like these?”

I’ve watched teams generate action items from this format that are more energizing, more specific, and more likely to actually happen than anything produced by the “what went wrong” column. Not because problems don’t matter - but because people move toward what excites them faster than they move away from what frustrates them.

You don’t have to go full 4D Cycle in a 60-minute retro. Even borrowing the Discovery question set shifts the energy in the room. Start there.

Visioning and Team Chartering

When a new team forms - or an existing team resets - AI provides a powerful alternative to the “let’s identify our challenges and create norms to address them” approach. Instead, run a Discovery across the team: “In your best team experience ever - any team, any job - what made it great? What were the conditions?”

The themes from that conversation become the foundation for team agreements that people actually believe in, because they’re built on lived experience rather than aspirational platitudes.

Sprint Planning With a Strengths Lens

Most sprint planning sessions focus on capacity, velocity, and risk. AI doesn’t replace that - but it adds a layer. A quick opening question - “What’s one strength this team demonstrated last sprint that we should lean into this sprint?” - primes the conversation toward confidence rather than anxiety. Teams that feel capable plan more ambitiously and execute more creatively.

Building a Continuous Improvement Culture

Here’s where AI really earns its keep. Deficit-based continuous improvement has a ceiling. After enough retros focused on problems, teams develop retro fatigue - the sense that they keep surfacing the same issues and nothing changes. AI-based continuous improvement has a different trajectory because it keeps uncovering new strengths to amplify, new stories of excellence to learn from.

The shift from “what’s broken and how do we fix it” to “what’s working and how do we get more of it” is genuinely transformative for team culture over time. It doesn’t mean you ignore problems - that would be delusional, not appreciative. It means you address them from a position of strength rather than a position of exhaustion. A team that knows what it’s capable of tackles its weak spots with more creativity and less dread than a team that’s been marinating in its failures for an hour.

What It Looks Like in the Room

Marcus had been the Scrum Master for a platform team at a mid-size SaaS startup for about eighteen months. The team built and maintained the authentication and permissions layer that every other product team depended on. It was important work - and mostly thankless. When auth worked, nobody noticed. When it broke, everybody noticed loudly.

By the time Marcus reached out for coaching help, the team was stuck in a pattern he described as “defensive engineering.” They spent most of their sprint capacity on hardening, monitoring, and incident prevention. They hadn’t shipped a new capability in two months. Morale wasn’t terrible, but it was flat - the kind of low-grade disengagement where people do competent work and leave on time and never mention the weekend hackathon they used to organize.

Marcus wanted to run a team reset. His first instinct was the usual approach - a retro focused on what’s not working, followed by a chartering exercise to establish new norms. I suggested we try something different.

We started with an Affirmative Topic: “Exceptional platform craftsmanship - when our work makes every team better.” Marcus spent a week doing fifteen-minute Discovery interviews with each team member. One question per interview: “Tell me about a time you were proudest of something this team built or solved.”

The stories surprised him. The tech lead talked about a permissions model redesign from eight months ago that three product teams had praised in all-hands. A mid-level engineer described a Saturday morning when she and a colleague diagnosed a subtle race condition that would have caused intermittent auth failures for months - and the architecture change they proposed on Monday morning that eliminated the entire class of bug. The junior engineer - the one Marcus had assumed was least engaged - told a story about a documentation sprint where the team rewrote every integration guide and got thank-you messages from developers across the company for weeks afterward.

The Dream session ran as a 90-minute workshop. Marcus asked: “If the strengths in these stories were present in our work every sprint, what would this team look like in a year?” The provocative propositions that emerged were specific and grounded - not “we’ll be world-class” but “every capability we ship comes with integration guides that other teams can use without asking us a single question” and “we proactively identify and resolve cross-team dependencies before they become incidents.”

Design took another session. The team mapped concrete changes: a monthly “platform showcase” where they demo new capabilities to product teams. A rotating “craft week” where one sprint per quarter is dedicated to building something new rather than hardening something old. A shared channel for integration questions that the team commits to responding to within four hours.

(The four-hour SLA was the junior engineer’s idea. She’d been quietly frustrated that other teams waited days for answers and assumed the platform team didn’t care.)

Three months later, Marcus told me the defensive engineering pattern had broken. Not because the team stopped caring about reliability - they hadn’t - but because they’d reconnected with the parts of their work that made them proud. The craft weeks produced two new capabilities that product teams had been requesting for over a year. The platform showcase became the most attended optional meeting in the engineering org.

The thing Marcus said that stuck with me: “I almost ran another ‘what’s wrong’ retro. We would have identified the same problems we already knew about and written action items nobody had energy for. Instead we found out what this team is actually capable of when they’re excited about the work.”

That’s the quiet power of Appreciative Inquiry. It doesn’t ignore what’s broken. It just starts somewhere more useful.

Go Deeper

• Cooperrider, D.L. & Srivastva, S. (1987). “Appreciative Inquiry in Organizational Life.” Research in Organizational Change and Development, Vol. 1, pp. 129-169. The foundational academic paper that started it all. Dense but essential for understanding why AI works, not just how.

• Cooperrider, D.L. & Whitney, D. (2005). Appreciative Inquiry: A Positive Revolution in Change. The most accessible book-length introduction. Short, practical, and full of case studies. Start here if you want to run AI sessions.

• Whitney, D. & Trosten-Bloom, A. (2010). The Power of Appreciative Inquiry. Second edition. More detailed than the Cooperrider/Whitney volume, with extensive facilitator guidance and real-world examples.

• Bushe, G.R. (2011). “Appreciative Inquiry: Theory and Critique.” In Boje, D., Burnes, B. & Hassard, J. (Eds.), The Routledge Companion to Organizational Change. A balanced scholarly assessment of where AI delivers and where its claims outrun the evidence. Worth reading for coaches who want to use AI honestly, not evangelically.

• Cooperrider Center for Appreciative Inquiry. Weatherhead School of Management, Case Western Reserve University. Ongoing research, practitioner resources, and the academic home of the framework.