Agile Change Management

This training helps project teams and change leads apply Agile methods to manage change, adapt quickly, and deliver value incrementally.

My workspace28 minFree to watchDownloads

What you’ll learn

01Agile Change ManagementWelcome. If you lead change, or you're accountable for making transformation stick, this course is for you. We're talking about Agile Change Management. Not a faster version of a rollout plan. A values-driven, feedback-based way to lead the people side of transformation. It applies Agile principles you already use: co-creation, short feedback loops, and adaptive action. Here's the core mindset shift. Instead of managing a milestone-based rollout, you're continuously sensing and learning. You stop asking, are we on plan? You start asking, what is the system telling us, and what do we adjust next? This is a shared operating model. Change practitioners, product leaders, and delivery teams work from the same backlog, the same stakeholder feedback, and the same cadence. That matters, because most transformation failures aren't methodology failures. They're governance and coordination failures. Over the next slides, we'll cover why traditional change models strain in iterative environments, the core principles of agile change, and how to embed change work directly into your delivery cycles. So keep one question in mind for your own context. Where is your current change approach creating friction instead of flow? Let's start with why traditional change models strain in iterative environments.ijcsejournal.org core.ac.uk mdpi.com+22 min
02Why Traditional Change Models Strain in Iterative EnvironmentsLet's talk about why traditional change models strain in iterative environments. Linear models like A D K A R and Kotter assume a stable, knowable end state. But agile delivery evolves scope sprint over sprint. The target keeps moving. So change bolted on as a parallel, later-stage workstream fails fast. High-velocity releases also create change saturation and adoption fatigue. Your stakeholders can only absorb so much at once. The practitioner reframe is this. Enable absorption, not plan protection. Stop defending the original rollout plan. Start designing how people will take in each increment. That shift is where the work becomes real. Next, let's align on the core principles and shared vocabulary.ijcsejournal.org core.ac.uk mdpi.com+21 min
03Core Principles and Shared VocabularyLet's ground this in the core principles and the vocabulary we'll use throughout. First, values before mechanics. Mindset precedes process. If you install a backlog and a sprint cadence on a team that still expects top-down mandates, nothing changes. Second, co-creation beats buy-in. People who shape the change adopt the change. Buy-in is something you sell to people. Co-creation is something you build with them, and it is far more durable. Third, working solutions over documentation. Show something real sooner. In a change context, that means a solution that actually solves the problem people are feeling, not a deck describing what a solution might look like. Fourth, respond to change over following the original plan. Treat a change to the plan as useful information, not a failure. Now, our shared vocabulary. Backlog, sprint, increment, feedback loop, readiness, adoption, and minimum viable change. Minimum viable change is the smallest release that delivers real value and lets you learn. Our guiding principles: early involvement, frequent sensing, value-based adoption, and adaptive planning. Get the language consistent, and the work gets easier. Next, we'll locate change work inside agile ceremonies and artifacts.agilechange.management leanchange.org resources.scrumalliance.org+22 min
04Locating Change Work in Agile Ceremonies and ArtifactsNow let's talk about where change work actually lives inside Agile. It lives in the ceremonies. So embed change activities into sprint planning, stand-ups, reviews, and retrospectives. Use the product backlog as a visible home for change work. Capture adoption risks, communication increments, and readiness checks as backlog items. Write change items with clear acceptance criteria, just like delivery work. And position change practitioners as embedded team members, not adjacent specialists. Here's the practical lesson: if a change activity is not on the backlog, it usually doesn't get scheduled, prioritized, or resourced. So put it where the team already looks. Next, we'll look at Roles and Accountability Across Change and Delivery.prosci.com ttecjobs.com resources.scrumalliance.org+21 min
05Roles and Accountability Across Change and DeliveryLet's talk about who actually owns what. Start with the change practitioner. Your job is coach, facilitator, and feedback integrator, not just the person sending communications. If you're only producing comms, you've been misassigned. Next, the product owner owns backlog value. The scrum master guides process. Sponsors model the new behaviors and remove barriers. Transformation leads align portfolio change strategy, priorities, and adoption risk across the whole program. Now watch the tension points. Authority without ownership is the classic trap. Someone can approve a readiness decision but won't live with the outcome. Shared outcomes fix that, because adoption risk belongs in the backlog, not a separate tracker. One more thing. Small teams can run lightweight, direct patterns. Large programs need explicit decision rights and structured readiness gates. Pause here and map your own context. Who owns the readiness call, and who owns the result? Then move into building a feedback-driven change cycle.prosci.com ttecjobs.com resources.scrumalliance.org+22 min
06Building a Feedback-Driven Change CycleLet's talk about building a feedback-driven change cycle. First, stop treating stakeholder analysis as a one-time event. Replace it with continuous sensing. You need to know what people are experiencing right now, not what a spreadsheet told you three months ago. Next, adopt a minimum viable change cycle. Plan small, act, sense, and adapt. Keep it tight, so each loop teaches you something before the next one starts. Feed that cycle with evidence. Pull in adoption signals, usage data, and qualitative input every iteration. Usage tells you who is actually doing the work. Qualitative input tells you why. And frame your change activities as experiments. State a hypothesis, run it, and read the result. A fixed plan rarely survives contact with a real organization. Short feedback loops surface issues early. That is the whole point. The earlier you catch a problem, the cheaper the course correction. Get this cycle running, and the next question becomes how to read resistance as data rather than as an obstacle.agilechange.management leanchange.org resources.scrumalliance.org+22 min
07Reading Resistance as Iterative DataHere is a mindset shift worth making. Treat resistance as iterative data. That means when someone pushes back, you inspect it the same way you inspect a failed deployment. It is telling you something about usability, readiness, or your change design. Not all resistance is the same, though. Active resistance looks like open criticism or a refusal to participate. Passive resistance is quieter. Delayed responses, half-finished work, a quiet return to old habits. Then there is healthy skepticism, which asks hard questions but stays engaged. Each one needs a different response. So surface concerns early. Use retrospectives, pulse checks, demos, and direct conversations. Do not wait for a formal survey. And keep your sponsors visible. Their job is to remove blockers, not command and control. When sponsors over-direct, you get, be Agile, but do not act Agile. That is one of the fastest ways to increase resistance, not reduce it. Unless resistance becomes outright sabotage, treat pushback as evidence. Inspect it, act on it, and keep going. Next, let us look at measuring progress without creating overhead.scrum.org growingscrummasters.com toptal.com+22 min
08Measuring Progress Without Creating OverheadNow let's talk about measuring progress without creating overhead. The temptation is to track everything. Don't. Pick two or three metrics at each level. Leading indicators, adoption, and impact. Track observable behavior, not training completion or communications. Training completion proves attendance, not adoption. So if your scorecard says ninety percent trained but your backlog shows the new workflow sitting untouched, that's your real signal. There's an actual case here. A large lender trained over ninety percent of staff, but only forty-five percent of loan applications ran through the new platform. Training complete, behavior stuck. They fixed the approval rules, added short scenario training, and usage climbed to eighty-eight percent in eight weeks. Next, ladder your adoption signals to one or two business KPIs. Adoption alone is necessary, not sufficient. If cycle time and error rates improve while behavior holds, you have credible correlation. Keep dashboards lightweight. Run a weekly decision-oriented review. Not a status meeting. A decision meeting. Which blocker gets a root cause fix, what you stop doing, which two or three manager behaviors you reinforce this week. Finally, measure at thirty, ninety, and one hundred eighty days. Thirty days shows early gaps, ninety days shows sustained use, and one hundred eighty days proves the behavior stuck. Next, let's look at practical patterns for communication, enablement, and sponsorship.doi.org2 min
09Practical Patterns for Communication, Enablement, and SponsorshipLet's talk practical patterns for communication, enablement, and sponsorship. Start with content. Skip the long email newsletter. Teams need skimmable, role-based material. Release notes at the end of each sprint. Journey maps that show the before and after for a given persona. Day-in-the-life narratives that answer one question. What's changing for me? Next, replace upfront training waves with just-in-time enablement. Short micro-learning modules, delivered when people actually need them. Not six weeks before go-live. Then sponsorship. Sprint reviews and demos are your sponsorship moments. Invite leaders in, and let them give direct feedback. That is visible commitment, not a status report. Embed the change work in shared tools, dashboards, and visible backlogs. If it's not in the backlog, it won't get done. And treat communication, enablement, and sponsorship as one continuous loop. Each feeds the next. Questions from a demo shape enablement. What people learn shapes what leaders reinforce. As you apply this, watch the common missteps. Over-communicating instead of enabling. Broadcasting at people instead of inviting feedback. And treating these as three separate workstreams. Now let's look at some common change scenarios and practitioner tactics.agilechange.management leanchange.org resources.scrumalliance.org+22 min
10Common Change Scenarios and Practitioner TacticsNow let's look at common change scenarios and the tactics that actually work. Agile change isn't only about tools. It covers process redesign, restructures, and culture shifts. So the first question is always: what kind of change is this? Because your response has to match it. A system rollout is technical. You can move fast, run lightweight experiments, and expect adoption to stabilize within weeks. A culture shift is different. That takes months, sometimes a full performance cycle. Push it at rollout speed and you'll get compliance, not commitment. Here's what's reusable across all of it. Tiered communication, so stakeholders hear what's relevant to them, not everything. Just-in-time enablement, delivered the week of or before the first sprint, not months ahead. And visible sponsorship. Sponsors showing up at demos does more than any slide deck. Then rightsize the response. Low risk? Run a small experiment. High scale? Use structured waves. And match your measurement cadence to the change type, because tracking culture shifts on a thirty-day cycle will mislead you. Next, we'll look at scaling without adding bureaucracy.prosci.com doi.org2 min
11Scaling Without Adding BureaucracyLet's talk about scaling without adding bureaucracy. When a transformation grows, the instinct is to add more governance. Resist that. Scale through visible backlogs, shared cadences, and reusable canvases instead. Replace lengthy plans and slide decks with change canvases and experiment cards. These keep the thinking visible without the overhead. Track stakeholder experience using behavior-over-time views. That way you can anticipate the dip before it becomes a crisis. Make concurrent initiatives visible and sequenceable, so you can manage portfolio saturation rather than discover it late. And balance autonomy and control. Pilot locally, capture the patterns that work, then scale those. Not everything. Just what has evidence behind it. The common misstep here is mistaking activity for progress. More frameworks, more meetings, more reporting. None of that scales change. Visible work and shared rhythm do. Next, we look at starting small, with a starter change backlog and your first feedback loop.prosci.com scrum.org growingscrummasters.com+21 min
12Starting Small: A Starter Change Backlog and First Feedback LoopNow let's get practical. Start by picking one live initiative. Not a pilot program off to the side. Embed change work directly inside it. Your starter backlog is short. Adoption risks. Communications increments. Readiness checks. Write acceptance criteria as observable behaviors, not activity done. "Manager can run the new approval flow without escalation" beats "training delivered." Then choose one feedback loop. Either a weekly pulse or retrospective sensing. One is enough to start. Watch for the common slips. Too many backlog items. No named owner. And measuring training completion as if it proves adoption. It doesn't. Keep the backlog small, give every item an owner, and track behavior, not attendance. From pilot to repeatable practice.agilechange.management leanchange.org resources.scrumalliance.org+21 min
13From Pilot to Repeatable PracticeA pilot proves the change can work. Your job now is to make it repeatable. Start with a short learning review. Not a ceremony. Thirty to sixty minutes, focused on what actually happened. Then decide, using evidence, what to standardize, what to adapt, and what to stop. That third option matters most. Teams rarely kill practices that no longer earn their place. Next, distribute facilitation and feedback. Stop being the single point of change. Train people in each delivery team to run the reviews, gather feedback, and adjust locally. Then keep a short cadence to inspect and adapt the change approach itself. And here is the part teams skip. Treat the change method as something to iterate. If your rollout approach is not working, change it. That is not failure. That is the method doing its job. Coming up next, action plan and learning review cadence.agilechange.management leanchange.org resources.scrumalliance.org+21 min
14Action Plan and Learning Review CadenceLet's close with a plan you can actually run. Over the next two sprints, take on Agile Change Management as real work, not a side project. First, pull one change backlog item. Make sure it has clear acceptance criteria your team can verify, not vague intentions. Then pick one sensing mechanism: a weekly pulse or your retrospective. One is enough. Next, track one adoption metric tied to a weekly decision. If the number moves, what will you change that week? If nothing changes, it is not a metric, it is a report. Finally, set a short review cadence. Inspect results, adapt, repeat. Keep it small, keep it honest, and keep it weekly. Thanks for working through this with me. You now have what you need to start tomorrow.doi.org2 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 3.7 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 16.2 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.7 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.