The Agile Manifesto turned 25 in February. Seventeen people at a ski lodge in Utah in 2001, writing four lines that the entire enterprise world would eventually turn into a certification industry. Over the last days I've had a few conversations with friends who are struggling with exactly this right now....and I can't get rid of a thought in my head. I genuinely can't tell if it's just stupid or completely obvious.
All the shenanigans we've been doing in engineering for 25 years one way or the other, Scrum, sprint planning, story points, estimation sessions, change management boards, yes even waterfall to some extent, were built for a world where changing your mind was expensive. Writing an app took months or years and a customer changing their requirements in month five cost real money, so you spent month one making very sure they wouldn't. The process existed because the mistake was costly....and that changed dramatically.
We live in a world where the price tag on source code is basically what the tokens cost, and nobody employs an army of engineers to hand tune software any more.
So how much of it do we still need?
What the ceremonies were actually pricing
The number underneath all of it comes from Barry Boehm. His 1981 cost of change curve, built on data from TRW and IBM waterfall projects in the 1970s, said a defect caught during requirements costs roughly 1x to fix and the same one caught in production costs something like 100x. Exponential. That curve is the reason every heavyweight process you have ever sat through exists. It was maths rather than culture, which is worth sitting with for a second.
Now the part I enjoy.
Kent Beck attacked that curve in Extreme Programming Explained in 2000, arguing that with the right practices the cost of change flattens out instead of exploding. It became one of the beliefs the whole agile movement got built on. And then he quietly dropped the claim from the second edition, because nobody could produce the data to back it up.
So the curve that justified heavy process came from 1970s mainframe projects, and the rebuttal that shaped twenty five years of the alternative got pulled for lack of evidence. Both sides of the argument that decided how most of our industry organises its work were, honestly, a good guess with a slide behind it.
That makes me more willing to take the thought seriously, not less.
The batch size half, where I think it's just correct
A sprint is a batching mechanism. Two weeks is not a natural unit of anything. It exists because gathering feedback used to be expensive, so you paid that cost once and spread it over ten days. Plan once, build for ten days, show it, adjust. Drop the cost of feedback and the optimal batch size heads toward one.
It's queueing theory rather than a hot take, and it's why flow-based systems keep quietly eating Scrum inside teams that already deploy continuously. The 2026 signal is visible in hiring rather than in blog posts: Scrum Master roles are being merged, renamed or removed from hiring plans, while the certification business keeps growing. Both of those are true at once and the combination tells you roughly everything. I'd even go a step further and say if you're still running Scrum by the book....you might be up for a rude awakening when the competitors around you outpace you by miles.
Where the thesis breaks, where my thoughts might have been wrong
I had been filing Scrum and BPMN or similar in the same drawer. Thinking about it and writing this, I don't think they belong there.
Scrum is a construction methodology. It's about how a team builds a thing, and it existed because building was slow and expensive and you kept finding problems halfway through. Building got cheap. So it's worth less now. Straightforward.
BPMN however is a different animal. It's a written down deal about what actually happens. A process model doesn't describe how you'll build software, it describes what the business does. Who approves what. What happens on the unhappy path. Which step only exists because a regulator demands it and not because someone once preferred it that way. AI made building cheap and did nothing at all for ambiguity, and if anything being vague got more expensive, which unlike the Boehm curve is a part we have actual evidence for.
Maybe we can even argue BPMN is more important than ever now, or some form of it that AI can properly understand, but that's a topic for a different post.
DORA's 2025 report found that higher AI adoption now correlates with an increase in delivery throughput and an increase in delivery instability at the same time. Their explanation is that time saved during creation gets reallocated straight into auditing and verification. Their framing is that AI works as an amplifier, magnifying whatever strengths and dysfunctions the organisation already had.
Then there's the METR randomised trial, which I keep coming back to. Sixteen experienced open source developers, 246 real tasks, on mature repositories they already knew well. With AI tools allowed, they were 19% slower. They had predicted 24% faster going in. Afterwards, having actually been slower, they estimated they'd been 20% faster.
The gap between measured and felt is the whole story.
And the aggregate version: teams reporting they write code several times faster than two years ago, while cycle time from ticket opened to feature in production barely moves. The coding part got fast. Everything around it didn't.
No mystery about why. Hand an agent an underspecified requirement and it does not stop to ask you what you meant, it fills the gap with the most plausible thing and returns working code that confidently does the wrong thing. A vague requirement used to produce a stalled ticket and an awkward question in Slack. Now it produces a merged pull request.
The joke is that BPMN might be the only thing that's left from all the magic
Spec-driven development is the fashionable practice of 2026. Write a precise specification, hand it to the agent, review what comes back. There is an enormous amount of energy going into markdown scaffolding to make this work well. So many people suggest running through proper planning sessions before handing something to an agent, and plans are still important for sure.
A BPMN diagram is a formal specification with unambiguous semantics, an executable runtime, and a standard that's been stable for two decades. Camunda argued exactly this in April, and yes, they sell a BPMN engine, so weight it accordingly. The argument survives the conflict of interest.
There's also research extending BPMN to model human and agent collaborative workflows, on the grounds that existing process languages can't express agent decision-making, reliability, or the specific points where a human has to be in the loop. Which is a fancy way of saying the notation we already had is closer to what agents need than anything invented since.
The deployment numbers point the same direction. Something like 71% of organisations are using AI agents, and roughly 11% of agentic use cases actually reached production in the past year. That gap is exactly where the boring stuff lives: retries, timers, state, audit trails, and a written definition of what the process even is.
Which is the problem BPMN was invented to solve, about fifteen years before anyone needed it for this.
So what might be gone soon now?
Cut the sprint as a fixed ritual, cut story points, which were a proxy for effort under uncertainty and effort is no longer the scarce input. Cut the estimation ceremony. Cut the two week batch if you deploy continuously, because you're paying a coordination tax for a feedback loop you no longer have. Keep, and spend more on than you currently do: the written, precise, reviewable description of what should happen. Anything that captures the unhappy path. Anything that records who decides what, because that is the one thing an agent cannot infer from your codebase no matter how good it gets.
So the bits of the old process that kept humans in sync are dying, while the boring write-it-down bits suddenly hold the whole thing up. Most teams are going to love the first half of that and quietly skip the second.
The bit I can't resolve
I don't know whether a formal notation is the right container for this as nobody has ever enjoyed drawing BPMN, the tooling has historically been miserable, and the diagrams have a habit of describing a process that stopped existing eight months ago. (I'm aware I've just spent several paragraphs defending a thing I would personally rather not open.)
But something has to hold the unambiguous description, and the honest alternative on offer right now is a long markdown file that drifts from reality at roughly the same rate the diagrams did, with fewer semantics and no runtime.
Here's the experiment I'd actually run. Next time a change request comes in, time two things separately. How long it takes to build the change, and how long it takes to decide precisely what the change should do including the edge cases nobody mentioned. Then compare.
If the second number is the bigger one, the process you should be cutting is not the process you thought.
