Every few years, Prosci publishes research on how to make ADKAR work inside agile projects. The most recent iteration is well-intentioned and practically useful for practitioners already deep in the Prosci ecosystem. But there's something worth naming directly: adapting a structured, sequential methodology to fit agile is not the same as having an agile methodology in the first place.
That distinction matters — especially if you're a change practitioner trying to figure out which approach actually fits how your organization works.
What Prosci Means by "Agile Change Management"
Prosci's definition of agile change management is essentially this: take the ADKAR model and CLARC roles, and apply them in shorter cycles aligned to sprints. Their own research describes change teams operating "within conventional, waterfall-style phases of prepare, plan, and manage the change" — even while the project team is running Scrum. Iterative delivery on the project side. Sequential management of the people side.
That's a reasonable workaround. It's not an agile methodology.
The Problem With Retrofitting
ADKAR is a linear model. It describes a sequence of outcomes individuals must achieve — Awareness, Desire, Knowledge, Ability, Reinforcement — in order, before change is considered successful. That's useful for predictable, stable environments where you know what the change is before you start managing it.
Agile environments, by definition, are not that. Requirements shift. Scope changes. The "solution" at sprint 15 may look nothing like what was scoped in sprint 1. When the thing people are being changed toward is itself evolving, a model that front-loads Awareness and ends with Reinforcement struggles to stay relevant.
Prosci's guidance acknowledges this tension. Their adaptation involves more frequent touchpoints, just-in-time training, and earlier reinforcement cycles. These are genuine improvements. But they're adjustments to a fundamentally fixed structure — not a re-architecture of it.
How Lean Change Management Was Built
Lean Change Management wasn't designed as a change management methodology that later learned to tolerate agile. It was built from agile, lean, and Lean Startup thinking from the start.
The core model — Insights ? Options ? Experiments — is a continuous, non-linear feedback loop. There is no prescribed starting point. There is no mandatory sequence. You start where the context tells you to start, and you move based on what you learn, not based on which phase you're in.
The 136 Elements of Change work like a periodic table. Change practitioners select and combine elements — co-creation approaches, facilitation tools, big ideas, stances — to create a response that fits their specific situation. No two organizations get the same compound. That's not a feature added later to support flexibility. That's the structural design.
The Five Universals of Change reinforce this at the values level:
- Co-Creation Over Buy-In — people closest to the change shape the change
- Response to Change Over Resistance — what Prosci calls resistance, Lean Change treats as data
- Meaningful Dialogue Over Broadcast Communications — conversations replace cascade decks
- Experimentation Over Big Plans — learning is a first-class outcome, not a fallback
- Purpose Over Urgency — alignment through meaning, not fear of consequences
These aren't agile-adjacent. They're agile-native.
The Real Question
If you're a change practitioner in an agile environment, the honest question isn't "how do I adapt my change methodology to fit sprints?" It's "does my change methodology actually work the way agile works?"
Prosci's framework was built for a world of stable change, top-down sponsorship, and sequential delivery. It's been thoughtfully extended to handle agile projects, and those extensions are useful. But extension is not origin. The assumptions baked into ADKAR — that you can sequence awareness before desire, knowledge before ability, all the way to reinforcement — reflect a particular model of how change happens to people, not with them.
Lean Change Management was built on a different assumption: that change is uncertain, context-dependent, and best navigated through experimentation and co-creation — not managed through a predetermined sequence of individual outcomes.
What This Means in Practice
In a Prosci-trained agile environment, the change team typically sits adjacent to the delivery team, translating sprint outputs into ADKAR-aligned activities. The people side and the delivery side are parallel tracks that meet at key milestones.
In a Lean Change environment, there are no parallel tracks. The Insights-Options-Experiments cycle mirrors how agile teams actually work. Change activities are experiments with hypotheses, not communications plans with delivery dates. Retrospectives are built into the model, not added as an afterthought. Resistance is surfaced early and treated as useful signal, not as a risk to be managed.
This doesn't make Lean Change universally superior. Large enterprises with deeply Prosci-trained cultures may find genuine value in ADKAR's precision and the research base behind it. Context always wins.
But "agile change management" as a category deserves more than a single entrant that arrived there by adaptation. Some methodologies were designed for this environment from the beginning.
Frequently Asked Questions
What is agile change management? Agile change management is an approach to organizational change that uses iterative, feedback-driven methods rather than sequential plans. It emphasizes experimentation, co-creation, and continuous adaptation over predefined processes.
How does Lean Change Management differ from Prosci's approach to agile? Prosci adapts its ADKAR model to work within agile project environments, applying change management in sprint-aligned cycles while maintaining sequential individual-outcome logic. Lean Change Management was built from agile and lean principles — its core cycle (Insights ? Options ? Experiments) is inherently iterative and non-linear, with no mandatory sequence.
Is ADKAR compatible with agile projects? ADKAR can be applied in agile projects with modifications — more frequent touchpoints, just-in-time training, earlier reinforcement. Prosci's research provides practical guidance for this. The challenge is that ADKAR's underlying logic is sequential, which creates structural tension in fast-moving or uncertain environments.
What makes a change methodology truly agile? A truly agile change methodology shares core characteristics with agile development: iterative cycles, feedback loops that shape the next action, tolerance for changing requirements, co-creation with the people affected, and learning as a first-class outcome — not just a nice-to-have.
Start the conversation