When most agent-assisted software development lifecycle (SDLC) transformation programs fail, the cause has nothing to do with the technology. It shows up three or four months in, when:
These are all change management problems, but they are rarely recognized as such until the damage is already done. No single change management methodology was built to address a scope that broad.
This paper proposes an approach that brings together three models, each designed for a different job.
Each approach fills a gap that the others leave open. Getting all three to work together is harder than it sounds, but that is the actual work. All three frameworks run throughout the transformation; what shifts is where each one carries the most weight.
Agent-assisted software development is different from the technology rollouts that came before it, although that comparison only gets you so far. Earlier implementations layered a tool on top of an existing process. You learned the tool, and you kept doing your job the same way. Agentic development changes the shape of the work itself, and the effects reach into every phase of the software development lifecycle (SDLC).
Code review is the first place most teams feel the difference. When a pull request was authored by a model with no understanding of organizational context or technical debt, the usual criteria don't quite fit. Testing follows the same pattern.
Agents can produce hundreds of test cases overnight, but separating out the noise and finding the cases that cover meaningful edge conditions requires judgment that no tool supplies. Requirements gathering also shifts, because stories are drafted in seconds but validating business intent still requires someone who knows the domain.
All of that adds up to operating model change, not tool adoption. Programs that treat them the same will stall.
Resistance also looks different here than in previous technology waves. Agentic coding triggers a question that earlier tools never raised, and it's one people rarely say out loud in meetings. Instead, it shows up as silent avoidance, minimal compliance, or unsafe workarounds like pasting sensitive data into public models.
Users need something concrete: A clear picture of what their role will look like afterward, what new skills they'll build, and a place to practice before anyone expects them to perform. Without that, fear fills in the gaps.
One other consideration is worth mentioning. An agentic development competency is perishable. Prompts, models, and best practices evolve quickly. Without a reinforcement engine built into your change program, adoption will be uneven, productivity gains will plateau once the initial excitement fades, and it will be a struggle to scale beyond the early adopters.
The change management work continues past go-live, and that ongoing investment is what keeps the wheels turning.
No single change model was designed to handle every dimension of an agentic development transformation. That's not a criticism — they each do something well. However, each has blind spots that become obvious the moment you try to run the entire program with just one change model.
Kotter’s change model builds the organizational conditions that make change possible at scale. Urgency is grounded in real competitive pressure, and a guiding coalition is formed that reaches past the C-suite and includes the engineering managers and principal architects who control how code gets written and merged. Kotter also requires a vision concrete enough to change how teams show up to planning meetings.
That foundation matters, but it also stops at the team boundary. Getting an individual developer to move from skepticism to competence is a different problem, and Kotter wasn't built to solve it.
That’s where ADKAR comes into play. Its sequence is granular by design, moving from awareness of what’s changing in a specific role, through desire to make that change rather than tolerate it. It provides knowledge of how to work differently, and reinforcement that keeps new behaviors from reverting once the project team moves on.
In an agentic SDLC context — where the fear of role replacement is real and often unspoken — that sequence is the difference between a program where people change and one where they comply.
What both frameworks leave open is the operational question. Even with aligned leadership and willing developers, someone has to determine what the future-state SDLC actually looks like.
Where do agents generate software, and where do humans evaluate? What does code review look like for a pull request that no human fully wrote?
Those are design questions, and operational change management (OpCM) is designed to answer them. Without that layer, you end up with willing people and real strategic alignment pointed at a process that wasn’t built for them.
Coordinating three frameworks adds real complexity, and not every organization needs the full weight of all three from day one. For agent-assisted software development at an enterprise scale, this combination is what closes the gap. Not because it is elegant, but because the gaps are real — and the price of failure is a pilot that never scales.
Kotter's model moves an organization from inertia to committed action, and it has a very specific job in an agentic SDLC transformation: Get leadership to stop treating this as a tool experiment and start owning it as an operating model change.
Figure: The Kotter 8-Step Change Model
Programs that stay in tool experiment mode get piloted, generate some enthusiasm, then quietly get shelved. When leadership treats the change as an operating model decision from the start, they get resourced, governed, and scaled.
Urgency must be grounded in the metrics that engineering leadership watches:
When a leadership team sees that competitors using agent-assisted coding are increasing sprint commitments by 20%, or that their own teams spend 35% of their time on boilerplate an agent could draft in minutes, the conversation shifts — from whether to act to how fast they can move.
Vague urgency about staying competitive doesn't move engineering organizations. The numbers do.
That urgency must be channeled through the right coalition, which in an SDLC context means more than executive sponsors. Engineering managers set team norms. Principal engineers control what gets merged. Security and compliance leaders define what safe deployment looks like.
If those people aren't aligned, adoption stalls at a team level, regardless of how much executive support exists at the top. This is not conjecture, but based on observations from real-world scenarios.
In one instance, delivery teams were posting real productivity gains with agentic coding, but adoption had flatlined. Unfortunately, the principal engineers on the architecture review board had not been asked to be part of the coalition championing the change.
They kept running the old playbook, and every agent-assisted code commit received the same scrutiny as a junior developer's first day on the codebase. Consequently, three months of productivity data were sitting in a queue.
The vision step gets shortchanged more than any other, and engineering teams feel the difference. For a developer who has spent years writing boilerplate, it must be clearly communicated that their everyday tasks will be replaced by architectural decisions and complex problem solving that requires actual judgment.
A QE engineer needs the same concreteness, not a general message about how AI agents will transform quality work. They need a clear view of what a sprint will look like: the baseline regression suite already exists before they start, and their time will be spent on exploratory testing that nobody can automate.
A good way to test this is whether someone can picture it in next week's planning meeting. Generic transformation messaging rarely passes that test.
Urgency, coalition, and vision are not three separate steps that happen to follow each other. Together, they build the executive alignment that everything downstream depends on.
It is more than top-level support. It’s a leadership structure that has felt the competitive pressure, organized itself around the SDLC change, and agreed on what a transformed engineering process looks like. Programs do not recover from failing these first three. Everything built afterward rests on this foundation.
Building the right organizational conditions is only half the job. What's left is harder, and it plays out one person at a time. An architect reviewing a pull request that no human fully wrote isn't just applying existing criteria differently. They're developing new ones, without a clear model for what good looks like yet.
A product owner validating AI-drafted stories rather than writing them is in a similar position. ADKAR provides the structure for moving each person through the change without losing them at each milestone.
Figure: The ADKAR Model
The message that actually lands is specific to the workflow change, not the tool. "We're rolling out new tools" tells engineers nothing and leaves them to fill in the blanks, which leads to assumptions about job security and organizational intentions.
A QE engineer needs to know that test authoring is shifting, that their judgment is more valuable than ever, and that the manual scripting work that consumed three days per sprint is coming off their plate.
When awareness is built around specific workflow changes and not the tool itself, people understand what they're being asked to do, rather than what they might be about to lose.
Desire is where most agentic software development programs consistently fail. Leadership announces a productivity initiative, frames the change around efficiency and throughput, and then wonders why engineers comply without committing.
The problem is that efficiency is an organizational benefit. It doesn't answer the question every engineer is grappling with — whether the skills they spent years developing still matter when AI agents are doing part of the work. The answer must be “yes,” and it needs to be specific.
For QE engineers, the case is that broader automated coverage frees them for exploratory testing and strategy work that is more demanding than another sprint of regression scripting.
Developers hear a version of the same answer, with the scaffolding and boilerplate coming off their plate so more of their time goes to architectural decisions and problems that need senior judgment.
When the change is framed right, this shift can happen in a matter of weeks. If leadership’s message is about productivity targets instead of role enrichment, it could take six months. The outcome is very dependent on that first conversation.
Most programs budget for tool training and call it knowledge transfer, which gets the mechanics across but misses most of what the role change actually requires. Teams need to understand how to prompt for their specific codebase, how to evaluate agent-assisted output during code review, how to design test strategies that start with AI-generated suites rather than build from scratch, and how to validate AI-drafted acceptance criteria before a story enters a sprint.
They need to know where the model is likely to produce something that looks right but isn't. In a code context, that means:
None of that knowledge comes from vendor demos or one-hour overviews. It requires structured training built around the actual tech stack and the specific failure patterns agentic development produces in their environment. Not every organization wants to hear that. It's the work.
Awareness, desire, and knowledge are where individual readiness gets built. Once everyone understands what is changing in their specific role, wants to make that change, and knows how to work differently, the individual preparation work is done.
What comes next — ability and reinforcement — require something training can't provide. They need a redesigned operation, one where the environment is built to expect the new way of working, rather than tolerate it. That's what Operational Change Management (OpCM) addresses.
OpCM in an agentic software development transformation is a design problem before it's anything else. Where agents generate code and where humans evaluate. Where the handoffs happen. What governance covers agent-generated artifacts. What it takes to sustain that new workflow at business speed.
Executive alignment and individual readiness are both necessary conditions, but they don't answer the key operational question: What the process will look like when people are ready to work differently. That's what this layer builds, and it's what keeps the transformation improving after the project team is gone.
Whether the redesigned SDLC works once you turn it on is the only question that matters before go-live.
If those questions don’t have solid answers, you’ve designed an experiment, not an operation.
The work starts with mapping the SDLC from outcome to origin and asking what each step looks like when agentic coding is a core capability rather than an add-on. Requirements gathering changes, story refinement changes, and the definition of what a developer produces in a sprint changes. Code review changes because the artifact being reviewed was authored in part by a model, and evaluating it requires different criteria than evaluating hand-written code.
Testing is where it gets dramatic. The economics of test generation shift so far that the entire QA strategy must be rethought. Most organizations skip this redesign. They graft coding agents onto the existing SDLC and wonder why the gains stay marginal. The process was designed for a world where humans authored everything. It wasn't built for this.
What follows from process redesign must be explicit, because role shifts that are not fully explained are a sure-fire way to create sprint confusion.
Developers have moved from primary authors to evaluators and editors of AI-generated code. That may sound like a small distinction, but most transition plans underestimate how long it takes for teams to feel the difference in how they approach a pull request, or what a productive day looks like.
Product owners are working through the same kind of shift, validating AI-drafted stories with their domain expertise rather than writing them, and what a productive refinement session looks like changes with it.
Each of those changes must be named, documented, and reflected in how work gets assigned, reviewed, and measured. Organizations that leave it implicit end up with role confusion inside sprints, and the cycle time numbers don’t move the way the project plan said they would.
Flow engineering is where programs often get their biggest surprise. Accelerating code generation without mapping the downstream queue is like widening a highway on-ramp that feeds into a one-lane bridge. Faster entry, same bottleneck.
The queues, dependencies, and handoffs that were invisible in the old process are still there. It’s common for teams to cut their code generation time by as much as 60%, then spend three weeks wondering why their cycle time hasn't moved.
In one instance, the answer was sitting in a Jira board that nobody had looked at. The review queue had absorbed every minute the team had saved. If AI can generate test suites in minutes but the review queue adds three days of wait time, all you've done is shift the bottleneck downstream and give it a different name.
Old governance controls are another quiet killer. The instinct is to layer more approval steps on top of AI-generated artifacts — which seems reasonable until you realize the new SDLC is slower than the one it replaced.
Redefining the control framework means asking which approval steps exist because the risk genuinely requires them and which exist because the old process assumed human authorship at every stage. Agent-assisted code that has passed automated quality gates, security scans, and peer review may not need the same multi-level sign-off that hand-written code did under a different risk model. Getting governance right enables velocity without compromising the controls that matter. Most programs don't figure that out until they've already built the slower version.
The metrics for the redesigned operation have a clear shape, and wiring them into the sprint dashboard before go-live is where most programs slip.
These metrics tell you whether the redesigned SDLC is performing better or just moving faster with more defects accumulating downstream. If those numbers aren't in the sprint dashboard, you're not managing the new operation. You're watching it.
Before you scale, prove it works under real sprint conditions with real teams and real delivery pressure. Then, build continuous improvement into the sprint cadence through retrospective metrics, prompt library updates, bottleneck reviews, and model capability assessments as the underlying technology changes.
Many transformations fall apart at this point. The project team declares success at go-live and moves on. An SDLC redesigned around agent-assisted development has a different finish line. It's ready when it can run, improve, and adapt without the people who built it in the room. That bar is higher than most project plans account for.
Kotter, ADKAR, and OpCM don't hand off to each other. All three run from the start of the transformation to the end. It’s only the composition that shifts: Each change model does the heavy lifting at a different point during the program.
Early on, Kotter commands most of the attention, and for good reason. Three of the eight steps center on executive alignment. That can feel like a lot of overhead before any tool reaches a developer’s hands, but urgency, coalition, and vision must exist when the transformation starts or be rebuilt later at great cost. They determine whether anything downstream gains real traction or moves only on paper.
Once the organization is pointed in the right direction, people start asking what this change means for their job. Within ADKAR, awareness, desire, and knowledge are where the readiness work lives. People need to understand what's changing and why, want to get there, and know how to work differently. Skip any one of those and adoption stalls in ways that are hard to diagnose, because on the surface everything looks fine until it doesn't.
If there's one place that transformation programs underestimate the work, it's the process design, the governance model, and the metrics that tell teams whether they're winning. These are the aspects that OpCM must get right from the start. They may not feel consequential in week two of a transformation, but by month six — when teams are either running inside a process built for them or fighting one that wasn't — those decisions are all that matter.
Done right, the foundation doesn't just support the new way of working. It gets faster over time. As individuals build competence and new behaviors take hold, the early investment starts compounding. By the later phases, the work has shifted from building to accelerating, and that's where OpCM dominates. Not because the challenges get harder, but because a process designed for continuous improvement keeps delivering returns long after the alignment and readiness work is done.
You can see it coming months before anyone says so. The gap shows up between what the adoption dashboard reports and what the codebase shows. The architects are still running the old review process, because nobody brought them into the coalition when it mattered. The developers stopped opening the prompt library not long after the training session, and the conversation about why belongs to no one in particular. That’s what it looks like when an operating model transformation is treated like a tool deployment.
The organizations that get past the pilot phase treat change management as part of a larger enterprise agentic strategy, not as a communications plan bolted on after the tools are chosen. They build executive alignment before the first tool is deployed, move people through the readiness milestones rather than assuming training covers it, and redesign the operation so there’s a process waiting when people are ready to work differently.
That last part sounds simple. It isn’t.
The scope of an agent-assisted SDLC transformation is wider than most programs plan for, and the part that surprises teams is never the technology. It's the depth of the operating model change underneath it.
No single model covers the entire scope of change, which is why we propose combining three. The enterprises that skip the underlying work will keep running pilots that look promising and are never rolled out to their teams.
Those that embrace this three-tiered approach and understand when to rely on each change model will be less likely to experience the unwelcome surprise of a failed transformation.
Global Behavioral Change Management Lead
Chris Murphy is Coforge's Global Behavioral Change Management CoE Lead. He brings 40 years of IT experience, 18 years of Agile experience, and 12 years of Organizational Change Management experience to his work with clients. Chris started his AI journey in the mid 1990s, using Bayesian Belief Networks with Genetic Algorithm optimizers to predict persistent patterns in financial data. Chris holds SAFe Program Consultant and Certified Scrum Product Owner certifications. He led the Global Agile Center of Excellence at Mindtree before joining Coforge. Clients know him for asking the right questions and turning their needs into action that delivers real business value.