Kill the Theater, Keep the Agility
I don’t want to write a treatise on product methodology. I want to put down a few convictions about how we build things now — in a moment when the ground moves under us every single week day.
Here is the first one: the problem was never Agile. The problem is the theater we built on top of it.
More than a decade ago, Dave Thomas — one of the seventeen people who actually signed the Agile Manifesto — said that “Agile is not a noun, it’s an adjective.” The moment it became a noun, it became a product. Something you buy, certify, scale, and sell. Frameworks with capital letters. Quadrants. Two-day courses that turn you into a “master” of anything.
That is the thing I want dead. Not agility. The theater.
The theater we should burn
You know the theater when you see it. The daily stand-up that is really a status report to a manager who doesn’t trust the team. The velocity chart that turns engineers into a factory line measured in points. The two-week sprint defended as if the number two had been handed down on a stone tablet. The retrospective that produces the same five sticky notes every fortnight and changes nothing (improve the communication, work on technical debts, bug pipelines, etc).
Martin Fowler — another signatory — calls this the Agile Industrial Complex: process imposed on teams from above, in the name of a manifesto that explicitly valued people over process. We turned a rebellion against bureaucracy into a new bureaucracy. That’s the joke. That’s the tragedy.
The uncomfortable twist
Here’s what almost nobody says out loud: everything I’m about to propose is already in the 2001 Manifesto. Welcome change late. Deliver working software on the shortest timescale you can. Business and builders working together, daily. Self-organizing teams. Maximize the work not done.
We didn’t outgrow those ideas. We buried them under ceremony. And now AI hands us both the excuse and the leverage to dig them back out.
So this isn’t a call for something post-Agile. It’s a call to finally do the original thing — at the speed the tools now allow. Four convictions.
1. Plan the compass, not the map
Long-term — and even mid-term — planning is mostly a performance now. Not because direction doesn’t matter; it matters more than ever. But the detail you commit to on Monday is obsolete by Friday. Your competitors moved. The model you build on shipped a new version. A capability that was impossible last month is a weekend project today.
So separate the two things we keep confusing. Direction is stable: the vision, the strategy, the problems worth solving. Hold those strongly. Execution is liquid: the roadmap, the plan, the order of work. Hold those loosely. Marty Cagan has been saying it for years — measure outcomes, not output. A roadmap full of shipped features that moved nothing is not a win.
Plan the compass. Stop drawing the map in ink.
2. The unit of work is the learning loop — not the sprint
When coding consumed most of a sprint, two weeks made sense. AI collapsed that. The build is no longer the bottleneck; understanding the problem is. When execution shrinks from days to hours, a fourteen-day cycle stops being a rhythm and becomes an artificial delay.
Basecamp’s Shape Up pointed the way before AI even arrived: fixed time, variable scope, no eternal backlog to groom. AI lets us push it further. A week. Sometimes a day. And the cycle is the whole cycle — discovery, shaping, build, QA, deploy — not just the coding slice. The question is never “how many points.” It’s “what can we learn and ship before this loop closes.”
3. The T, amplified on both ends
The people who thrive now are T-shaped: deep in one thing, broad across many. Tim Brown at IDEO made that shape famous. AI doesn’t flatten it — it stretches it on both axes.
The horizontal bar gets wider. Everyone can now prototype, run a market scan, draft the copy, read the code well enough to ask the right question. The vertical bar gets deeper, because the specialist offloads the routine and spends their judgment where only they can.
So stop thinking of AI as a teammate assigned to each person. It isn’t a second head count. It’s an extension of the one you already have — wider reach, deeper craft, more done in less time. A team of T-shaped people with that extension does what used to require a department.
4. Everyone in the room from minute one
The old assembly line — the PM writes the spec, hands it to design, who hands it to engineering, who hands it to QA — is the slowest possible way to be wrong. Kill the handoff.
Put the whole team in from the first hour. The PM leads the why; that’s the vertical bar of their T. But the feature is not a closed document handed down — it’s a problem the team solves together. Engineers start building while the shape is still forming, in conversation, not from a ticket. QA designs the tests from day one, not after. Design, research, code, validation — in parallel, in the same room, in the same week. The Manifesto said it plainly in 2001: business people and builders, working together, daily. We just stopped doing it.
What this is not
This is not an argument for moving fast and breaking things. It’s the opposite. When AI makes the build cheap, speed stops being the differentiator — discipline does. Faster code with no tests is just faster debt. A one-week cycle with no clear intent is just chaos with a deadline.
AI doesn’t retire the old engineering virtues — clear specs, automated tests, small batches, tight feedback. It makes them non-negotiable. The teams that win with AI aren’t the ones that build the fastest. They’re the ones that learn the fastest, with the discipline to trust what they shipped.
The point
The proof is already on the table. Tiny, AI-native teams are reaching revenue that used to require hundreds of people. They aren’t winning because they run better ceremonies. They’re winning because there’s almost no distance between the people who decide and the people who build.
That’s the whole thing. Kill the theater. Keep the agility. One is a costume. The other was always the job.
— Nicolás Parola