Six months into most enterprise agentic AI programs, the agents are running. The CTO has presented them at the all-hands. The team that deployed them has moved on. Delivery metrics haven't moved.
The explanation that follows is almost always the same. The software development lifecycle (SDLC) needs to change. The team hasn't adjusted its process. What's needed is a transformation initiative, new ceremonies, a formal handoff from the old way of working to the new one. That reasoning sounds right and produces the same outcome. Another six months planning the transformation, and the same flat delivery numbers at the end of it.
The stall isn't coming from the SDLC. It's coming from the frame.
We call this the replacement instinct. The belief that if the old process is still running, adoption hasn't really happened. That the agents need the old process to give way before they can count. It's the frame behind most enterprise agentic AI programs, and it's why most of them stall.
The organizations moving fastest don't have better technology. They have a different question. They're not asking how to transform their delivery process. They're asking where the agents fit inside the one they're already running.
That question has specific answers. They vary by framework, but they exist in all of them.
If You're Running Scrum
Scrum is the cleanest case because the ceremonies create obvious insertion points, and most of the manual weight is concentrated in the same places across teams.
Backlog refinement is where most teams should start. Before the session, run an agent over your raw backlog to generate acceptance criteria, flag stories that are too vague to estimate, and surface dependencies the product owner hasn't documented. Engineers arrive at the meeting with better material. The session runs shorter. Estimates hold up better in the sprint. There's very little downside to trying this even in a cautious environment, and it requires no ceremony redesign.
Sprint planning is the next candidate. Agents can pull historical velocity data, dependency graphs, and team capacity to put together a recommended sprint composition before the meeting starts. The team still makes the call. The agent does the forty-five minutes of prep work that usually gets done in a hurry by whoever facilitates.
During development, the insertion point is more substantive. An engineer defines what needs to be built and what the constraints are. The agent produces implementation candidates. The engineer reviews, keeps what works, discards what doesn't. For work that follows well-established patterns, like standard endpoints, data transformation logic, and configuration scaffolding, agents can handle a large portion of the initial implementation pass. Engineers spend more time making decisions and less time typing.
Sprint reviews and retrospectives are where most teams leave time on the table. Agents can pull commit history and ticket data to draft release notes, stakeholder summaries, and retrospective documents that track patterns across multiple sprints. The 20 minutes your scrum master spends compiling that material becomes 3 minutes of reviewing a draft.
None of that is transformation. It's insertion. The process doesn't change. The distribution of work inside it does.
If You're Running SAFe or Agile-Light
Most enterprise teams aren't running textbook Scrum. Plenty operate some version of Agile mixed with SAFe or longer program-level planning cycles. The insertion logic holds across all of these. The specific points shift.
For SAFe teams, Program Increment planning is the highest-value opportunity. Teams typically spend two weeks producing the dependency maps and conflict analyses that go into a PI event. Agents can produce that material in an afternoon. The PI event starts from a different position. At the ART level, agent-assisted dependency mapping catches conflicts before the planning event that would otherwise surface as blockers during it. The format of PI planning doesn't change. The condition it starts in does.
Teams running lighter Agile processes, with sprints but minimal ceremony, usually find the easiest entry through the CI/CD pipeline. These teams are already moving fast with lean overhead, so adding agents at the tooling layer doesn't require anyone to approve a methodology change. Wire one into the PR review workflow. Add another to test generation or deployment validation. Adoption tends to stick when it comes through the developer experience rather than a top-down initiative, because developers adopt what saves them time in the work they're already doing.
Both of those assume some form of iterative delivery. A meaningful portion of enterprise software development doesn't have that option.
If You're Running Waterfall
Waterfall is alive in regulated industries. Financial services, healthcare, defense contracting, any environment where phase gates, documentation requirements, and compliance audit trails make iterative delivery contractually complicated or genuinely impractical.
The replacement instinct hits hardest in waterfall environments, because the phases are long and the distance between where agents could be helping and where they currently are is large. Teams see that distance and conclude they need to redesign the whole process before they can start. That conclusion is how agents stay in pilot for twelve months without producing anything.
The actual entry point is simpler. Waterfall phases are large and documentation-heavy, which means there's more volume of work an agent can absorb without touching the methodology at all.
The requirements phase is where to start. An agent can analyze requirements documents and flag completeness gaps, ambiguity, and anything that won't hold up as a testable requirement. Catching that problem in week two costs a fraction of what it costs to find it during testing.
The design phase is a similar story. Agents can draft architecture documents, produce data flow diagrams from system specs, and surface design patterns that fit the project's constraints. These documents take a long time to write from scratch. They're much faster to review and correct.
Testing is where most waterfall teams feel the most schedule pressure, and it's where the volume of agent-ready work is highest. Agents can generate test case suites directly from requirements documents, run regression tests without supervision, and produce result summaries that trace back to specific requirement IDs. That traceability is exactly what compliance auditors want to see, and it's usually produced manually by someone who has other things to do.
Documentation and handoff is the last area. Waterfall projects accumulate significant documentation debt. Agents can produce and maintain technical docs as a natural output of development work rather than a separate effort bolted on at project close.
You don't need to change the methodology to get value. Find the deliverables in each phase that are repetitive, follow a consistent pattern, and are currently produced by hand. Start there. That's the insertion frame applied to waterfall.
What Governance Actually Requires
Once agents are running in any of these environments, the same governance questions surface. Getting ahead of them before the first experiment is what keeps the pilot from becoming a cleanup exercise.
Human review checkpoints come first. Agents should not be pushing to production without a human in the loop. Define specific handoff points where agent output requires sign-off, and build those checkpoints into the tooling itself. If they only exist in a policy document, they won't hold.
Audit trails matter in every environment, not just regulated ones. Every agent action needs to be logged with enough context to reconstruct why it happened. You want to be able to answer “why did this occur” without having to piece it together from memory.
Scope limits are what keep the governance model manageable. Be specific about what agents are authorized to do. An agent that can write code but not merge it, that can flag a security issue but not close the ticket, is a much more contained problem if something goes wrong. Start narrow and expand as teams build familiarity with how the agent behaves.
The teams that skip this step and let scope drift are the ones that end up with governance incidents that set the whole program back six months.
The First Quarter
Most transformation programs stall between the vision document and the first actual change in how work gets done. The replacement instinct is part of why. Teams wait for the methodology to be ready before they start, and the methodology never quite gets ready.
A better approach is to treat the first 90 days as a proof of concept, not a rollout. Pick one team, one sprint, and one workflow that currently takes more time than it should. Backlog refinement and test generation are both good starting points. Run an agent on it and measure before and after on something the team already tracks, whether that's story points completed, defect escape rate, or time in code review.
Once there's something real to show, bring in two or three adjacent teams. Work out how the governance checkpoints function in practice. Document what the agent got wrong and how much correction it needed. That's the data that matters for making the case to expand.
After a quarter of this, the conversation with engineering leadership looks completely different. You're not describing an idea. You have numbers from your own delivery environment, and you got them without waiting for the transformation to arrive.
That's the insertion frame in practice. Not a methodology change. Not a transformation initiative. A question asked of each framework you already run. Where does the agent go from here?
Trackmind helps enterprises put Claude to work inside the SDLC they already run. Learn about our Claude Practice.