ADKAR and agile transformation are not competing frameworks. ADKAR describes the five things an individual needs to adopt a change — Awareness, Desire, Knowledge, Ability, Reinforcement. Agile transformation is an organizational approach to building the capabilities that deliver business outcomes. You need both, and most transformations stall because leaders treat them as alternatives.
This playbook is written for the transformation leader who has inherited both. Your change management team is running ADKAR. Your agile coaches are running Scrum, Kanban, or SAFe. The two groups are not speaking the same language, and the transformation is paying for it.
Why ADKAR and Agile Transformation Need Each Other
Most of the published material on ADKAR and agile is written from one side or the other. Change management writers explain how to stretch ADKAR across sprint cycles. Agile writers argue that ADKAR is fundamentally linear and should be replaced with something iterative. Both miss the point.
ADKAR is a diagnostic model for individual change. It tells you whether a specific person is ready to adopt a specific change, and if not, which gate is blocking them. Agile transformation is a system-level approach to building organizational capability. One operates on humans, one on the system they work inside. Neither replaces the other.
When a transformation fails — and McKinsey research puts the failure rate for large-scale change at around 70% — it usually fails on the human side. The operating model was sound. The tooling was selected. The teams were trained. But the individuals never crossed the Desire gate, and adoption stalled. That's an ADKAR problem wearing an agile costume.
The symptom: sprint velocity improves while adoption flatlines
You will see this in the data. Delivery metrics climb. Teams are shipping. Stakeholder satisfaction scores do not move. Executive sponsors quietly ask whether the transformation was worth the investment. What's happening: the system-level change is working and the individual-level change is not. ADKAR gives you the language to diagnose which gate each person is stuck at. Agile transformation gives you the delivery system to act on what you find.
How ADKAR Fits Inside an Agile Transformation Approach
The integration is not about re-sequencing ADKAR into sprints. It's about mapping each ADKAR element to the rhythm at which agile transformation already operates — and using your existing ceremonies to move people through the gates.
Awareness
Awareness is sustained, not staged. In a waterfall change, you announce once and move on. In an agile transformation, Awareness degrades every time the scope shifts, a new team is onboarded, or a vendor is swapped. Treat it as an ongoing broadcast function, not a kickoff deliverable. Weekly transformation updates, visible OKRs, and sponsor appearances at team demos all keep Awareness fresh.
Desire
Desire is where most transformations break, and it's where managing organizational change takes real effort. Desire cannot be manufactured through communication. It's built by answering one question for each person: what's in this for me on a Tuesday morning? In an agile context, that answer is usually concrete — less meeting overhead, clearer priorities, shorter feedback loops — but it has to be made real, not promised abstractly. Sponsor conversations, manager one-on-ones, and team-level retrospectives are the forums where Desire either builds or erodes.
Knowledge
Knowledge aligns to sprints. Train just-in-time, just-enough, and just-what's-needed. A three-day Scrum class at kickoff is the old model. The new model is: teach the Product Owner role in week one, teach the Scrum Master role in week two, teach facilitation techniques when the team's first retrospective falls flat. Knowledge delivered right before it's needed sticks. Knowledge delivered six weeks early evaporates.
Ability
Ability is the ability to perform. This is where agile coaching earns its keep. Ability develops through deliberate practice inside real work, not through training. Pair a coach with a Scrum Master for four sprints. Let the team struggle through their first three PI Plannings. Demonstrate the behavior, observe the attempt, give feedback. Ability is a sprint-over-sprint capability, not an event.
Reinforcement
Reinforcement happens at every release. In a sequential change, Reinforcement is the post-go-live activity — celebrate, measure adoption, address drift. In an agile transformation, every release is a micro-go-live. Every retrospective is an adoption check. Build Reinforcement into the cadence your teams already run. Celebrate the third sprint in a row the team hit its commitment. Address the fourth sprint in a row a specific practice slipped.
Where Does Your Organization Actually Stand?
18 questions. 4 minutes. Get scored across 9 Business Outcomes and see exactly where to focus.
Where ADKAR and Agile Transformation Actually Clash
Integration is not conflict-free. Pretending otherwise is the mistake that leaves practitioners stuck in the middle.
Linearity. ADKAR is sequential — you can't build Ability before you build Desire. Agile transformations are non-linear. Teams cross the Desire gate at different times. Some individuals regress. You will have people at Reinforcement on one change and Awareness on the next, all in the same sprint. The ADKAR model holds up; the project plan around it does not.
Measurement cadence. ADKAR assessments are typically run as surveys at fixed points. Agile transformations generate behavioral data continuously — sprint retrospectives, team health checks, delivery metrics. Don't replace ADKAR assessments with retro data, and don't replace retro data with ADKAR assessments. Run both and correlate. When team health scores drop and ADKAR Desire scores drop at the same time, the signal is clear.
Framing. ADKAR was built inside waterfall change management, and some of its language still carries that shape. "Reinforcement" implies a defined end state. In an agile transformation, there is no end state — just the next capability to build. Keep the model, update the framing.
A Practical Playbook for Agile Transformation Leaders
This is the sequence we run with clients who have both ADKAR and an agile transformation under way.
Before you start
Align on vocabulary. ADKAR calls them "sponsors." Scrum calls them "stakeholders." SAFe calls them "business owners." These are not synonyms, but they overlap. Publish a one-page glossary before the transformation kicks off. Map each role in your change management plan to its agile equivalent, and flag the ones that don't translate — that's where coordination will break down later.
During scaling
Assign a change lead to every agile release train, value stream, or tribe. Not a communications manager. A practitioner who owns ADKAR diagnostics for the people inside that structure. They attend PI Planning. They sit in retrospectives. They run the monthly pulse surveys. They are part of the delivery system, not a support function attached to it.
When resistance surfaces
Diagnose with ADKAR first. Is this a Desire problem or a Knowledge problem? A Desire problem requires sponsor engagement and manager coaching. A Knowledge problem requires just-in-time training. Agile coaches often default to "let's run a retrospective and talk it out." That works for team-level friction. It does not work when the resistance is an individual stuck at a specific ADKAR gate. Match the intervention to the specific failure mode.
When a team regresses
Agile transformations regress — see 5 reasons teams regress. ADKAR gives you the diagnostic language to explain why a team has regressed to leadership in a way executives can act on. "Three members of the team have dropped below Desire because of the reorganization announcement" is actionable. "Morale is low" is not.
How ADKAR Fits the Path to Agility Approach
Path to Agility® is our approach for transforming organizations. The 9 Business Outcomes, 26 Agile Outcomes, 100 Capabilities, and 400+ Practices give you the system-level map of what to build and in what order. ADKAR gives you the individual-level diagnostic for whether each person is ready to adopt each capability.
We see ADKAR and Path to Agility as orthogonal, not redundant. Path to Agility tells you what capability to build next based on the business outcome you're trying to move. ADKAR tells you whether the humans inside that capability are ready to adopt it. You need both answers before you commit sprint capacity to the change.
Teams that we work with often arrive with one or the other. Change management shops come in with ADKAR but no system-level map of what to build. Agile-first shops come in with a delivery system but no diagnostic for individual adoption. The integration is not difficult once both frameworks are present. It's difficult when one is missing.
This is also why our change management assessment and our Path to Agility Navigator are built to be used together. One measures where the organization is on the capability map. The other measures where the individuals inside it are on the ADKAR gates. Leaders who run both get a picture that neither framework produces alone.
Frequently Asked Questions
Is ADKAR compatible with agile transformation?
Yes. ADKAR is an individual-change diagnostic; agile transformation is a system-change approach. They operate on different levels and do not conflict. The integration requires mapping ADKAR elements to the cadence your agile teams already run — Awareness sustained across the initiative, Knowledge and Ability aligned to sprints, Reinforcement at every release.
Should I use ADKAR or agile change management?
Use both. ADKAR gives you a precise diagnostic for where each individual is stuck. Agile change management gives you the iterative delivery system to act on what the diagnostic tells you. Choosing one and rejecting the other means you're either running a rigid plan against a shifting reality or running a responsive system with no way to measure individual readiness.
How does ADKAR fit with SAFe?
Map ADKAR to the SAFe cadence. Sustain Awareness across every PI. Build Desire through sponsor engagement at PI Planning and during system demos. Deliver Knowledge and Ability through the SAFe training curriculum, sequenced to the rollout of each Agile Release Train. Reinforce at every Inspect and Adapt. The ADKAR roles — sponsors and managers — map to SAFe's Business Owners and Release Train Engineers, with some translation. Publish that translation up front.
When does ADKAR fail in an agile context?
ADKAR fails when it's run as a standalone project with its own timeline, disconnected from the delivery cadence. You will see status reports showing the change management plan on track while delivery teams are visibly struggling. The fix is structural: embed the change practitioner inside the agile structure, not alongside it.
What about scaled frameworks beyond SAFe?
The same principles apply to LeSS, Nexus, and Scrum@Scale. The specific roles and ceremonies differ; the ADKAR mapping logic does not. Awareness is sustained. Desire is built through sponsor and manager conversations. Knowledge and Ability align to the scaling event cadence. Reinforcement happens at every release. If you have a scaled agile framework with defined ceremonies, ADKAR can ride along.
The Bottom Line
Transformation leaders who win with ADKAR and agile together share one habit: they stop asking which framework is right and start asking which diagnostic is this problem calling for. ADKAR for the individual. Agile transformation for the system. Both, run together, from day one.
If your transformation has both frameworks in play and they are not yet talking to each other, that's the coordination problem with the biggest payoff this quarter. Not next quarter. Not after the next release. Now — while the individuals are still willing to move.
If your transformation has ADKAR and agile running in parallel but not yet integrated, start a conversation with our team. We work with a small number of leadership teams each quarter on exactly this kind of integration, and we bring both the Path to Agility® approach and ADKAR diagnostics to the engagement.
Facing These Challenges First-Hand?
We've guided 100+ organizations through transformation. Let's talk about what's happening with yours.
Start a Conversation
