Agile is too rigid for AI-native
I say this as someone who has seriously lived, taught, and scaled Agile: Agile was my second professional love – and today I say goodbye. How that came to be, and why the Agile movement sadly turned into little more than a business model, I’ve already told in AI eats Agile for Breakfast. Today I want to explain why Agile no longer works for me.
Why Agile doesn’t fit AI-native
Too fast a pace. On a good day, an AI-native team ships five features, 10 chores, and 3 bugfixes. Priorities shift hour by hour. No Agile framework with time-boxed events can keep up with that. By the time the daily scrum happens, every impediment is already addressed, resolved, and shipped to production ;)
Code isn’t written by teams. Niels Pflaeging puts it plainly in his analysis of Time-Oriented Software Development: at any given moment, software is built by exactly one person or one pair – never more. Anything beyond that isn’t collaboration, it’s batching and a barrier to performance. That’s exactly why working solo or in a pair, coupled with AI agents, beats any development team. Teams mean coordination, and bigger teams mean even more coordination. And coordination breaks flow. That’s exactly why developer-agent teams don’t belong buried somewhere in an IT department, but directly in the business line – Niels calls that “business people who happen to develop software.”
Scale down. Answering this pace with more process makes it worse. SAFe meets complexity with massive scaling apparatus and rigid Release Trains running on an 8-to-12-week cadence – agility theater that scales in exactly the wrong direction. More structure is the wrong answer to more complexity. Tearing structure down, scaling down, is the right call at this pace.
Flow. The real break runs deeper, though: daily, refinement, planning, sync, departments, handovers, segmented process chains – every handoff breaks flow. No amount of ritual-tweaking fixes that. The bottleneck isn’t building itself, it’s bringing attention, context, and responsibility into alignment with flow. Which means the entire development process – from idea to shipping in production – has to be optimized for flow, with the organizational and procedural hurdles removed.
Make time the boss
If you want to scale down and optimize for flow, the blueprint isn’t Scrum or SAFe – it’s the factory floor. Niels Pflaeging draws the line from the Toyota Production System to Time-Oriented Software Development (TOSD). The core idea: capacity isn’t the fixed thing with delivery time floating around it – time is the fixed boss, and capacity flexes. Single-piece flow instead of batches, fixed timeboxes instead of sprint forecasts, daily closure instead of a sprint goal somewhere in the distance.
Concretely: work flows from a prioritized list, via concept, across an OK Point, into a strictly time-fixed realization – one day ideal, two acceptable, three the maximum. If a unit takes longer, the timebox isn’t wrong – the scope is cut wrong.
No fixed sprints, events, estimates, or central coordination. One list, flow, rhythm, and the principle “talk to each other” whenever it’s needed. Flow can be that simple. KISS – possibly Agile, in its purest form ;)
What I keep, and where I diverge
I’m a critical thinker, and on one point, TOSD’s authors and I explicitly disagree. For Niels, the OK Point sits “exclusively” between humans. For me, it additionally also sits between humans and agents – and that’s exactly what Niels rejects: an agreement between human and agent, he’d say, is an illusion, not a real OK Point.
I experience it differently in my daily work: the agent puts a proposal on the table, I sharpen it, we agree it’s OK, and realization starts – and at the end, we check whether the agreement was kept. How that works exactly, I’ll explain in the posts that follow on this channel. Stay tuned.
I want to be clear that my farewell to Agile isn’t meant in the sense of “yuck, everything is bad.” The principles behind Agile – short feedback loops, working software over comprehensive documentation, responding to change over following a plan – are more right today than ever. I’m not saying goodbye to what Agile wanted. I’m saying goodbye to the form it turned into.
The price of flow
This probably sounds too good to be true, you’re likely thinking right now. But you need to understand the price you pay for tearing down organization, structure, process, bureaucracy, and rules: “The currencies are called business sense, skill, and responsibility.” A fool with a tool is still a fool, but a responsible, skilled person with business sense, coupled with an AI agent team and a Platform that keeps the agents on track, can work true wonders.