Opening the book…
Kotter's 8-Step Change Model and Agile Adoption
Kotter's 8-Step Change Model offers another useful lens for thinking about organizational transformation. It wasn't created specifically for Agile, but it maps onto Agile adoption remarkably well, since Agile transformation depends on exactly the same ingredients this model calls out: real energy, genuine leadership, ongoing communication, and consistent reinforcement over time.
- Create urgency: build a clear, shared understanding that the current way of working isn't enough.
- Build a guiding coalition: bring together leaders, managers, and team members who can carry the change forward together.
- Form a strategic vision and initiatives: define where the organization is going and why, in terms specific enough to guide real choices.
- Enlist a volunteer army: grow adoption through belief and participation, not just compliance.
- Enable action by removing barriers: identify and remove whatever is preventing people from working the new way.
- Generate short-term wins: create visible, meaningful proof that the change is actually working.
- Sustain acceleration: keep removing barriers and deepening adoption after the first wins land, rather than assuming the work is done.
- Institute change: make the new way of working part of the culture, so it no longer depends on a few dedicated individuals to survive.
The eight steps run in sequence: create urgency, build a guiding coalition, form a strategic vision and initiatives, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, and finally institute the change. Rather than memorizing this list mechanically, it's worth understanding what each step is actually contributing to the overall success of a transformation.
1. Create Urgency
People rarely change in any deep or lasting way unless they genuinely understand why the change matters to them. Urgency in this sense doesn't mean panic or crisis messaging. It means a clear, shared understanding that the current way of working simply isn't enough anymore.
Urgency might show up as dissatisfied customers, competitors releasing faster than the organization can respond, lead times that have stretched too long, rising quality issues, burned-out employees, projects that stay late despite heavy upfront planning, slow innovation, work stuck sitting in approval queues, or teams that look busy while very little value actually flows out the other end. A good urgency message ties the need for change directly to real business and customer problems rather than abstract ideals. A weak urgency message simply says "leadership wants Agile." A stronger one says something closer to "our customers wait six months for changes that competitors deliver in weeks, and we need a way of working that helps us learn and deliver value faster."
2. Build a Guiding Coalition
Transformation can't realistically be carried on the shoulders of one Agile coach or a single executive sponsor. It needs a genuine coalition behind it, one that might include executives, middle managers, Product Owners, Scrum Masters, team members, architecture leaders, operations leaders, compliance partners, finance representatives, HR partners, and whichever informal leaders people already trust and listen to.
Middle managers deserve particular attention here, since many transformations quietly fail by overlooking them. They're often asked to support Agile without ever being told clearly how their own role is supposed to change, and they can end up squeezed uncomfortably between executives demanding transformation and teams demanding real empowerment. A strong coalition helps remove barriers, communicate the vision consistently, align policies across departments, and model the new behavior the organization is actually asking for.
3. Form a Strategic Vision and Initiatives
A transformation vision explains where the organization is headed and, just as importantly, why it's headed there. That vision needs to be clear, practical, and tied directly to value rather than left as an inspirational slogan.
A vision might focus on delivering customer value in smaller increments, reducing lead time from idea to release, improving quality through earlier testing and automation, empowering product teams to make faster decisions, shifting from project funding toward product funding, improving flow across value streams, or increasing transparency to reduce hidden risk. Whatever form it takes, a vision should actively guide choices rather than just decorate a slide. If the vision is "empower teams," governance has to change to genuinely support empowered teams. If the vision is "deliver faster," the organization has to confront dependencies, technical debt, and approval delays head-on. If the vision is "customer value," metrics need to shift toward outcomes rather than staying fixed on output alone.
4. Enlist a Volunteer Army
Change tends to spread faster when people choose to participate in it rather than feel forced into it. A volunteer army is made up of people who genuinely believe in the change and help others learn it, whether that's Agile champions, early adopters, coaches, Product Owners, Scrum Masters, technical leaders, or simply team members willing to model the new behavior in their own daily work.
This doesn't mean transformation stays optional forever for everyone. It means real, lasting adoption grows out of participation and genuine belief, not compliance alone. Communities of practice can help enormously here, whether that's a Scrum Master community, a Product Owner community, an engineering excellence community, or an Agile leadership community, each one helping learning spread across the organization rather than staying trapped inside individual teams.
5. Enable Action by Removing Barriers
Transformation tends to fail whenever an organization asks for new behavior while quietly leaving the old barriers standing exactly where they were. Common barriers include teams that aren't actually empowered to make decisions, Product Owners without real authority, too many approval gates stacked on top of each other, funding tied only to temporary projects, architecture reviews happening far too late in the process, compliance treated as a final checkpoint rather than an ongoing conversation, performance measures that reward individual utilization over team outcomes, leaders comparing teams by velocity, tools that hide work rather than surfacing it, teams overloaded with too many competing priorities, technical debt quietly slowing delivery, and dependencies left unmanaged.
Removing barriers like these is essentially servant leadership practiced at the organizational level rather than the team level. A transformation effort should keep asking a simple question: what's preventing people from working the new way? Then it should actually remove or reduce whatever the answer turns out to be, rather than just naming the barrier and moving on.
6. Generate Short-Term Wins
Large transformations take real time, and short-term wins along the way build the confidence needed to sustain that longer effort. A short-term win should be visible, meaningful, and clearly connected back to the transformation's broader vision, not just a convenient milestone picked for its own sake.
A pilot team reducing lead time by 30 percent, a product team moving from quarterly releases to monthly ones, a team improving quality through automated testing, a group cutting approval delays by involving compliance earlier, a Kanban team reducing WIP and improving predictability, a Product Owner improving stakeholder alignment through clearer prioritization, or a team using its retrospectives to actually remove a recurring blocker are all the kind of wins worth highlighting. These wins matter because they demonstrate that change is genuinely possible, and they cut down on the cynicism that tends to build up during any long transformation effort. That said, these wins should never be manufactured or declared prematurely, since claiming success too early tends to damage trust far more than it builds it.
7. Sustain Acceleration
After early wins land, organizations often relax and quietly assume the transformation is essentially complete. This is genuinely dangerous, since sustaining acceleration means continuing to remove barriers, expand learning, improve systems, and deepen adoption well past the point where the first wins felt satisfying.
The organization should keep asking what it actually learned from its early teams, what barriers still remain in place, what needs to change before expanding further, where teams are still going through Agile motions mechanically without the mindset behind them, which policies still quietly conflict with Agile ways of working, what technical practices still need strengthening, how cross-team coordination can improve, and how leaders themselves are being supported as they adapt to this new model. Transformation, at this stage, mostly requires persistence rather than any single dramatic intervention.
8. Institute Change
The final step is making the new way of working genuinely part of the culture rather than something the organization does when reminded to. This happens once Agile behavior becomes simply normal: teams raise risks early without prompting, leaders instinctively ask how to remove barriers, Product Owners make real value decisions, stakeholders expect incremental delivery as the default, finance supports adaptive funding models, governance enables responsible delivery instead of just blocking risk, metrics get used for learning rather than judgment, retrospectives lead to real improvement, technical excellence is genuinely valued, and customers stay involved continuously rather than only at the beginning and end.
The change becomes truly institutionalized once the organization no longer depends on a handful of heroic individuals to keep it alive. At that point, the new way of working survives turnover, reorganization, and changing leadership, because it's become how the organization simply works rather than a program someone has to actively champion.
Myth: Agile transformation is complete after training and tool rollout. Training and tools may genuinely start the journey, but transformation only sticks once behaviors, incentives, governance, and leadership actually change alongside them. A rollout without that deeper shift tends to fade once the initial enthusiasm wears off.
PMI-ACP Exam Connection
PMI-ACP questions may not always name Kotter directly, but they frequently test the same underlying ideas his model captures. Watch for scenarios touching on urgency, stakeholder engagement, a leadership coalition, short-term wins, barrier removal, and ongoing reinforcement, since these tend to be the recurring signals behind correct answers on transformation-related questions.
If a scenario describes a transformation that's failing, the best answer is rarely "force compliance" through stricter enforcement. It's almost always to understand the resistance first, clarify the purpose behind the change, genuinely engage the stakeholders affected by it, remove the barriers actually standing in the way, and reinforce the desired behaviors consistently over time rather than assuming a single mandate will make them stick.
This page titled 8.2.2: Kotter’s 8-Step Change Model and Agile Adoption was last modified on Mon, 31 Aug 2026 12:16:59 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Guharaman Janakiraman.
The book could not be loaded just now.