I wrote recently about how AI-assisted development is reshaping the software development lifecycle. Specs are becoming the primary artifact, validation is becoming continuous, and implementation is collapsing from weeks to hours.

That led to an interesting question in the comments: if the SDLC is changing this dramatically, what happens to Scrum?

My short answer on LinkedIn: probably not in the form most teams practice today. This post expands on that with a bit more reflection and some predictions.

Death to Scrum: parody of the Death to Smoochy movie poster

(With apologies to Death to Smoochy; all rights belong to their respective owners)

What the original Agile Manifesto got right

In 2001, seventeen software developers met at Snowbird, Utah and wrote a 68-word document that reshaped how we build software. The Agile Manifesto valued:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The important thing is that these were principles, not procedures.

I believe that the manifesto and the twelve principles behind these values still hold up: continuous delivery of valuable software, welcoming change, sustainable pace, technical excellence, self-organizing teams, and regular reflection. The core insight still holds: teams doing uncertain work need fast feedback loops.

Scrum is what got built on top

Over twenty-five years, "agile" became Scrum, Scrum became ceremonies, ceremonies became calendar invites, and calendar invites became overhead. Most engineering teams today practice some version of Scrum: sprint planning, daily standups, sprint reviews, retrospectives, story point estimation, velocity tracking, burndown charts, backlog grooming.

The original manifesto warned about this in its first value, individuals and interactions over processes and tools. The warning did not survive contact with enterprise project management.

This is not a screed against Scrum, which I have been guilty of in the past. Scrum solved real problems. It was an implementation strategy optimized for the economics of software development in the early 2000s: expensive engineering capacity, slow feedback loops, difficult deployments, and limited visibility into work. It gave teams a regular cadence, made work visible, and created accountability without micromanagement. For a generation of engineering teams, it was a meaningful improvement over what came before. The question is whether the conditions that made Scrum useful still hold.

What Scrum was actually for

Most of Scrum's machinery exists to manage handoffs and coordinate scarce engineering capacity.

  • Sprint planning exists because humans cannot reliably predict how long work will take. Story points and planning poker were never really about precision. They were social tools for surfacing disagreement and forcing conversations about uncertainty.
  • Standups exist because work is distributed across people who cannot see each other's progress. The ritual creates a forced synchronization point to surface blockers early.
  • Sprint reviews exist because product, engineering, and stakeholders do not have a shared view of what is being built. The demo is the moment of truth.
  • Retrospectives exist because teams need a structured space to examine their own process, away from the pressure of delivery.
  • Backlog grooming and triage exist because issues enter the system in inconsistent shape and someone has to do the work of reading, refining, and routing them.
  • Sprint metrics like velocity, burndown, and cycle time exist because leadership needs predictability and visibility into work that is otherwise opaque.

Each of these solved a real problem: coordinating between humans is expensive, and software organizations evolved processes to manage that cost.

What changes when agents enter the system

AI tools change the underlying conditions:

  • Mechanical implementation capacity is becoming dramatically less scarce. Translating requirements into working software increasingly takes hours instead of weeks. The bottleneck shifts from writing code to deciding what should exist, validating it, and safely operating it. The constraint is no longer "how do we maximize the throughput of our limited engineering team" but "how do we ensure what gets generated is correct, safe, and worth shipping."
  • Estimation is becoming vestigial. When implementation collapses to hours, the question is no longer "how long will this take" but "is this worth doing" and "is the spec good enough to execute against." Story points are an answer to a question we are no longer asking.
  • Handoffs are being absorbed into agents. Triage, grooming, routing, and even initial drafting can be done by agents that have access to customer feedback, internal context, and the codebase. Linear is already building for this with Intake and the broader vision they describe for issue tracking: support tickets, Slack threads, and customer call transcripts can be auto-converted into well-scoped issues, deduplicated, routed, and labeled. It does not eliminate product thinking or engineering judgment, just the procedural translation work. The triage meeting becomes optional.
  • Coordination overhead changes shape. Teams still need architectural alignment, operational ownership, security review, and prioritization. What shrinks is the amount of procedural synchronization required just to keep implementation moving.
  • Sprint cadence is increasingly arbitrary. Two-week sprints made sense when shipping was hard. When deployment is continuous and validation is automated, the sprint boundary increasingly becomes a calendar artifact rather than a delivery constraint.

The original manifesto is not wrong, but the rituals that grew on top of it were optimized for a constraint that is dissolving.

A new manifesto?

If we wrote the Agile Manifesto today, knowing what we know about AI-assisted development, the values would not change much. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

The manifesto ages surprisingly well, but the Scrum workflows built around it do not:

  • Specs and intent over tickets and stories. When code can be generated in minutes, the scarce thing is the precise description of what to build. Engineering judgment moves from implementation to specification.
  • Continuous flow over sprint cadence. When work moves at the speed of agent throughput and validation is continuous, fixed sprints become less meaningful as the primary unit of planning and delivery. The discipline shifts from "what fits in this sprint" to "what is worth doing now and what does done look like."
  • Validation and safety over raw throughput. As implementation accelerates, the bottleneck increasingly shifts to testing, review, security, observability, and release confidence. The challenge is no longer generating code quickly, but ensuring what gets generated is correct, safe, maintainable, and production-ready.
  • Outcomes over velocity. Velocity measures how much a team produces, which made sense when production was the bottleneck. The new bottleneck is whether what gets produced is correct, useful, and shipped. Track outcomes, not output.
  • Human judgment over human throughput. When agents do more of the procedural work, the human contribution shifts toward intent, taste, judgment, and accountability. The team structure that made sense for human throughput does not necessarily fit a world where one engineer with strong domain knowledge and good agent orchestration can often execute work that previously required multiple coordinated implementation roles.

How do we evolve the engineering team toward this?

Gradual evolution

The shift will likely not happen all at once, and most teams will resist it for the same reason most teams resisted agile in 2003: the existing process is what they are comfortable with, and the new one is unfamiliar and unproven. Given this, some practical changes that could work and are not too disruptive:

  1. Start with intake, not sprints. The most leveraged early change is automating triage and intake. Agents can convert support tickets, Slack threads, and customer calls into well-scoped issues with the right labels and routing. This reduces the meeting load immediately and proves out the pattern that agents can do procedural work well.
  2. Replace estimation with prioritization. Stop running estimation rituals. Instead, ask two questions for each piece of work: is this worth doing, and is the spec good enough that someone (human or agent) can execute against it. If the answer to either is no, the work is not ready. Story points add no information that a yes/no on these two questions does not already provide.
  3. Make (most) standups async. The daily standup is the easiest ceremony to retire. Replace it with an async update from issue tracker activity. Keep a weekly sync for things that genuinely need synchronous discussion (architecture, blockers, customer issues), and let the rest happen through writing.
  4. Treat the spec as the artifact. Code review will not scale if the team is generating ten times more code. The leverage point moves earlier in the process and spec review becomes the new code review. The questions the spec review should answer:
    • What behavior are we expecting
    • What are the important edge cases
    • What non-functional constraints matter (e.g. security, reliability, performance)
    • How will we know the result is correct
    An engineer and a PM should align on this before any code is generated.
  5. Keep sprint reviews, but reframe retrospectives. Demos still matter: showing working software to stakeholders and customers is one of the most valuable things a team does. Keep those. Retrospectives also matter, but the focus shifts from "how did our process work" to "what should change in our process." Use retros to question the rituals themselves, not just refine them.
  6. Be deliberate about which ceremonies to keep. Retiring all of Scrum at once is a bad idea. Some ceremonies serve a real purpose beyond coordination, especially as a team is learning to work this way. Keep the ones that do, and gradually drop the ones that have become routine. The test should be simple: if the meeting were canceled, would anything actually break?

Metrics for the new world

The old Scrum metrics measured human throughput inside a fixed cadence. They are mostly the wrong metrics now.

The metrics that will survive the transition are the ones tied to outcomes and flow:

  • Lead time i.e. time from idea to production. This is the most important metric: as you compress the SDLC with AI tooling, lead time should shrink visibly. If it is not shrinking, what you are doing is not delivering value at the pace it should.
  • Cycle time from in-progress to done, per piece of work. This is useful for finding bottlenecks. If cycle time is going up while lead time is going down, work is sitting in queues somewhere (most commonly: in review).
  • Defect escape rate. Bugs found in production divided by bugs found before production. As code generation accelerates, this is the canary metric for whether your validation is keeping up.
  • Spec quality. This is harder to measure quantitatively, but observable: how often does work get rejected at spec review, how often does generated output need significant rework, how often does a finished feature not match the original intent. These are leading indicators of whether the team is treating the spec as the primary artifact.
  • Time to validate a hypothesis. From "we think users want X" to "we have evidence one way or the other." As prototyping gets faster and feedback loops tighten, this number should shrink dramatically. If it is not shrinking, you are using faster tools without faster thinking.
  • Validation latency. Cycle time measures total time in progress. Validation latency measures specifically how long work waits in testing, review, security checks, and deployment validation queues before it is trusted enough to ship to production. As code generation accelerates, this is where most of the cycle time will live.
  • Customer-reported issues per release. This is an old metric, but it is still valuable, and is the ultimate test of whether faster shipping is also better shipping.

The metrics to retire or deprioritize:

  • Velocity assumes humans are the bottleneck and story points are the unit of throughput: both of which are decreasingly true.
  • Sprint burndown assumes a fixed sprint boundary, which is increasingly artificial.
  • Planned-to-done ratio measures how good a team is at predicting work in a sprint, which matters less when sprints are less rigid.

These metrics measure the wrong layer: they tell you how predictable your sprint is, not whether you are building the right thing or shipping it well.

Principles, not procedures

The Agile Manifesto's four values and twelve principles will survive intact. The principles translate, but the Scrum procedures built on top of them won't. These were tools optimized for a world where implementation throughput and human coordination were the dominant constraints. As those constraints dissolve, the tools become overhead.

The original Agile Manifesto came out of frustration with waterfall. The next evolution will come from teams who realized parts of Scrum had become ceremony for ceremony's sake and started adopting workflows that better match how software gets built with AI-assisted tools.

Right now, most teams are layering new tools onto old processes. What you get is a faster version of the same process, not a different one.