I love the idea of creating separate lanes for human intuition and algorithmic flow. This really resonates with how I see the future unfolding: presence, pattern-making, and the visual pulse of meaning meet the raw acceleration of machine orchestration. Thanks for opening this door.
Scrum cycles can (and should) be decoupled from releases. We can release during the sprint. Nothing prevents that. We can have both discovery (strategic and tactical refinement) and delivery during the sprint.
Scrum events, such as review, should be used more towards reflecting together (based on metrics) and planning for the next sprints. As you mention, humans need a human-scale for thinking.
The dual-track framing is sharp. But the bottleneck between lanes isn't speed – it's specification. The human lane runs on tribal knowledge: the definition of "done" lives in someone's head, the acceptance criteria are negotiated in conversation, the quality standard is "I'll know it when I see it." That works when everyone is human. The moment an AI agent joins, it needs what it has never been given: a machine-readable specification of what the work actually requires. Not a user story. A testable contract. The fast lane doesn't need faster Scrum – it needs a specification layer that both lanes can read. Humans interpret it as process documentation. Agents execute it as test suites. Same source, two renderings.
Dual-track agility assumes the handoff between the judgment layer and the execution layer stays manageable. That assumption doesn’t survive contact with what the machine lane actually produces.
When AI is shipping in hours instead of weeks, the human lane isn’t governing execution anymore, it’s triaging it. The sprint cadence that once matched the pace of delivery now can’t keep pace with the volume of decisions returning from the machine lane for evaluation. Did that feature solve the right problem? Does that output match what the user actually needed? Is the thing we specified last Tuesday still the right thing now that we can see it running? Those questions don’t get slower because execution got faster. They multiply.
The post argues for separating the lanes so humans can operate at human speed. But the machine lane doesn’t stay in its lane. It generates requirements for the human lane faster than the human lane can process them. The bottleneck doesn’t disappear with dual-track design. It moves…straight to the judgment layer that Scrum was built to protect.
Correct. And that's why the slow lane will have to look very different from how it looked in the past when there's a fast lane that it needs to interact with.
In practice, I’ve seen Scrum often become a ‘ritual shield’, teams go through the motions while the org still thinks in annual planning cycles. The real bottleneck isn’t always Scrum itself, but the mental models it’s asked to run inside.
Scrum’s core idea short feedback loops, team autonomy, and transparency is still valuable what’s dying is treating it as the one‑size‑all solution rather than a template to adapt. Maybe the next layer is AI‑aware agility decoupling plan‑making from execution‑making, and letting AI run on its own rhythm while humans focus on intention, ethics, and discovery. Let's see...
AI may not need a standup, but humans still do. And unless I’m missing something, AI doesn’t create its own work backlog — it runs on the prompts, priorities, and context that usually get clarified in those very ceremonies you dismiss.
Correct. That's why I called it DUAL track, not ONE track only for AIs.
And AI definitely creates, prioritizes and manages the backlog at companies such as Tesla and Amazon. It's not a common approach, for sure, but it's definitely possible.
To be fair, if we do get to the point where we just have 1 engineer managing an Agentic swarm, doing the work of 10 people, we probably can ditch stand up. A dream? Maybe. But it’s cool to think about :p
i understand the tech excitement. But on another path, where are all of these highly trained people going to work when AI is capable of doing the work of 10 engineers. I am not a bleeding heart, but massive unrest is in our future if we are successful a making AI this successful.
Scrum isn’t done. It’s just built for a species that hasn’t caught up to its own tools.
The problem with “dual-track” thinking is that it still assumes there’s a single terrain—one field of play where humans and machines coexist in parallel. But humans and machines don’t share a terrain. They operate from different gravitational centers.
Humans metabolize complexity through story, context, and care. Machines metabolize it through pattern, precision, and scale. They’re not faster lanes on the same highway—they’re different laws of physics. Trying to optimize one with the logic of the other is why our systems keep overheating.
This isn’t dual-track agility. It’s dual operating systems. And the real challenge isn’t choosing which to prioritize—it’s architecting the translation layer that lets them interact without collapse. That’s not a sprint problem. It’s an ontology problem.
Scrum isn’t dead; it’s running on legacy firmware. The update isn’t another framework—it’s a new interface between consciousness and computation.
There is a lol to unpack in this article, but it really has me thinking. I'm a huge believer in Agile and ran my teams that way before I retired. But this is the first time I have really thought about how running teams should change with the advent of AI, and I have to say your thoughts on this really resonate with me. Humans will still need their Agile lane, but AI will need something new. Something that is a hybrid of what exists today. Thanks for this thought provoking piece. I think I will be thinking about it for days to come.
I love the idea of creating separate lanes for human intuition and algorithmic flow. This really resonates with how I see the future unfolding: presence, pattern-making, and the visual pulse of meaning meet the raw acceleration of machine orchestration. Thanks for opening this door.
Let’s hope we can navigate towards that. Let our agents to agent stuff and free up human creativity and ingenuity.
Scrum cycles can (and should) be decoupled from releases. We can release during the sprint. Nothing prevents that. We can have both discovery (strategic and tactical refinement) and delivery during the sprint.
Scrum events, such as review, should be used more towards reflecting together (based on metrics) and planning for the next sprints. As you mention, humans need a human-scale for thinking.
The dual-track framing is sharp. But the bottleneck between lanes isn't speed – it's specification. The human lane runs on tribal knowledge: the definition of "done" lives in someone's head, the acceptance criteria are negotiated in conversation, the quality standard is "I'll know it when I see it." That works when everyone is human. The moment an AI agent joins, it needs what it has never been given: a machine-readable specification of what the work actually requires. Not a user story. A testable contract. The fast lane doesn't need faster Scrum – it needs a specification layer that both lanes can read. Humans interpret it as process documentation. Agents execute it as test suites. Same source, two renderings.
Dual-track agility assumes the handoff between the judgment layer and the execution layer stays manageable. That assumption doesn’t survive contact with what the machine lane actually produces.
When AI is shipping in hours instead of weeks, the human lane isn’t governing execution anymore, it’s triaging it. The sprint cadence that once matched the pace of delivery now can’t keep pace with the volume of decisions returning from the machine lane for evaluation. Did that feature solve the right problem? Does that output match what the user actually needed? Is the thing we specified last Tuesday still the right thing now that we can see it running? Those questions don’t get slower because execution got faster. They multiply.
The post argues for separating the lanes so humans can operate at human speed. But the machine lane doesn’t stay in its lane. It generates requirements for the human lane faster than the human lane can process them. The bottleneck doesn’t disappear with dual-track design. It moves…straight to the judgment layer that Scrum was built to protect.
Correct. And that's why the slow lane will have to look very different from how it looked in the past when there's a fast lane that it needs to interact with.
In practice, I’ve seen Scrum often become a ‘ritual shield’, teams go through the motions while the org still thinks in annual planning cycles. The real bottleneck isn’t always Scrum itself, but the mental models it’s asked to run inside.
Scrum’s core idea short feedback loops, team autonomy, and transparency is still valuable what’s dying is treating it as the one‑size‑all solution rather than a template to adapt. Maybe the next layer is AI‑aware agility decoupling plan‑making from execution‑making, and letting AI run on its own rhythm while humans focus on intention, ethics, and discovery. Let's see...
AI may not need a standup, but humans still do. And unless I’m missing something, AI doesn’t create its own work backlog — it runs on the prompts, priorities, and context that usually get clarified in those very ceremonies you dismiss.
"AI may not need a standup, but humans still do."
Correct. That's why I called it DUAL track, not ONE track only for AIs.
And AI definitely creates, prioritizes and manages the backlog at companies such as Tesla and Amazon. It's not a common approach, for sure, but it's definitely possible.
Good point, you did say dual track. I misread your intent.
Dual stack is a great thought on how to implement honestly.
It doesn’t need Scrum to have a standup. It’s just a funny coincidence.
To be fair, if we do get to the point where we just have 1 engineer managing an Agentic swarm, doing the work of 10 people, we probably can ditch stand up. A dream? Maybe. But it’s cool to think about :p
i understand the tech excitement. But on another path, where are all of these highly trained people going to work when AI is capable of doing the work of 10 engineers. I am not a bleeding heart, but massive unrest is in our future if we are successful a making AI this successful.
Scrum isn’t done. It’s just built for a species that hasn’t caught up to its own tools.
The problem with “dual-track” thinking is that it still assumes there’s a single terrain—one field of play where humans and machines coexist in parallel. But humans and machines don’t share a terrain. They operate from different gravitational centers.
Humans metabolize complexity through story, context, and care. Machines metabolize it through pattern, precision, and scale. They’re not faster lanes on the same highway—they’re different laws of physics. Trying to optimize one with the logic of the other is why our systems keep overheating.
This isn’t dual-track agility. It’s dual operating systems. And the real challenge isn’t choosing which to prioritize—it’s architecting the translation layer that lets them interact without collapse. That’s not a sprint problem. It’s an ontology problem.
Scrum isn’t dead; it’s running on legacy firmware. The update isn’t another framework—it’s a new interface between consciousness and computation.
There is a lol to unpack in this article, but it really has me thinking. I'm a huge believer in Agile and ran my teams that way before I retired. But this is the first time I have really thought about how running teams should change with the advent of AI, and I have to say your thoughts on this really resonate with me. Humans will still need their Agile lane, but AI will need something new. Something that is a hybrid of what exists today. Thanks for this thought provoking piece. I think I will be thinking about it for days to come.
Scrum is old and now that it’s done, I can say I never liked it anyway!
Did Maarten Landmijn take over your account?