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

by | Agile

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

5 things Eames taught me about agile project delivery

5 things Eames taught me about agile project delivery

by | Agile, Change approach, Change Initiatives, Designing change

Ray and Charles Eames, legendary mid-century designers, developed creative processes remarkably aligned with modern agile methodologies. Their approach emphasised iteration, resource respect, and systems thinking, offering valuable lessons for today’s project teams facing complex delivery challenges.

This guide explores five key Eames principles and their direct application to agile project delivery. Change practitioners and project leaders gain practical insights to enhance iteration, stakeholder engagement, and systemic success.

What Agile Principles Did Eames Champion?

The Eames duo’s design philosophy prefigured agile concepts by decades. Their methods focused on practical experimentation, collective wisdom, and holistic systems. These are core tenets of contemporary agile delivery.

These principles translate directly to project environments, improving outcomes across technology rollouts, process changes, and organisational transformations.

1. Not Reinventing the Wheel: Leverage Collective Experience

Eames avoided starting from scratch, instead building on proven materials and techniques. Agile teams benefit similarly by tapping organisational knowledge rather than isolated innovation.

Practical Applications in Agile Delivery

  • Previous rollout lessons: Review past implementations of similar products or services to anticipate adoption challenges and success factors.
  • Stakeholder group insights: Consult colleagues experienced with specific audience dynamics and communication preferences.
  • Solution design patterns: Adapt approaches proven effective in prior technical or process solutions.
  • Timeline strategies: Apply scheduling techniques refined through previous deadline pressures.
  • Learning intervention successes: Reuse effective training content, delivery methods, and evaluation frameworks.

This principle prevents redundant effort while accelerating delivery through proven foundations.

2. Continuous Testing and Learning: Iterative Refinement

The Eames process featured constant prototyping and feedback, mirroring agile’s iterative cycles. Every team member, not just designers, contributes to this learning loop.

Change Management Testing Examples

  • Message validation: A/B test communications with target audiences to measure resonance and engagement.
  • Learning content trials: Pilot training modules with sample groups, gathering feedback on structure, clarity, and delivery medium.
  • Impact assessment accuracy: Validate change impact analysis directly with end users rather than proxies alone.

Digital tools enable scalable testing, ensuring solutions evolve toward optimal fit-for-purpose outcomes.

3. Respecting the Materials at Hand: Understand Your Resources

Eames emphasised the importance of recognising the capabilities and limitations of available resources. In agile project delivery, this means deeply understanding people, systems, processes, and stakeholder capacities.

Applying Resource Respect in Agile Projects

  • Assess team skills and system maturity before designing interventions.
  • Adapt project plans based on stakeholder readiness and local constraints.
  • Support change leads in gauging the ability levels of different groups to absorb new processes.
  • Tailor communication and training to maximise relevance and effectiveness given resource realities.

This approach builds realistic, sustainable change strategies aligned with organisational strengths and challenges.

Eames agile change management design thinking process

4. Generating New Perspectives and Ideas Through Play and Fun

The Eames valued play as a creative catalyst, fostering new ideas and fresh perspectives. Agile teams benefit from incorporating elements of play, fun, and experimentation into their work.

Practical Ways to Embed Play in Agile Delivery

  • Run hackathons or innovation sprints encouraging out-of-the-box thinking.
  • Design team-building activities that mix fun with purposeful reflection on project goals.
  • Use gamification techniques to increase engagement in learning and adoption tasks.
  • Foster a psychologically safe environment where experimentation and mistakes are accepted as learning opportunities.

Play enhances creativity, collaboration, and morale, supporting higher-quality outcomes.

5. Eventually Everything Connects: Embrace Systems Thinking

The Eames stressed seeing the broader picture and understanding how various elements interlink to form a larger system. This mindset is vital in agile delivery, where dependencies and impacts extend beyond single teams or projects.

Systems Thinking in Agile Projects

  • Map connections among processes, systems, communications, training, and branding to ensure cohesive delivery.
  • Identify how multiple change initiatives intersect and impact shared stakeholders or resources.
  • Help stakeholders understand how different initiatives support broader organisational strategies.
  • Use system maps and visualisations to support planning, risk assessment, and communication.

This holistic awareness prevents siloed work and promotes integrated, effective change.

Implementation Roadmap for Eames-Inspired Agile Delivery

Applying These Principles in Modern Projects

Quick-Start Actions for Teams

  • Conduct knowledge audits to capture previous rollout experiences across the organisation.
  • Schedule regular testing cycles for communications, training, and impact assessments.
  • Map resource capabilities and limitations during project kickoff planning.
  • Plan quarterly innovation sessions incorporating play and experimentation elements.
  • Create visual system maps showing project interconnections and dependencies.

Building Organisational Support

  • Train change leads in resource assessment and systems thinking techniques.
  • Establish cross-project knowledge sharing forums.
  • Integrate Eames principles into agile training and certification programs.
  • Use success stories to demonstrate ROI from iterative testing and collective learning.

These steps embed timeless design wisdom into contemporary delivery practices.

Cultural Considerations for Success

Overcoming Common Barriers

Success requires psychological safety for experimentation and leadership support for non-traditional approaches. Traditional organisations may resist play-based innovation, requiring champions to demonstrate tangible benefits first.

Scaling Across Teams

Start with pilot projects showcasing measurable improvements in delivery speed, stakeholder satisfaction, and adoption rates. Use these case studies to expand practice organisation-wide.

Measuring Impact

Track metrics like iteration cycle time reduction, stakeholder engagement scores, knowledge reuse rates, and cross-project collaboration frequency to validate principle effectiveness.

Frequently Asked Questions (FAQ)

What makes Eames principles relevant to modern agile delivery?
Their focus on iteration, collective wisdom, resource respect, creativity through play, and systems thinking directly addresses contemporary project complexity and delivery challenges.

How do you implement continuous testing in change management?
Use A/B testing for messages, pilot training modules with user groups, and validate impact assessments directly with end users to refine approaches iteratively.

Why is systems thinking essential in agile projects?
Modern initiatives rarely operate in isolation. Understanding interconnections prevents siloed work and ensures cohesive delivery across multiple changes.

How can teams incorporate play into serious projects?
Run hackathons, gamify learning tasks, and design team activities blending fun with purposeful project reflection to boost creativity and morale.

What is the first step in applying ‘not reinventing the wheel’?
Conduct knowledge audits capturing previous rollout lessons, stakeholder insights, and proven solution patterns across the organisation.

Read our ultimate guide to agile for change manager.

—————–