Using Agile Practices with ADKAR — A 2026 Update

I wrote the original post over 10 years ago and More than a decade later, this post still gets traffic. That tells me people are still searching for the intersection of agile and change management. So rather than patch the original, I rewrote it from scratch. A lot has changed — not least of which is my own thinking.

What ADKAR Is (and What It Isn't)

ADKAR is a model developed by Prosci. It describes the five building blocks of individual change:

• Awareness — Do people understand why the change is happening?
• Desire — Do people want to support and participate in the change?
• Knowledge — Do people know how to change?
• Ability — Can people actually do what's being asked of them?
• Reinforcement — What will sustain the change after go-live?

ADKAR is a diagnostic model. It tells you where someone is in their change journey. It doesn't tell you how to move them forward. That gap is exactly where agile thinking becomes useful.

The 2014 version of this post tried to blend ADKAR steps with agile practices in a fairly linear, prescriptive way. The problem is that both agile and change are nonlinear, and treating them like a checklist misses the point of both.

What I want to do here instead is show how the values and principles behind agile — not the ceremonies or frameworks — can make ADKAR more effective in practice.

If you want the full picture of what those values and principles are, I've put them together at agilechange.management.

The Core Problem: ADKAR Describes Change, Agile Navigates It

ADKAR gives you a lens. If someone is stuck at Desire, you know awareness is not the problem. That's genuinely useful.

But ADKAR doesn't tell you what to do about it. Most organizations respond to a Desire gap by escalating communications, adding more training, or pressuring managers to reinforce the message. All of that is a push-based approach — move the person toward the change.

Agile thinking flips this. Instead of pushing, you create conditions that pull people toward change. You reduce barriers, surface what's actually going on, and let people help shape what comes next.

That shift — from push to pull — is the underlying principle worth holding onto.

Applying Agile Thinking Across Each Stage of ADKAR

Awareness — Stop Broadcasting, Start Conversing

Most Awareness campaigns are one-way: a town hall, an email from the CEO, a poster in the hallway. People receive information; they don't participate in it.

The agile approach to Awareness is to treat it as a two-way feedback loop. Lean Coffee sessions — informal, agenda-less conversations structured around participant-generated topics — are still one of the best tools I know for this. You learn more about what people actually think in one 45-minute Lean Coffee than in a dozen all-hands meetings.

A few practices that work:

• Create a simple Change Canvas with the who, what, why, and what's not changing, and bring it to the people affected — don't just post it on the intranet. (Change Canvases are part of the Lean Change OS)
• Run a Lean Coffee in each affected team or department before the formal change launch. Use it to surface assumptions and questions you didn't know existed.
• Make the change visible with a Big Visible Change Wall — a shared board showing what's happening, what's coming, and where teams can give input. (More on this element here)

The data you collect during Awareness is not just for measuring readiness — it's the first round of insights that should shape your approach to everything that follows.

Desire — Co-creation Over Buy-In

The 2014 version of this post talked about "change champions" and the WIIFM (What's In It For Me) question. That's still relevant. But there's a more fundamental shift worth making.

Traditional change management tries to build Desire by selling the change — communicating benefits, managing resistance, enrolling champions to carry the message. This is a buy-in model. The implicit assumption is that the change was designed somewhere else, and now needs to be accepted.

Agile thinking challenges the assumption. Co-creation — involving the people affected in designing the change itself — is a far more reliable path to Desire than any communication campaign.

When people help write the plan, they don't fight the plan. That's one of the 12 principles of agile change management.

Practices that support this:

• Run Open Space sessions to let teams define what the change means in their context. Open Space is one of the most underused tools in change — when done properly, it creates more alignment in a day than months of cascading communications. (More on Open Space as a Lean Change element)
• Use Moving Motivators (from Management 3.0) to understand what drives the people affected — intrinsic motivators vary significantly by person and role, and understanding them shapes how you talk about the change.
• Let early adopters define their own version of what success looks like. Don't hand them KPIs. Ask them.

Knowledge — Experiential Over Instructional

This is where most change programs spend most of their budget, and where most of the waste lives.

Training that happens before people have Desire is almost entirely wasted. People learn by doing, not by attending. ADKAR acknowledges this sequencing problem, but it doesn't solve it — organizations still tend to schedule training as an event, not as part of an ongoing practice cycle.

The agile equivalent of Knowledge-building is the feedback loop: build something, use it, learn from the experience, adjust. Applied to change:

• Design training as short, repeated cycles rather than one big event. A two-hour workshop every two weeks produces more lasting capability than a two-day course delivered once.
• Use Experiments to create safe-to-try learning opportunities. Give people a specific, bounded context to try the new behaviour, and treat the outcome as data — not as pass/fail. (Experimentation as a Lean Change element)
• Build in retrospectives after every significant learning cycle. What worked? What didn't? What will we try differently next time?

Communities of practice and peer learning still work. The principle is the same as it was in 2014: create sustained opportunities for people to practice, not just receive information.

Ability — Sustainable Pace Over Maximum Throughput

The gap between Knowledge and Ability is where change initiatives quietly die. People know what they're supposed to do. They don't have the time, space, or psychological safety to actually do it.

Agile has a term for this: sustainable pace. The idea is simple — you cannot sustainably run at 100% capacity and also absorb change. Some slack is not a luxury; it's a precondition for learning.

Organizations routinely do the opposite: they launch a transformation while adding it to existing workloads. Then they label the resulting resistance as a people problem.

What actually helps:

• Make capacity explicit. If people are expected to adopt new ways of working, what are they going to stop doing to make room?
• Limit work in progress. Introducing too many changes simultaneously creates thrashing — people context-switch between the old and new ways of working and get good at neither. One well-supported change at a time is almost always more effective than five simultaneous ones.
• Separate coaching from managing. Change agents and agile coaches can help people develop Ability. Managers who are also accountable for delivering outcomes through the same people face a structural conflict of interest in that role.

Reinforcement — Continuous Feedback, Not a Closeout Report

The 2014 version of this said "the change will be reinforced when people attach meaning to it." That's still true. But the mechanism matters.

Most change programs treat Reinforcement as a phase — something you do at the end of an initiative, measured through surveys and adoption metrics. Agile thinking treats reinforcement as a continuous loop, not a closing step.

The Feedback Driven element in the Lean Change OS makes this concrete: use real feedback from real experiments as the primary input into how the change evolves — not annual surveys or governance checkpoints. (More here)

Practices that sustain change:

• Run retrospectives at the team level on a regular cadence — not to celebrate wins, but to honestly examine what's working and what isn't.
• Update your Change Canvas quarterly to reflect what has shifted in the context, the approach, and the understanding of success.
• Use Diagnostics — leading indicators that help you see problems before they calcify into resistance. Trailing indicators (adoption rates, survey scores) tell you what happened. Leading indicators tell you what's coming. (Diagnostics element)

The Bigger Picture: ADKAR + Agile Values

ADKAR remains a useful diagnostic tool. It helps change agents identify where an individual is in their change journey and gives a framework for designing targeted interventions.

But ADKAR as a process — applied linearly, managed as a plan — tends to produce exactly the kind of compliance-based change that agile thinking pushes back against. People move through ADKAR on paper while the actual change stalls in the background.

The values behind agile change management offer a different starting point:

• Individuals and interactions over processes and tools — understand the person before applying the model
• Working solutions over comprehensive documentation — show people something real rather than describing what's coming
• Co-creation over contract negotiation — invite people into the design of the change, not just its delivery
• Responding to change over following a plan — use what you learn at each stage to adapt, not just to execute

T

hose values don't replace ADKAR. They inform how you use it.

If you want to go deeper on what agile change management actually means — the full set of values, 12 principles, and the Lean Change elements that make them practical — that's what agilechange.management is for.

A Final Note on What Changed

The practical tools from 2014 — Lean Coffee, retrospectives, Change Canvases, limiting WIP — still hold up. What I'd update is the framing.

The 2014 post treated ADKAR as the primary model and agile as a set of techniques to layer on top. In 2026, I'd reverse that: start from agile values, and use ADKAR as one of several diagnostic lenses available to a change agent working from a context-first approach.

The goal has never been to make change management agile. It's to make change more effective. Sometimes that means running a Lean Coffee. Sometimes it means asking a better question before you reach for any tool at all.

Jason Little is the founder of Lean Change Inc. and the creator of the Lean Change OS — a body of knowledge for modern change practitioners. He is the author of Lean Change Management and Change Agility.