A critical part of agile is being able to iterate and continuously improve in order to deliver an optimal solution. Rather than one large change release, an agile project would break this down into smaller releases. Each release will go through an iterative process to test, collect data, evaluate and use any learning to improve the next release.
If an agile approach is appropriate we should also adopt this same approach in how we deliver change management activities. This means that we should be running a series of experiments to test, learn, document and improve on how we deliver change to the organization.
This contrasts to how most change managers would approach developing and delivering the change approach. The standard approach is collecting various information about the change, talk to key stakeholders about the change, and then form a view based on previous experiences in terms of what change approach would work for this initiative. Then, this approach would be present to stakeholders to get their blessing before executing on the change approach.
Below is an example of planning to run experiments in an agile environment from Alex Osterwalder, the founder of Strategyzer. First is designing the experiment, shaping its hypothesis, and testing it, which involves looking at the outcome data, learning from the experiment and making any relevant decisions based on the outcome.
Referenced from Alexander Osterwalder.
In this first part of a series on practical agile applications for change managers we focus on communications.
Communicating for change is a critical part of managing change and is also one that can easily be tested using a series of experiments.
The Campaign Monitor has outlined a series of aspects in which emails can easily be tested. These include:
Subject headlines
Pre-header
Date and time
Call to action
Content
Digital businesses also often conduct A/B Testing whereby 2 different sets of content are designed and delivered at the same time for the duration of the test. At the conclusion of the experiment we can then look at the results to see which one did better based on audience responses.
How do we measure communications experiments?
There are several ways to do this:
Readership – For intranet pages, your corporate affairs rep can usually access readership statistics
Surveys – Send surveys to the audience to ask for feedback
Focus groups – Run small focus groups for feedback
There is one area in which corporate can better learn from digital businesses – using digital tools to measure and track communications. For example, you can send out emails promoting a new intranet page, and then check back to see how many users actually visited the site. The results may be helpful as an initial experiment before launching the email to a wider audience group to achieve maximum results.
There are plenty of external tools such as ActiveCampaign or Mailchimp where you are able to use features such as:
A/B testing results
Send emails are certain times or dates
Automatic email responses
Target particular segments
View and click rates
In the following diagram you can see an example that it’s not difficult to build a drip-email series of interactions with your stakeholders based on their responses (or lack of).
It’s feasible to use these tools for a project where you can run a series of experiments and measure outcomes to support your change iterations.
Walk into any large organisation and ask which team owns change management. The answers you receive will be illuminating. HR will tell you it is fundamentally a people and culture discipline. The project management office will point out that every project methodology includes a change stream. Communications will argue that behaviour change is impossible without the right messages. IT will note that system adoption is the primary delivery risk on their programmes. And depending on the organisation, finance, legal, or operations may each have their own claim.
This is not a trivial naming dispute. When multiple functions each believe they hold the primary expertise in managing change, the practical result is fragmented accountability, duplicated effort, conflicting methodologies, and employees who receive inconsistent and often contradictory guidance about the same transformation. Understanding why this happens — and what it means for how organisations should develop genuine change capability — is one of the more important questions in organisational design.
Why every function has a partial claim
The reason so many functions feel entitled to claim change management expertise is that they are all, in a genuine sense, partially right. Change management as a discipline draws on theories and practices that have been developed across psychology, organisational behaviour, communications, project management, and HR. Each of these fields has made real contributions to our understanding of how individuals and organisations adapt. The problem arises when a partial contribution is mistaken for the whole discipline.
HR’s claim is grounded in the fact that people are at the centre of every change. Resistance, capability development, role redesign, and cultural alignment are all genuinely HR concerns, and the best HR practitioners bring sophisticated people skills to change work. What HR frameworks often underweight is the structural and portfolio-level complexity of managing multiple concurrent changes — the governance, sequencing, and organisational capacity questions that are distinct from any individual people initiative.
Project management’s claim is grounded in the reality that most organisational change is delivered through projects. Disciplined planning, risk management, milestone tracking, and resource allocation are essential to any successful transformation. But project management frameworks are designed to deliver defined outputs within a scope boundary. Change management is concerned with what happens to the organisation after the outputs are delivered — whether behaviours actually shift, whether capabilities are actually built, whether the change is actually absorbed into how work gets done.
Communications’ claim is well-founded because uncertainty is the primary psychological driver of change-related stress, and communication is the primary tool for replacing uncertainty with clarity. But communication without genuine understanding of the change’s impact on specific roles and workflows becomes messaging without meaning — polished announcements that tell employees what is changing without helping them understand what it means for how they do their job on Monday morning.
IT’s claim stems from the fact that many of the most significant organisational changes in recent decades have been system implementations — ERP rollouts, CRM migrations, digital transformation programmes — where adoption of a new technology platform is the primary measure of success. Technology change is real change management work, but it is a subset. Organisations that define change management as system adoption have implicitly limited their change capability to one category of change, leaving them less equipped for structural reorganisations, process redesigns, or strategic pivots that do not have a technology component.
The consequences of fragmented ownership
When change management ownership is fragmented across functions, several predictable problems emerge. The first is methodology inconsistency. Employees who have been through five transformations in three years may have experienced five different approaches to stakeholder engagement, five different formats for impact assessment, five different ideas about what “being consulted” means. This inconsistency erodes trust. When people cannot predict how change will be handled, they become cynical about the process before it has even begun.
The second problem is invisible cumulative load. No single function has a view across the entire change portfolio. HR sees the people initiatives. The PMO sees the project list. Communications sees the announcement schedule. But no one is looking at what all of these add up to for a specific team or role group at a specific point in time. The result is change saturation — teams absorbing more concurrent change than their adaptive capacity can handle — that is entirely visible in retrospect but was invisible to every function at the time.
The third problem is accountability diffusion. When everyone owns change management, no one is truly accountable for whether a change lands well. The PMO can point to on-time delivery. HR can point to the training programme that was run. Communications can point to the number of messages sent. But if adoption is low, productivity has not recovered, and employees are still doing things the old way six months after go-live, the responsibility can be passed indefinitely between functions. No one is accountable for the outcome, only for their slice of the input.
What genuine organisational change capability actually looks like
Genuine change management capability is not located in any single function, but it does require a recognised discipline with its own body of knowledge, its own accountability structures, and its own seat at the table when strategic decisions are made. The most capable organisations treat change management the way they treat other enterprise capabilities — as something that requires deliberate investment, clear ownership, and measurable standards.
The characteristics of organisations with mature change capability are well documented in the research literature. Prosci’s longitudinal research on change management best practices consistently finds that the highest-performing organisations share several features: dedicated change management practitioners who are not also wearing project management or HR hats; executive sponsorship that is active rather than nominal; structured methodology applied consistently across programmes; and formal mechanisms for capturing and applying lessons from past changes.
Critically, mature change capability is not about the size of the change team. Small change teams that have organisational authority, cross-portfolio visibility, and rigorous methodology consistently outperform larger teams that are embedded in individual functions without coordination. The key variable is not resource quantity but structural position.
The role of data in adjudicating functional claims
One of the reasons functional disputes about change management ownership persist is that they are typically conducted without data. Each function makes its claim on the basis of its professional identity and its past experience, not on the basis of evidence about what actually drives change outcomes in the specific organisation. This is a solvable problem.
Organisations that measure change outcomes — adoption rates, productivity recovery, attrition during transitions, error rates in new processes — quickly develop an evidence base for understanding which factors actually determine whether changes land well. In most organisations that collect this data systematically, the findings consistently point to the same variables: the quality of people leadership through the transition, the degree to which employees understood what the change meant for their specific role, the pace of change relative to the organisation’s absorption capacity, and the degree to which concerns raised during implementation were visibly acted upon.
Notably, these factors cut across all the functional claims. Quality people leadership is relevant to HR’s concerns. Understanding what change means for specific roles is a communications challenge. Absorption capacity is a portfolio management question. Acting on concerns is a governance issue. The data, in other words, vindicates the view that change management is genuinely cross-functional — while also making clear that it cannot be owned by any single function in isolation.
This is precisely the insight that drives the design of platforms like The Change Compass, which provides organisations with portfolio-level visibility into change load, impact, and capacity across the enterprise. Rather than giving any one function a proprietary view of the change landscape, this kind of platform creates a shared data layer that all functions can draw on — and that makes the aggregate picture visible to decision-makers who would otherwise be managing blind.
A framework for resolving functional tension
Rather than attempting to definitively answer which function should own change management — a question that will be answered differently in every organisation depending on history, structure, and culture — it is more useful to describe the conditions under which cross-functional change capability works well.
The first condition is a single point of accountability. Even when change management work is distributed across functions, there needs to be one person or team that is ultimately accountable for whether the organisation’s change portfolio is being managed well. This does not mean centralising all change activity — it means ensuring there is someone whose job it is to hold the cross-portfolio view and escalate when capacity constraints, methodology inconsistencies, or accountability gaps are creating risk.
The second condition is agreed methodology. Functions can and should contribute their specialist expertise to change work. But the overarching framework — how impact is assessed, how stakeholders are engaged, how readiness is measured, how adoption is tracked — needs to be consistent across programmes. Agreed methodology does not suppress functional contribution; it channels it.
The third condition is shared data. When all functions can see the same picture of the organisation’s change landscape — the same impact data, the same capacity measures, the same adoption indicators — functional disputes about ownership become less important, because the shared data makes the organisational need clear regardless of which team is doing the work. Harvard Business Review research on organisational judgment consistently finds that shared information reduces the inter-functional conflicts that arise from asymmetric awareness.
The fourth condition is executive sponsorship that cuts across functions. When the senior leader who sponsors the change management capability is positioned above the functional disputes — at the executive team level rather than embedded within any single function — it becomes possible to make governance decisions about methodology, accountability, and resource allocation that no individual function can make unilaterally.
Building maturity rather than winning territory
The framing of change management ownership as a territorial dispute — which function wins? — is ultimately counterproductive. The more useful question is: how does the organisation build mature change capability, and what role does each function play in that maturity journey?
Prosci’s change management maturity model describes five levels of organisational capability, from ad hoc and project-specific at the lower end to organisational competency and standardised methodology at the higher end. What distinguishes higher-maturity organisations is not that they have resolved the question of which function owns change management. It is that they have transcended the functional dispute entirely — change management has become an enterprise capability with its own governance, its own standards, and its own accountability, drawing on but not subordinated to any single function.
Reaching that level of maturity requires each function to make a genuine contribution: HR bringing its understanding of people and culture, the PMO bringing its project governance rigour, Communications bringing its ability to create meaning and clarity, IT bringing its implementation discipline. But it also requires each function to recognise the limits of its contribution — the things that its professional lens does not equip it to see.
The organisations that manage change most effectively are not those where one function has won the territorial dispute. They are those where the discipline has grown beyond the territory entirely.
Frequently asked questions
Why do so many functions claim change management expertise?
Change management draws on knowledge from HR, communications, project management, psychology, and organisational design. Each of these fields makes a genuine partial contribution to the discipline, which means that practitioners from each field can legitimately claim relevant expertise. The problem arises when a partial contribution is mistaken for the whole discipline, leading to fragmented ownership and inconsistent practice.
What are the consequences of fragmented change management ownership?
Fragmented ownership produces methodology inconsistency across programmes, invisible cumulative change load on employee groups, and diffused accountability for outcomes. When every function claims ownership and none is truly responsible for whether changes land well, the organisation loses the ability to learn systematically from change experience and to govern the change portfolio as a coherent whole.
Does change management belong in HR or the PMO?
Neither location is inherently correct. What matters more than location is structural position, accountability clarity, and methodology consistency. Change management capability that sits within HR tends to be strong on people and culture dimensions but may lack portfolio governance. Capability that sits within the PMO tends to be strong on project discipline but may underweight the sustained adoption and cultural dimensions of change. Many mature organisations establish change management as a distinct capability that draws on both functions without being subordinated to either.
What does genuine organisational change maturity look like?
Mature change capability is characterised by consistent methodology applied across programmes, cross-portfolio visibility into change load and capacity, clear accountability for change outcomes rather than just change activities, and systematic capture and application of lessons from past programmes. It is an enterprise capability with its own governance and standards, rather than an activity embedded within any single functional team.
Heat maps have become the default visual language of organisational change management. Almost every change team produces one. They are familiar, easy to build, and satisfying to present, colourful grids that give the impression of analytical rigour. But here is the uncomfortable truth: for most organisations, heat maps are where change analytics begins and ends.
Prosci’s benchmarking research consistently shows that organisations with excellent change management are seven times more likely to meet project objectives than those with poor change management (88% vs 13%). And a key differentiator between excellent and poor is measurement capability. When your change reporting has not evolved beyond the heat map, you are almost certainly making slower and less informed decisions than you could be.
This article does not argue that heat maps are useless. They serve a purpose as an initial orientation tool. But they become dangerous when they are treated as the final word on change impact. Here are the specific limitations, and a practical path forward.
The three problems with relying on change heat maps
Before discussing alternatives, it is worth understanding precisely why heat maps fall short. The issues are not cosmetic, they are structural.
Heat maps flatten complexity into a single dimension
A standard change heat map typically shows volume of change by business unit or stakeholder group, using colour intensity to indicate “high,” “medium,” or “low” impact. But change is not one-dimensional. A business unit might face a low volume of changes that are each individually massive in scope, or a high volume of changes that are individually minor but cumulatively overwhelming.
The core problem is that heat maps flatten multidimensional data into a single visual layer. A 2023 Harvard Business Review article on employee change fatigue revealed that the average employee now experiences 10 planned enterprise changes per year, up from just 2 in 2016. When you reduce that complex, overlapping change landscape to red, amber, and green cells, you inevitably lose the nuance that matters most, particularly the interdependencies between initiatives and their cumulative impact on people.
Heat maps are snapshots, not trajectories
A heat map shows you where things stand at a single point in time. It does not show you whether things are getting better or worse, whether the pace of change is accelerating or decelerating, or whether a business unit that looks “green” today is about to turn “red” next quarter when three major initiatives converge.
Decision-makers do not just need to know the current state. They need to understand the trajectory: where are we heading, and do we need to change course?
Heat maps rarely drive specific action
The most common reaction to a change heat map presentation is nodding. Senior leaders see the colours, acknowledge that some areas have more change than others, and move to the next agenda item. This is because heat maps present information without context or recommendation.
A heat map that shows Finance is “red” tells you nothing about why it is red, which specific changes are causing the overload, or what you should do about it. Without that analytical depth, the heat map becomes wallpaper rather than a decision-making tool.
Five ways to move beyond the heat map
If heat maps are your starting point, the question is: what comes next? Here are five practical pathways that progressively build your change analytics capability.
1. Understand the transformation narrative, not just the volume
Heat maps count changes. But the number of changes is rarely the most important question. What matters is the nature of those changes and how they interact.
Start asking deeper questions about your change portfolio:
Are these changes fundamentally reshaping the operating model, or are they incremental process improvements?
Do multiple initiatives affect the same teams, systems, or processes simultaneously?
Is there a logical sequencing, or are changes landing randomly based on project timelines?
When you understand the transformation narrative, you can explain to senior leaders not just how much change is happening, but what kind of change it is and what it means for the organisation’s capacity to absorb it. For a deeper exploration of why change saturation is a pandemic for most large organisations, this shift from quantity to quality is the single most impactful upgrade you can make.
2. Move from static spreadsheets to data-driven storytelling
WTW’s 2023 global study of 600 organisations found that companies taking a data-driven, proactive approach to change management drive nearly three times more revenue than those with below-average change effectiveness. Change accelerators achieved 6% one-year revenue growth compared to negative 30% for transitional companies. The implication is clear: the quality of your change data directly shapes the quality of your outcomes. Yet many change teams still build their heat maps manually in Excel, updating them quarterly at best.
Data-driven storytelling means:
Replacing opinion-based impact ratings with quantifiable metrics (system usage data, training completion rates, process compliance scores)
Using visualisation tools that update in real time as underlying data changes
Structuring your narrative around what the data shows, not what you think the audience wants to hear
The shift from “I believe this area is heavily impacted” to “the data shows this area has 14 concurrent changes affecting 2,300 employees over the next quarter” is transformational for credibility.
3. Analyse stakeholder impact across multiple dimensions
Heat maps typically look at change through an organisational lens: which business units are affected. But changes also affect customers, partners, subject matter experts, and communities of practice that cross organisational boundaries.
Build a multi-dimensional view of impact that includes:
Volume: How many changes are landing?
Complexity: How difficult is each change to adopt?
Duration: How long will the disruption last?
Concurrency: How many changes overlap in timing?
Cumulative load: What is the total cognitive and operational burden on each stakeholder group?
Tools like The Change Compass’s Total Impact visualisation allow you to layer these dimensions rather than reducing them to a single colour code. When a senior leader can see that the Customer Service team faces four concurrent changes of moderate complexity over the same eight-week window, the conversation shifts from “they’re amber” to “we need to reschedule one of these.”
4. Assess the pace and trajectory of change
A heat map is a photograph. What you need is a time-lapse.
Build visualisations that show how the change landscape evolves over time:
Is the volume of change increasing or decreasing quarter over quarter?
Are go-live dates clustering in ways that create bottlenecks?
Do timelines realistically account for embedding periods, or do they assume instant adoption?
Are benefits realisation milestones aligned with actual change completion, or are they aspirational?
When you can show a trajectory, you create the opportunity for proactive decision-making. A leader who sees that Q3 is trending toward saturation can act in Q2 to reschedule or resource up. A leader who sees a static red cell in Q3 has no time to respond.
5. Connect change to strategic alignment
The most mature change analytics capability does not just track what is changing and how much. It tracks whether the right things are changing.
Map your change portfolio against the organisation’s strategic priorities:
What percentage of change effort is aligned to the top three strategic goals?
Are the highest-priority strategic initiatives receiving adequate implementation runway and stakeholder communication?
Is there meaningful change effort being spent on initiatives that no longer align with current strategy?
This analysis often reveals uncomfortable truths: that 40% of the change portfolio is legacy work with no clear strategic connection, or that the CEO’s top priority has the least change management support. For practical approaches to this challenge, see our guide on how to be more strategic in managing change. These are insights that heat maps simply cannot provide.
The evolution from heat maps to dynamic change analytics
The gap between what heat maps offer and what organisations need has driven the emergence of a new category of tools: dynamic change analytics platforms.
A Capgemini change management study (2023) found that an organisation’s level of data maturity directly increases the success of its transformation efforts. The reason is straightforward: when you can see the change landscape updating in real time rather than waiting for a quarterly spreadsheet refresh, you make better decisions faster.
Modern change analytics platforms go beyond the heat map in several critical ways:
Real-time data integration. Instead of manually updating a spreadsheet, the platform pulls data from project management tools, HR systems, and survey platforms continuously.
Predictive analytics. AI models forecast where saturation is likely to occur based on historical patterns and planned change volumes, allowing proactive resequencing.
Multi-dimensional impact views. Replace the single red/amber/green cell with layered visualisations showing volume, complexity, timing, and cumulative load simultaneously.
Automated reporting. Generate stakeholder-specific views, from executive summaries to team-level detail, without manually rebuilding reports for each audience.
Scenario modelling. Test “what if” scenarios before committing to change schedules: what happens if we delay Initiative X by four weeks? How does that affect the saturation forecast for the Technology team?
Digital change management platforms like The Change Compass were built specifically to address the limitations of heat map-based reporting. If your organisation has outgrown the heat map, and most have, book a live demo to see what dynamic change analytics looks like in practice.
When heat maps still make sense
To be fair, heat maps are not always wrong. They can be useful in specific contexts:
As an initial orientation tool when a new change leader joins and needs a quick visual overview
For very early-stage change portfolio management where the organisation has no analytics infrastructure
As a simplified communication device for audiences who are not yet ready for more complex visualisations
The key is treating the heat map as a stepping stone, not a destination. If your change analytics capability has not evolved beyond heat maps in the past 12 months, that should be a red flag.
The heat map is a stepping stone, not a destination
Change management heat maps served the profession well as a first generation of change analytics. They gave practitioners a visual language for describing change impact and a tool for getting the attention of senior leaders. But the profession has moved on, and the tools need to move with it.
The five pathways described in this guide, from understanding the transformation narrative to connecting change to strategic alignment, represent a practical progression. You do not need to implement all five at once. Start with the one that addresses your organisation’s most acute blind spot, build credibility through better insights, and expand from there.
The organisations that are leading in change management today are not the ones with the prettiest heat maps. They are the ones that have graduated beyond them entirely.
Frequently asked questions
What is a change management heat map?
A change management heat map is a visual tool that displays the volume or intensity of change across an organisation, typically using colour-coded cells to indicate high, medium, or low impact by business unit or time period. While useful as a starting point, heat maps have significant limitations because they flatten complex, multi-dimensional change data into a single visual dimension.
Why are change heat maps not enough for enterprise change management?
Heat maps reduce complex change data to simple colour codes, losing critical nuance about change complexity, duration, concurrency, and cumulative stakeholder load. With the average employee now experiencing 10 planned changes per year (up from 2 in 2016, according to Harvard Business Review), the interdependencies between initiatives are too complex for a single visual layer. Enterprises need multi-dimensional analytics to make informed sequencing and resourcing decisions.
What should I use instead of a change management heat map?
Progress from heat maps to dynamic change analytics platforms that offer real-time data integration, multi-dimensional impact views, predictive saturation modelling, and automated reporting. These tools provide the analytical depth needed for informed decision-making. In the interim, you can improve your existing approach by layering dimensions such as complexity, concurrency, and trajectory into your reporting.
How do you measure change saturation?
Change saturation is measured by tracking the cumulative change load on specific stakeholder groups, including the volume of concurrent changes, the complexity of each change, the duration of disruption, and the recovery time between major changes. Modern analytics tools use predictive models to forecast saturation before it occurs, enabling proactive resequencing.
What is change portfolio management?
Change portfolio management is the practice of viewing and managing all active and planned change initiatives across an organisation as a coordinated portfolio, rather than as isolated projects. It involves analysing the combined impact on stakeholder groups, sequencing changes to manage saturation, and aligning the portfolio with strategic priorities.
How does AI improve change management analytics?
AI-powered change analytics provides real-time adoption tracking, predictive saturation modelling, automated sentiment analysis, and impact attribution. According to Prosci’s research, practitioners using AI report significantly increased efficiency and faster response times. Gartner’s 2026 study found that teams redesigning workflows with AI are twice as likely to exceed revenue goals, enabling a shift from reactive problem-solving to proactive risk mitigation.
References
Prosci (2014, updated 2025). The Correlation Between Change Management and Project Success. https://www.prosci.com/blog/the-correlation-between-change-management-and-project-success
Harvard Business Review (2023). Employees Are Losing Patience with Change Initiatives. https://hbr.org/2023/05/employees-are-losing-patience-with-change-initiatives
Capgemini (2023). Change Management Study 2023. https://www.capgemini.com/insights/research-library/change-management-study-2023/
Prosci (2024, updated 2026). AI in Change Management: Early Findings. https://www.prosci.com/blog/ai-in-change-management-early-findings
Gartner (2026). Top Change Management Trends for CHROs in the Age of AI. https://www.gartner.com/en/newsroom/press-releases/2026-3-16-gartner-identifies-top-change-management-trends-for-chros-in-age-of-ai
When a change manager joins an agile delivery team for the first time, the experience is often disorienting. Sprints end before the change plan is written. Stakeholder engagement gets squeezed between retrospectives and backlog refinement. The carefully structured approach that worked for waterfall programmes suddenly feels like it belongs to a different era. Most of the time, nobody has told the change manager what to do differently. They are just expected to adapt.
This article is about what that adaptation actually looks like. Agile is not just a project delivery methodology — it represents a fundamentally different rhythm for change, with different assumptions about how requirements evolve, how teams are organised, and how frequently stakeholders need to be engaged. Change managers who understand these differences do better work and have more influence. Those who try to map their traditional toolkit onto an agile context spend most of their time in friction.
The five principles below are grounded in how agile change management actually works in practice, not in how it is theorised in certification programmes. They are drawn from the most common challenges practitioners encounter when making the shift from waterfall to agile delivery environments.
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.
References
Project Management Institute, “Agile Change Management: Bridging the Gap”
It all begins with an idea. Maybe you want to launch a business. Maybe you want to turn a hobby into something more. Or maybe you have a creative project to share with the world. Whatever it is, the way you tell your story online can make all the difference.
Don’t worry about sounding professional. Sound like you. There are over 1.5 billion websites out there, but your story is what’s going to separate this one from the rest. If you read the words back and don’t hear your own voice in your head, that’s a good sign you still have more work to do.
Be clear, be confident and don’t overthink it. The beauty of your story is that it’s going to continue to evolve and your site can evolve with it. Your goal should be to make it feel right for right now. Later will take care of itself. It always does.
