There’s a joke that any discipline with “science” in its name probably isn’t one. The same logic applies here: any process with “agile” in its name is probably not agile.
What began in the early 2000s as a genuine reaction to the madness of thousand-page specs and multi-year delivery cycles gradually became something else entirely: a hiring filter, a conference circuit, a certificate mill. Agile stopped being a practice and became a brand – and then, like so many brands without a strong commercial guardian, it got applied to everything until it meant nothing.
Gojko Adzic drew a sharp parallel to Star Wars. Three films. Clear meaning. Then – an avalanche of content that progressively undermined the original idea until even the core premise (there are good guys and bad guys) became negotiable. At some point, you’re no longer protecting a brand. You’re just licensing it to whoever will pay.
Agile Alliance, the body that was supposed to be the guardian of the movement, was recently acquired by PMI – the Project Management Institute. The organization that started with the premise “we don’t need project managers” is now owned by the world’s largest project management body. Bertrand Russell wrote about how doctrines, through completely logical steps taken over a long period of time, can end up producing exactly the opposite of what they intended. This is a textbook case.
Something important has been quietly happening for years: the community has been splitting.
On one side, there’s software agile – test-driven development, continuous delivery, pair programming, the engineering practices that came out of XP. This stuff works. It’s largely been absorbed into how good software teams operate everywhere. You don’t need to teach version control anymore. Kids learn it at university. It won. It just doesn’t need a brand anymore.
On the other side, there’s process agile – retrospectives, facilitation techniques, organizational design, scaling frameworks. This branch kept growing, kept elaborating, kept adding layers. The original Scrum Guide was 10 pages. A book called Essential Scrum – note: essential – ran to 800. That trajectory tells you something.
The problem with the process branch isn’t that the ideas are bad. It’s that they were developed for small teams (5, 10, maybe 30 people), then transplanted into multinationals with 50,000 developers and expected to behave the same way. They don’t. And in trying to make them scale, we built something so elaborate it collapsed under its own weight.
Here’s a pattern that runs through the history of technology: it removes middlemen.
Automated elevator controls replaced elevator operators. Online booking replaced travel agents. Uber replaced local dispatch centers. Technology consistently finds the human layer sitting between a product and its user – and removes it.
A lot of what agile coaching, process facilitation, and organizational agile became over the last 15 years is, structurally, a set of middlemen. That’s not a moral judgment – it’s a pattern. And the pattern suggests these roles will face significant pressure as AI tools increasingly handle the coordination, documentation, and facilitation that humans were hired to do.
Spec-driven development tools are already emerging (Microsoft’s SpecKit, Amazon’s Kira in private beta) that aim to let organizations focus on what they want to build – in plain language = and generate the implementation from there. We’ve been talking about executable specifications for 20 years. The tooling may finally be catching up.
Jeff Bezos reportedly pushes back when people ask him “what will change in the next 10 years?” His counter: ask what won’t change, because that’s what you can build a strategy around.
Two things seem unlikely to change:
Those two forces together suggest a future of smaller teams with more capability per person, less coordination overhead, and a tighter focus on whether you’re building the right thing – not just whether you’re building it efficiently.
The bottleneck has moved. For most organizations today, it’s not shipping software. It’s shipping software that solves the right problem. That’s a specification and judgment problem, not a process problem.
If you identify more with the engineering side – writing code, building systems, caring about quality – that community is alive and well. It’s just no longer calling itself “agile.” It’s gone back to its roots: engineering, craft, technical excellence. It doesn’t need the brand.
If you identify more with the organizational side – helping teams work better, improving communication, navigating complexity -there may actually be a bigger opportunity ahead, not a smaller one. The practices and ideas that were incubated in software teams over 25 years are genuinely applicable to knowledge work in other industries. Healthcare, legal, finance, manufacturing – organizations that have never heard of a sprint retrospective could benefit from what this community learned. The opportunity isn’t to keep elaborating the existing dance. It’s to take what works and export it somewhere it hasn’t been yet.
The brand “agile” may be done. But the underlying questions – how do people work better together, how do you build the right things, how do you stay adaptive in a fast-moving environment – those questions aren’t going anywhere.
