ADKAR and Path to Agility: Why Agile Transformations Need Both Individual Change and Capability Change

Agile transformations stall when leaders treat individual change adoption and organizational evolution as the same problem. They are not. ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) tells you how a person moves through a change. Path to Agility® operationalizes and measures the organizational evolution: the capabilities, the measurable outcome path, and the operating-model alignment that sustain transformation. Use one without the other and you get the failure pattern McKinsey enterprise agility research keeps documenting: 264 of 838 transforming organizations classified as "highly successful," with two missed transformations for every one that hit the mark.

Key Takeaways

• ADKAR addresses individual change adoption (Awareness, Desire, Knowledge, Ability, Reinforcement). Path to Agility operationalizes and measures the organizational evolution: it defines the capabilities, the measurable outcome path, and the operating-model alignment that sustain transformation. ADKAR enables adoption of the change; P2A makes the organizational change stick and measurable.
• McKinsey research found only 31% of 838 agile transformations were classified as highly successful. Failures are usually multi-dimensional, with people-adoption gaps among the most common contributing factors alongside capability and operating-model gaps.
• Prosci research shows initiatives with excellent change management are seven times more likely to achieve their objectives. Capability investment without adoption work is the most expensive way to land in the bottom two-thirds.
• The two models layer naturally: P2A defines what the organization is changing into; ADKAR moves the people through that change. Skip either layer and the transformation goes back to status quo within 18 months.
• Sequence matters. Awareness and Desire have to land before teams are asked to demonstrate new capabilities, otherwise leaders end up evaluating people on a change they never bought into.

What ADKAR Is Built to Do

ADKAR is a model for individual change. Per Prosci, the canonical source, the acronym names "the five outcomes an individual needs to achieve for a change to be successful: Awareness, Desire, Knowledge, Ability and Reinforcement."

The model is sequential by design. A person cannot demonstrate Ability before they have the Knowledge to perform the new behavior. They will not invest in Knowledge if they have no Desire to participate. They will not develop Desire if they have no Awareness of why the change is happening. Reinforcement is what prevents the person from sliding back to the prior behavior under pressure.

ADKAR is excellent at one specific thing: diagnosing where a change initiative is breaking down inside an individual. If a project's adoption is stuck, ADKAR tells you whether the gap is awareness, desire, knowledge, ability, or reinforcement, and what intervention to apply.

Where ADKAR Falls Short in an Agile Transformation

ADKAR is not built to answer the question agile transformations actually need answered: what capabilities does the organization need to develop, in what sequence, to deliver business outcomes?

That is a different problem. ADKAR is silent on it. The Prosci ADKAR methodology page is explicit that the model addresses individual progression through change, not the organizational target state.

The result, when ADKAR is applied alone to an agile transformation:

• People develop awareness of "we are becoming agile" without a definition of what capabilities that requires
• Training programs deliver Knowledge that may not match the capabilities the business outcome actually needs
• Reinforcement happens against events (standups, retros, sprint reviews) rather than against capabilities (predictable delivery cadence, value stream alignment, decentralized decision-making)
• Twelve to eighteen months in, the organization has changed what people do without changing what the organization can do — what we call agile theater

This is the most common failure mode we see at the executive level. Leaders fund the people-change work, the rollout looks healthy by ADKAR metrics, and the business outcomes never move.

What Path to Agility Is Built to Do

Path to Agility is an outcome-driven approach to organizational change. It defines a target state across four layers:

• 9 Business Outcomes: the reasons the transformation exists (Speed, Quality, Predictability, Employee Engagement, Customer Satisfaction, Innovation, Market Responsiveness, Productivity, Continuous Improvement)
• 26 Agile Outcomes: measurable improvements that drive the business outcomes
• 100 Capabilities: what teams and the organization need to be able to do
• 400+ Practices: specific actions that build capabilities

The model is diagnostic. An organization can be assessed against the 100 capabilities and the gaps become explicit. Leaders can see which capabilities support which business outcomes and prioritize accordingly, instead of rolling out a generic framework template and hoping the outcomes follow.

Path to Agility answers the question ADKAR does not: what is the organization changing into, in capability terms, and how does that ladder up to the business outcomes the executive sponsor cares about? For a fuller comparison of the two models head-to-head, see our Path to Agility vs. ADKAR breakdown.

How the Two Models Layer Together

Once you see the two models as solving different problems, the integration is straightforward. The capability layer (Path to Agility) sits above the people layer (ADKAR), and a transformation needs both to land.

The P2A layer answers what and why at the organizational level: what business outcomes the transformation is driving and which capabilities the organization is building to deliver them. The ADKAR layer answers how at the individual level — how each person moves through the change from Awareness to Reinforcement. They are complementary, not competing.

This pairing also resolves the most common board-level objection to agile transformation funding: "what is our return on this?" P2A makes the capability-to-outcome chain explicit. ADKAR makes the individual-adoption progress visible. Together they replace the vague "we are becoming agile" with a concrete narrative: here are the capabilities we are building, here is how each person is progressing through the change, and here is how that connects to the business outcomes you funded.

A Practical Sequence for Combining ADKAR and Path to Agility

The integration is not theoretical. The sequence we use with clients works like this:

1. Define the business outcomes first (P2A)

Before any rollout, leadership picks 2 to 3 of the 9 Business Outcomes the transformation has to move. Most organizations pick Speed, Predictability, and one of Quality, Customer Satisfaction, or Employee Engagement. This becomes the contract: success is measured against these outcomes, not against framework adoption.

2. Map outcomes to capabilities (P2A)

Each business outcome ladders up from a specific subset of the 100 capabilities. Speed without Predictability is a flash in the pan. Predictability without Decentralized Decision-Making becomes a bureaucracy. Mapping makes the dependencies visible and forces a sequencing decision.

3. Assess current capability state (P2A)

Before training, before re-orgs, before tooling, assess where teams actually stand on the capabilities required for the chosen outcomes. This is the Organizational Health Check step. Without it, leaders are funding a destination they cannot describe.

4. Build Awareness and Desire (ADKAR)

This is where most transformations fail. Leaders skip from assessment straight to training. ADKAR's first two elements have to land before training is useful. People need to know why the change is happening (Awareness) and why they should personally invest (Desire). Without those, training produces certification, not behavior change.

5. Develop Knowledge and Ability (ADKAR + P2A practices)

Training and coaching map to specific capabilities, not to a generic framework curriculum. Knowledge: what does this capability mean and what does it look like done well? Ability: can teams demonstrate it under pressure, on real work?

6. Reinforce against capability outcomes (ADKAR + P2A)

Reinforcement is not "we still hold standups." It is: we still demonstrate predictable cadence under stress. We still make decisions at the team level when leadership is absent. We still measure flow rather than utilization. Reinforcement against capabilities is what prevents the regression that the J-curve in agile transformations describes.

Common Mistakes When Layering ADKAR and Path to Agility

After 100+ enterprise transformations, the same integration mistakes show up.

Mistake 1: Treating ADKAR as a substitute for capability definition. Teams know they should adopt change but no one has defined what capabilities the organization needs. Adoption metrics look healthy. Outcomes stay flat.

Mistake 2: Treating P2A as a substitute for individual change work. Capabilities are defined and measured. Training is delivered. But Awareness and Desire never get worked on. Teams comply during assessments and revert under pressure.

Mistake 3: Sequencing them in parallel without coordination. Organizational change management and agile coaching groups operate independently. ADKAR assessments find a Desire gap; P2A capability work pushes ahead anyway. Or P2A finds a capability gap; ADKAR work continues against an outdated change message.

Mistake 4: Stopping at Knowledge. Most agile transformations end at the Knowledge phase. Teams have been trained. They can describe Scrum or SAFe correctly. But they have not demonstrated Ability under real conditions, and Reinforcement is not budgeted. The change does not survive its first quarterly business review under stress.

Mistake 5: Reinforcing the wrong thing. Reinforcement gets pointed at events, tools, and titles instead of capabilities and outcomes. The standup happens daily; the team still cannot deliver predictably. The Scrum Master role exists; decision-making is still bottlenecked at the director level.

Frequently Asked Questions

Is ADKAR a replacement for an agile delivery framework?

No. ADKAR is a model for individual change adoption. It does not specify how teams plan, deliver, or coordinate work. It is designed to layer on top of a delivery framework, not replace one. For agile transformations, ADKAR sits alongside the capability-and-outcome model (Path to Agility) and the delivery framework (Scrum, Kanban, SAFe, or a hybrid).

Can we use ADKAR without an approach like Path to Agility?

You can, but you will lack a definition of the target state. ADKAR will tell you whether each person is progressing through a change. It will not tell you whether the change itself is the one that will move your business outcomes. That is what an outcome-driven approach defines.

How does ADKAR map to the J-curve in agile transformations?

The J-curve describes the temporary performance dip that occurs during transformation. The dip is most often a Knowledge-to-Ability transition: teams know what the new behaviors are, but cannot yet demonstrate them under pressure. Reinforcement is what prevents the dip from becoming a permanent regression. See our J-curve in agile transformation post for a deeper treatment.

Does Prosci endorse using ADKAR with agile?

Prosci publishes guidance on aligning ADKAR with sequential, iterative, and hybrid changes. The model is methodology-neutral by design: it addresses individual change adoption regardless of which delivery framework the organization uses. The integration with outcome-driven approaches like Path to Agility is not Prosci-prescribed; it is a practitioner pattern that works because the two models address non-overlapping problems.

How do we know which model to start with?

Start with the business outcomes (Path to Agility). If you cannot describe the outcomes the transformation has to move, no amount of ADKAR work will save the rollout, because you will be moving people through a change that has no defined destination. Once outcomes and capabilities are defined, ADKAR begins immediately and runs in parallel with capability development.

What does "excellent change management" actually mean?

Per Prosci's research on the ADKAR Model, "initiatives with excellent change management are seven times more likely to achieve their objectives." In our practice, "excellent" means three things: ADKAR work begins before the first training session, capability targets are explicit and measurable, and reinforcement is budgeted past the rollout date. Most failed transformations miss at least one of those three.

What This Means for Executive Sponsors

If you are funding an agile transformation, the practical question is not "ADKAR or Path to Agility?" It is "do we have both layers covered?"

Ask the program leadership three questions. First: which 2 to 3 business outcomes is this transformation moving, and which capabilities ladder up to those? If they cannot answer, P2A work is missing. Second: how are we building Awareness and Desire before training, and how is reinforcement budgeted past go-live? If they cannot answer, ADKAR work is missing. Third: how are these two streams coordinated? If the organizational change management team and the agile coaching team are not on the same weekly cadence, the integration is theoretical.

The 31% McKinsey number — "highly successful" agile transformations — does not improve by picking a better framework. It improves when leaders stop treating individual change and capability change as the same problem and fund both layers explicitly.