Big A Agile Is Broken

If you asked most people at a large company “how do you know you’re practicing Agile?” you’d get answers about Jira configurations, sprint ceremonies, planning poker, swimlanes, and certifications. Very few would say “because we care most about continuously shipping good software with improvements.” Very few would talk about how they empower and trust their engineers to understand the business, or their business people to be familiar with the software.

That gap — between what Agile has become and what the manifesto actually said — is the whole problem.

The Original Insight

The Agile Manifesto was a short document with a radical idea: software is a creative process built by humans, and it’s a process of discovery. As you build, you discover limits and constraints. You uncover things you didn’t know about the business. You surface decisions that haven’t been made yet. The manifesto said: lean into that. Value working software over comprehensive documentation. Value individuals and interactions over processes and tools. Value responding to change over following a plan.

That’s it. That was the insight. And it was a good one.

What We Built on Top of It

There’s a prevailing view in business that software is fundamentally an assembly line problem. Put tickets in one end, get software out the other, and if you have the right process running the line, you get good outcomes regardless of who you put in the positions. Businesses have a natural incentive to think this way — process is controllable, people change. If quality comes from the system rather than the individuals, you can scale by filling positions with the cheapest available option. It’s why offshoring and now AI-generated code look so appealing to certain buyers.

Big A Agile — the ecosystem of certifications, frameworks, and process theater — has been conformed to fit neatly into that assumption. It’s largely centered around processes and tools. The original manifesto pushed back against treating software like a manufacturing line. The industry that grew up around the manifesto rebuilt exactly the thing it was supposed to replace.

The ceremonies are different from waterfall. The underlying assumption is the same — that process, not people and collaboration, is what produces quality.

Meetings Are Not The Same as Collaboration

I’ve seen this play out repeatedly at large enterprises. Just because you’re having meetings does not mean you’re having collaboration. Planning poker sessions where nobody is genuinely collaborating, but everyone is “estimating” in a way that makes someone in the org chart happy without providing meaningful information for the project. Sprint reviews that are status reports, not feedback loops.

I’ve watched companies operate with the expectation that “this will ship in 3 months and I can’t be wrong” while simultaneously refusing to flex on features. But the math doesn’t work that way. You can fix scope and let time flex, or you can fix time and let scope flex. If you think you’re fixing both, you’re doing one of three things: grossly overestimating time, destroying quality, or lying to yourself — letting features slip through moving goalposts rather than conscious product direction.

None of that is agile. It’s process theater designed to make everyone feel like there’s a plan, while avoiding the uncomfortable truth that building software requires ongoing judgment, trade-offs, and discovery.

The Risk Paradox

A lot of big companies adopt Agile specifically to manage risk. But then they ignore the key risk-management insight of agile — do the riskiest things first while always building and shipping working software.

Instead, I’ve seen teams go off and build elaborate architectures while ignoring the thornier problems, only to have those risks emerge later when there’s no time left to address them. It feels productive because code is being written. But the hardest questions are being deferred, not answered.

Building something that people use, piece by piece, iterating to a better state and constantly valuing a working build — that forecloses a lot of risk explosions later when everything needs to come together. It takes humility to ship often and show work in progress. It also takes courage to address the most unknown or riskiest part of the problem first, rather than staying comfortable with the things you’ve built before.

Ironically, the framework-heavy version of Agile that’s supposed to manage risk actually increases it by giving teams a false sense of control.

What Small-a Agile Looks Like

At BiTE, I’ve always said we’re “small-a agile, not Big A Agile.” We operate in small teams, value cross-pollination across product, design, and engineering, and put working, shipping software as our number one goal. We’ve used six, maybe eight different project management tools over the years. We never let the tool determine our process.

To take an example, on a project we’re currently building, one of our first coding tasks was standing up the full CI and TestFlight architecture. We went immediately toward getting code continuously shipping even though we have a lot of supporting pieces to build. CI/CD isn’t glamorous or fun work, but we know we needed a working build from day one that we could iterate on, rather than a collection of pieces we’d wire together later and hope they fit. Or worse, high alignment amongst the developers who can build on their own copies with a total lack of input from product, design, and our subject matter experts.

If someone asked me “how do you know you’re doing agile?” I’d point to our commitment to working software, shipped often. I’d point to how collaborative our team is across disciplines — engineers aren’t siloed away from product people and designers. That’s it. No certifications, no frameworks, no swimlane configurations. Just people building working software together and making it better every iteration.

Software Is Not an Assembly Line

Robert Heinlein once suggested that if someone gives you the idea for a book, you ought to buy them a beer. The idea doesn’t make the novel. The novel is the detailed work of bringing that idea into all sorts of places that aren’t obvious, working out how to realize it in ways you couldn’t have predicted when you started. The idea is important — that’s why you buy them a beer. But it’s not the novel.

A lot of people think you could come up with a good science fiction concept, hand a prompt to an AI, and get a Heinlein novel. As amazing as it is to get back a novel from just a prompt, it will be immeasurably less than Heinlein. Likewise, thinking that software is simply a matter of specifying tickets, handing off the prompts, and watching the system appear full formed with no changes or insights along the way.

There’s work to do. Creative, human, collaborative work. The kind that only happens when you trust the people doing it more than the process surrounding them. The manifesto knew that. Somewhere along the way, the industry forgot.