Agile Was Right for 2001. It’s Wrong for 2026.

Agile didn’t fail. The problem it was designed to solve simply changed. And the methodology never caught up.

Ben Sutherland · May 2025 · AI / Product Management

The Problem Isn’t Your Team. It’s Your Abundance.

Agile’s entire premise was built on scarcity. The scarcity of developer time. The scarcity of iteration cycles. The scarcity of feedback. Every mechanism in Agile — sprints, story points, velocity tracking, prioritization — was designed to make hard decisions about what to build when there wasn’t enough capacity to build everything.

That scarcity is gone.

Prototyping that used to take a sprint now takes an afternoon. Features that would have required a dedicated developer can be scaffolded in hours. The cost of making something has dropped so dramatically that developer time is no longer the limiting factor. You can now generate more features than your team can humanly evaluate, decide on, or maintain.

The old forcing functions — the ones that kept teams focused simply because building was hard — no longer apply. Agile’s self-limiting mechanisms were always downstream of that scarcity. Remove the scarcity and the mechanisms lose their teeth.

“Agile’s self-limiting mechanisms were always downstream of scarcity. Remove the scarcity and the mechanisms lose their teeth.”

The Shiny Object Problem Is Not What You Think

When people talk about shiny objects, they usually mean new tools or frameworks that distract teams from the work. That’s real, but it’s not the version of the problem that AI creates.

The AI version is more seductive. You ask a model to build a feature. It builds what you asked for — and then produces something adjacent. Something you didn’t request, didn’t plan for, and didn’t budget. Something genuinely impressive. And because it cost essentially nothing to produce, the temptation to keep it is almost irresistible.

This is scope creep that arrives not from ambition but from abundance. The feature didn’t grow because someone got excited and overbuilt. It grew because the model was generous and the team didn’t have a fast enough reflex to say no.

The Real Shiny Object Problem: It’s not distraction by new tools. It’s AI output that’s adjacent to what you asked for, impressive enough to keep, and misaligned enough to cost you later. Free-to-generate does not mean free-to-maintain.

Commandments, Not Bibles

Every product has two kinds of documentation. The first is the short list of what the product must achieve — the strategic and business outcomes it exists to deliver. These are the commandments. They should fit on one page. They should be impossible to misread.

The second is everything else: design specs, architecture decisions, feature documentation, process artifacts. This is the bible. It accumulates fast. It goes stale faster. And in most teams, it becomes the authority — the thing that gets defended, cited, and protected — while the commandments drift quietly into the background.

The methodology error most teams make is protecting the bible and letting the commandments erode. When that happens, the product stops being guided by outcomes and starts being guided by inertia. Features survive not because they serve the product’s purpose but because they’re documented, they’re built, and removing them would require updating the bible.

Flip the relationship. The commandments are load-bearing. The bible is disposable. Everything — every feature, every process, every sprint ceremony — gets evaluated against the commandments, not protected by the documentation.

A Feature Hierarchy Built for Abundance

Not every feature needs the same relationship to the commandments. What teams need is a clear and explicit hierarchy so that everyone on the team — at any point in development — knows the status of what they’re working on.

Core

These features directly express a commandment. Removing them would change what the product fundamentally is. They are never provisional. They are defended first.

Additive

These features improve the product without redefining it. They are aligned with the commandments but not load-bearing. They stay as long as they don’t interfere with core.

Experimental

These features — including the adjacent outputs AI generates unprompted — are on probation. They have a place in the product conditionally. A new experimental feature is provisional until it has proven its alignment with the commandments under real conditions. The psychological default shifts from “how do we justify removing this?” to “has this earned its place?”

Make the hierarchy explicit in every planning conversation. When evaluating what to work on, the team should be able to answer: is this core, additive, or experimental? And if it’s experimental — what would cause us to graduate it or cut it?

The Pruning Posture

Pruning in this model is not the same as ruthlessly cutting anything that doesn’t pass a hard filter. That would mean discarding the accidental benefits of AI — the unexpected outputs that turn out to be genuinely valuable. The point is not to build less. It’s to hold features lightly until they’ve earned permanence.

The discipline is not deletion. It’s readiness to delete. A team that’s ready to cut an experimental feature the moment it starts competing with a core feature is a team that’s doing this right. A team that can’t cut it — because it’s already in the sprint, already in the documentation, already in the demo — is a team that’s already lost the plot.

This is the new form of technical debt. Not code that’s hard to change, but features that are psychologically hard to remove. The cost compounds quietly until the product is unrecognizable from its commandments.

The Litmus Test for New Additions

Before any new feature — AI-generated or otherwise — moves from experimental to additive, it should survive three questions:

– Does it serve a commandment, or does it serve something we built earlier that we’ve started treating like a commandment?

– If a core feature and this feature came into conflict tomorrow, which one would we cut? If the answer isn’t immediate and obvious, the feature hasn’t earned its place.

– What’s the maintenance cost in human attention, not just compute? Free to generate is not free to own.

These aren’t gates designed to kill ideas. They’re filters designed to protect the product’s identity at a moment when the friction of generation has essentially disappeared but the friction of removal has not.

The Takeaway

The Agile Manifesto was written by people exhausted by process for its own sake. They wanted to restore the ability to respond to change, to trust people over procedures, to value working software over comprehensive documentation. Those values haven’t expired.

But the context has changed enough that the expression of those values needs to change with it. In 2001, the constraint was throughput. The manifesto was designed to remove friction from creation. In the AI era, the constraint is judgment. The methodology of this era needs to remove friction from evaluation and removal — to make the act of pruning as fast and as cheap as the act of building.

Agile taught us to be comfortable with change. What we need now is to be comfortable with loss — the deliberate, guilt-free, strategically correct loss of things we built, things we almost kept, things that were genuinely impressive but not genuinely aligned.

That’s not a betrayal of the Agile spirit. It’s the next chapter of it.

This is the beginning of a longer conversation. The principles outlined here will evolve into a more formal framework — one designed for teams building in a world where creation is cheap and judgment is the scarce resource. If this resonates with how your team is working, or failing to work, I’d like to hear about it.

About the Author

Ben Sutherland is a founder and product leader with 20+ years building games and digital experiences for Disney, EA, Zynga, Microsoft, and Google. After a successful exit, Ben has focused on purpose-built product design and innovation initiatives. He writes about AI, leadership, futurism, and the future of creative work.