Scrum Was Never the Point: Agile After AI

Asking whether Scrum is still valid in the age of AI is the wrong question. Scrum was never valuable on its own. It was a tool built to solve a specific problem, and AI has moved that problem somewhere else.

If your team is asking the question at all, the ceremonies have probably already drifted away from how the work really gets done. The useful question is narrower: which parts of the process still match where the work gets stuck, and which parts are now just ritual?

The bottleneck moved

Scrum and Agile grew up when writing software was slow and expensive and requirements were unclear. Short iterations kept a team from spending six months building the wrong thing. Every ceremony was tuned to that world: estimate human effort, commit to what people can build in two weeks, then check in daily on who is blocked.

AI coding tools have made the writing step far cheaper. They have not made it cheaper to decide what to build, review what was built, or prove it is correct. A feature an agent drafts in twenty minutes can still take two days to review, test and get through deployment.

Get Marinus Greyling’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So the constraint has shifted:

1. Before: writing the code was the slow part.
2. Now: deciding what’s wanted and verifying what came out are the slow parts.

A process built around the first constraint will measure the wrong thing once the second one takes over.

What still holds

The Agile Manifesto’s core ideas matter more now, not less. If you can produce code ten times faster, you can also build the wrong thing ten times faster. Tight feedback is the only defence against that.

• Short feedback loops. Get working software in front of the people who use it, fast and often.
• Working software over documents. AI makes producing plausible-looking output cheap. Running software in a real environment is still the only honest proof.
• Close collaboration with the customer. When building is cheap, the scarce skill is knowing what’s worth building.
• Retrospectives and reviews. They exist to help the team learn, not to push throughput up. That purpose hasn’t changed.

What’s breaking

Scrum’s mechanics were sized around human output, and that is where they’re starting to fail.

• Story points and velocity. Points estimated how hard work was for a person to build. When an agent writes the code and a human spends most of the time reviewing it, the estimate is measuring the wrong step. Velocity charts drift away from reality while still looking healthy.
• Fixed two-week sprints. When much of the work can be done in hours, a two-week commitment window adds waiting time instead of reducing risk. Work sits finished but unreleased because the sprint isn’t over.
• Daily stand-ups. They were for spotting blockers between people. With agents doing chunks of the work, the useful question is “what is waiting for review or a decision?”, not “what did you do yesterday?”
• Sprint commitments. Committing to a set of stories assumes building is the hard part. When building is cheap and verification is not, the commitment is a guess about the wrong thing.

What to do instead

Keep the Agile principles and loosen the Scrum mechanics. Build the process around the step where work actually waits.

1. Size work by how hard it is to verify, not to write. Ask how long it will take to be confident the change is correct: the review, the tests, the edge cases, the data. That number is your real estimate.
2. Make the review queue visible and limit it. Give review and verification their own columns on the board, with work-in-progress limits. If the review column is full, nobody starts new work. They help clear the queue.
3. Move to flow, keep the rhythm. Swap sprint commitments for continuous, Kanban-style delivery. Keep a regular cadence for reviews with stakeholders and for retros, because learning still needs a rhythm.
4. Measure cycle time, not velocity. Track how long work takes from idea to production, and where it waits. That shows where the constraint really sits.
5. Put humans where judgement matters. Clarifying intent, reviewing design, owning correctness. The agent writes; the engineer decides and verifies.

Where it bites hardest: data work

Database and data work shows the shift most sharply. AI-generated SQL that compiles is not the same as SQL that’s correct on your production data. Replication setups, compatibility-level behaviour, skewed data and old edge cases are exactly where generated code fails, and it fails quietly.

A query that returns plausible numbers looks done. Finding out whether it’s correct means checking it against real data, real volumes and real downstream consumers. That check is the expensive step, so it should be the step your process is built around.

The risk of standing still

Teams that keep the old ceremonies as they are will look productive. Velocity will climb, and the board will move. Behind it, untested AI output builds up in a review step nobody is tracking, until it shows up as a production incident.

Agile is still valid. Scrum, applied by the book, is increasingly measuring the wrong thing. Start with one question for your team: where does work wait the longest today: writing, review, testing, or waiting for someone to decide what’s wanted? The answer tells you which parts of Scrum to keep.