What agile actually means for change managers: five principles that reshape your practice

Jul 8, 2019 | Agile

Why traditional change management struggles in agile environments

Traditional change management is designed around certainty. You conduct a change impact assessment at the beginning of the project, define the stakeholder engagement plan, sequence the communications calendar, and execute against it. The implicit assumption is that the shape of the change is knowable early enough to plan for it properly.

Agile delivery rejects this assumption. Features are discovered through iteration. Scope evolves with each sprint. A requirement that seemed clear at the start of the programme may look completely different by sprint 10. This is a feature of agile, not a bug — but it creates a fundamental problem for change managers who are trying to communicate with stakeholders about “what is changing” when the answer shifts every two weeks.

Research from the Project Management Institute on agile change management found that change functions struggle most with the timing and specificity of stakeholder engagement in agile contexts. The challenge is not willingness to adapt but the absence of a clear model for how change management activities map onto sprint cadences. The five principles below provide that model.

Principle 1: Iterative change instead of big-bang adoption

In traditional delivery, the change management effort builds toward a single go-live moment: the day everything changes and users adopt the new system or process. Communication, training, and engagement all converge on that point. In agile delivery, there is no single go-live. There are increments: features that go live in sprint releases, with users adopting new capabilities progressively across months.

This shifts the change manager’s role from managing a transition event to managing a continuous adoption curve. Instead of a one-off training programme delivered two weeks before go-live, you need a series of shorter, more frequent touchpoints aligned to sprint releases. Instead of a single readiness assessment, you need rolling readiness checks that track adoption of each increment as it lands.

What this looks like in practice

A practical implication: your communication planning needs to operate on a sprint-by-sprint cycle rather than a project timeline. At the beginning of each sprint, ask the delivery team what will be released at the end of the sprint and who will be affected. Design a targeted, lightweight communication or engagement activity for that audience. At the end of the sprint, measure adoption of that increment before the next sprint planning begins. This gives you a closed feedback loop that is responsive to the actual pace of delivery, rather than a communication plan that was written six months ago and is increasingly disconnected from what is actually being built.

MIT Sloan Management Review research on agile transformation found that organisations using iterative adoption approaches achieved significantly higher sustained adoption rates compared to those using single-event go-lives, particularly for complex technology implementations. The reason is simple: users have more time to adapt, and issues are identified and resolved before the next increment builds on them.

Principle 2: Multi-disciplinary team membership

In traditional project delivery, the change manager operates alongside the project team: attending steering committees, reviewing deliverables, and running parallel workstreams. In well-functioning agile delivery, the change manager is embedded within the team — attending daily standups, participating in sprint reviews, and contributing to retrospectives alongside developers, business analysts, and product owners.

This distinction matters enormously. A change manager who attends steering committees learns about sprint outcomes weeks after they happen. A change manager embedded in the team learns about changes to scope, design decisions, and technical constraints in real time, which is the only way to keep stakeholder engagement current in a fast-moving delivery environment.

The practical implication is that change managers working in agile environments need to be fluent in agile ceremonies and vocabulary. Knowing what a sprint review is, what a retrospective is for, and how the product backlog is prioritised is not optional knowledge — it is the baseline for participating in the team effectively. Atlassian’s research on agile at scale consistently identifies the absence of change management capability within delivery teams — rather than alongside them — as a primary factor in transformation failures.

Principle 3: Early and continuous stakeholder engagement

Agile shifts stakeholder engagement from a scheduled event (a town hall, a training session, a change impact workshop) to a continuous process. In a sprint-based environment, end users and business stakeholders should be involved in sprint reviews — they should see what has been built, provide feedback, and have that feedback incorporated into subsequent sprints. This is stakeholder engagement in the most direct sense: users shaping the design of the change as it happens, rather than being informed about it after the design is locked.

The change manager’s role here is to facilitate this engagement, not just to plan communications about it. This means helping the product owner understand which stakeholders need to be involved in which sprint reviews, ensuring that business representatives are available and briefed before sprint reviews, and capturing the feedback from those sessions in a form that the delivery team can act on.

Managing stakeholder fatigue in continuous engagement

One practical challenge is preventing stakeholder fatigue when engagement is continuous rather than episodic. The solution is to be selective and purposeful: not every stakeholder needs to attend every sprint review. The change manager should map which stakeholder groups are most affected by upcoming sprint releases and prioritise their involvement accordingly. Less relevant stakeholders can receive lightweight updates rather than attending in person.

Research from Prosci on agile change management found that organisations with active stakeholder participation in sprint reviews experienced 35% higher adoption rates for agile-delivered changes compared to those using traditional post-delivery engagement models. The reason is that stakeholders who have been involved in shaping the design arrive at go-live with a much stronger understanding of what is changing and why, which directly reduces resistance and accelerates adoption.

How Scrum and Kanban change your planning cadence

Agile delivery teams typically operate using one of two frameworks: Scrum or Kanban. Understanding the difference matters for change management, because each creates a different planning environment.

Change management in Scrum teams

Scrum organises delivery into fixed-length sprints, typically two weeks. At the start of each sprint, the team commits to a defined set of deliverables from the product backlog. At the end of each sprint, the team holds a sprint review (demonstrating what was built) and a retrospective (reflecting on how the team worked). For change managers, the sprint structure creates a natural planning cadence:

Sprint planning: Understand what will be built and identify which stakeholders will be affected when it is released
During the sprint: Prepare communication, engagement, or training assets targeted at the upcoming release
Sprint review: Bring relevant stakeholders to see what has been built and gather their feedback
Sprint retrospective: Raise any change management concerns about adoption readiness or stakeholder reactions

Change management in Kanban teams

Kanban does not use fixed sprints. Work flows continuously from backlog to in-progress to done, with release happening when items are completed rather than at the end of a sprint cycle. This creates a more fluid environment for change management, where the focus shifts from sprint-level planning to flow management: ensuring that the rate at which changes are released to users does not exceed their capacity to absorb them. In Kanban environments, change managers often work most effectively by collaborating with the product owner to manage the release cadence deliberately, using capacity data to inform decisions about when to hold back completed features versus releasing them continuously.

Digital tools that support agile change management

Managing the cumulative adoption load across multiple agile delivery teams requires more than intuition. As organisations scale agile delivery across dozens of concurrent product teams, each releasing increments continuously, the aggregate change burden on affected business areas can become significant. Platforms like The Change Compass enable change managers to track and visualise the cumulative impact of agile releases across the portfolio, providing the portfolio-level visibility that individual team-level change management cannot deliver. This is particularly valuable for organisations running multiple agile programmes simultaneously, where the risk is not any single team’s release cadence but the combined load hitting the same business areas at the same time.

Adapting your practice without losing what works

The five principles above do not require abandoning change management fundamentals. Stakeholder analysis, impact assessment, readiness measurement, and communication planning all remain relevant in agile contexts. What changes is the frequency, granularity, and integration of these activities with the delivery rhythm. The change manager who understands this distinction, and can articulate it clearly to delivery leads and project sponsors, becomes a genuine asset to agile teams rather than a friction point in their way.

Start by attending the next sprint review for a programme you are supporting. Observe how decisions are made, who is in the room, and what happens to the feedback that is given. That single step will teach you more about what agile change management requires than any number of certification courses.

Frequently asked questions

What is agile change management?

Agile change management is the practice of integrating change management activities — stakeholder engagement, impact assessment, communication, and adoption support — into agile delivery frameworks like Scrum and Kanban. It differs from traditional change management by operating in shorter cycles aligned to sprint releases, with continuous rather than episodic stakeholder engagement.

What is the role of a change manager in a Scrum team?

A change manager embedded in a Scrum team attends daily standups, sprint planning sessions, sprint reviews, and retrospectives. Their primary contribution is ensuring that business stakeholders are engaged in sprint reviews, that the adoption readiness of each increment is tracked, and that communication activities are aligned to sprint release cycles rather than to a single project go-live date.

How is agile change management different from traditional change management?

Traditional change management assumes a defined scope delivered at a single point in time, with change activities building toward a go-live event. Agile change management operates in continuous cycles, with scope evolving through iterations. The key practical differences are that engagement activities are much more frequent, stakeholders are involved in shaping the design (not just receiving it), and adoption is measured incrementally rather than at a single post-implementation point.

How do you measure adoption in an agile change management context?

Adoption measurement in agile contexts should be sprint-by-sprint rather than a single post-implementation survey. After each sprint release, measure whether affected users have adopted the specific features released in that sprint. This allows you to identify adoption issues early, understand which user groups are struggling, and feed this information back into sprint planning so the delivery team can prioritise support or adjustments in subsequent sprints.

Can you use Prosci ADKAR in an agile environment?

Yes, the ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement) applies in agile contexts, but the activities that build each element need to be distributed across sprint cycles rather than concentrated before a single go-live. Awareness and Desire activities happen early in the programme and are reinforced with each sprint review. Knowledge and Ability are built incrementally as each sprint release is adopted. Reinforcement is ongoing throughout the delivery lifecycle.