Consider this
More code is being generated faster than ever before. DX reports that PR throughput has increased by 75.5% in the past four quarters.
While engineers are reporting higher satisfaction with individual tasks, systemic improvements remain elusive.
This is often phrased as “the bottleneck has moved,” but what if typing wasn’t the bottleneck so much as teams were organised to optimise the amount of typing that could get done? Occasionally, it would be to optimise the value of that typing, but still, this stuff took time, and so Scrum slowly ate the world, one fortnight at a time.
It’s not a marathon...
Teams are still organising around two-week sprints. The muscle memory of planning work this way has outlived its usefulness, like daylight saving time, a ritual still followed even though it was introduced as a reaction to energy crises and war over a century ago. Maybe it’s organisational comfort food in a time of upheaval, but a fortnight is out of step with how fast people now work.
As the world of software development turned its back on waterfall and embraced at least some semblance of agile practices through the first quarter of the twenty-first century, one framework has won out above all others. Scrum and two-week sprints became the corporate defaults. BRDs and change control boards disappeared, replaced by sprint planning, refinement and PRDs. Where once project managers toiled over gantt charts, now product managers planned work in two-week increments.
The idea of empowered product teams was dangled before us, but too often, ”working software is the primary measure of progress” was interpreted as planning delivery based on capacity. Sprint planning became about what can the team get done, rather than what can the team learn.
... and now it’s not a sprint either
Two-week whirlpools replaced waterfall. Given the choice between optimising for flow and optimising for capacity utilisation, organisations chose capacity utilisation. This focus on capacity means that there’s often no room to manoeuvre when the team finds something unexpected or a new request comes in, resulting in sprint churn. There’s an irony in that the kind of organisation that claims to value predictability can’t even plan two weeks ahead.
Now the constraint has shrunk significantly. Developers’ (avail)ability to deliver code is no longer an asset to be optimised. Code generation takes minutes. The work of individual engineers has transformed. I’ve lost count of the number of developers who have said to me “I no longer write code.” They mean they don’t type syntax anymore, they get an LLM to generate that for them. But the way in which work is arranged hasn’t caught up yet.
“Developers are using AI to complete individual tasks quickly, but those gains translate only partially into a smoother path through review queues, test suites, and release gates.” - DX AI State of Engineering: Q3 Report (Oct 2026)
At this speed, do fortnights still make sense? And if the answer is shorter sprints, what exactly are we shortening? Are long planning and refinement sessions useful in a world where spec-driven development is possible? Has the time come to optimise for team flow rather than developer capacity?
The Candyman Kanban
The obvious answer is “let’s all do Kanban,” and that feels like it should be the answer but I fear it is more comfort food, especially for those of us who believe in lean more than agile. Optimising for flow makes sense. It always has.
I suspect, though, that if enterprises were going to adopt Kanban, they’d have done it by now. There are reasons why this hasn’t happened, and part of it, I think, is the organisation’s addiction to predictability. Leadership are not prepared to hear “it takes as long as it takes.” Timeboxes satisfy them.
Shape Up offers part of the answer by fixing time to work on shaped projects. But it’s still shaping the work to fit in a set time. Given Shape Up works in six-week increments, it’s even harder to see how this survives an accelerated future than the fortnightly sprint does.
And now, the end is near...
It’s worth remembering that there’s nothing special about a two-week sprint. The organisation tells itself that it can plan capacity that far ahead, and two weeks is usually enough time to demonstrate progress. Even when I was working in Kanban, I tended to do fortnightly stakeholder reviews, partly because that’s the default cadence.
The organisation’s desire for predictability isn’t going anywhere, even as the timelines for code generation shorten. Now, coding capacity is cheap, but attention is expensive. Perhaps it’s time for this iteration of Scrum to retire. To replace it, organisations will need something that takes the best of a flow-based framework, but also gives the enterprise an appropriate form of predictability. To prevent churn, especially in a time of cheap code generation, we need focus.
I’ll state my case
Decision-based development may be upon us. This is where (ideally) the team decides what their next most important problem is. Often, they’ll be told what to work on, but instead of breaking it up into two-week slices, they take the problem statement and plan how to deliver an answer with AI and give a timescale for when they can respond. Not a “you’ll get this in the next two weeks” and not a waterfall approach to delivering an entire solution. Instead, they articulate a clear question and estimate when they’ll have an answer, and fix that as the “decision date.”
The work to reach that answer can be an investigation, a spike, or a delivery of a piece of software. Regardless, the decision date is a promise the team can always keep. On the decision date, the team shares what it has learned and declares its intent. It can declare its intent to ship, to stop, or to take further actions. The person who owns the problem can confirm or challenge the team’s intent, preserving the team’s agency and ensuring the leader is involved in the key decisions. Progress reviews therefore happen on decision dates, when there are meaningful decisions to be made. No more scrabbling around for things to present at sprint reviews.
Attention is expensive for leaders too. A director with multiple teams can spend her time on decisions, not sitting in updates that don’t require her considered opinion.
Working on smaller, purpose-driven changes creates flow, reducing the flood of code that’s overwhelming teams today by enabling them to work to the question, not the fortnight.
More code is being generated faster than ever before. Why wait two weeks to find out what is going on?