How Agile Went From Serving Builders to Serving the Business

Agile was born out of frustration. Software engineers, stifled by the rigid waterfall methodology, were desperate for a better way to build software. They needed flexibility to adapt to changing requirements, collaboration to break down silos, and iterative progress to deliver value faster. So they crafted the Agile Manifesto with a vision to empower builders—to give them the tools and autonomy to create great solutions in a dynamic, fast-paced world.

The principles outlined in the Agile Manifesto—individuals and interactions over processes, working software over documentation, customer collaboration over contracts, and responding to change over following a plan—were revolutionary. Agile didn’t just fix what was broken with waterfall; it gave builders a framework for doing their best work.

But slowly Agile stopped serving builders and started serving the business. Its principles were absorbed into corporate cultures more concerned with optics than outcomes. Agile practices naturally went from a tool for building great products to a mechanism for delivering frequent status updates, managing risk, and maintaining a comforting sense of progress. It now serves businesses more than builders and their customers, but it's cadence of updates masks this reality.

An adage from the early days of software engineering was "No one ever got fired buying IBM."  choosing a well-established, reputable vendor like IBM was seen as a "safe" decision, even if it wasn't always the most innovative or cost-effective option. The implication was that if something went wrong, the decision-maker could avoid blame by pointing to the company's track record and reputation. Agile largely fills this need today.

The Shift: From Builders to the Business

As Agile gained popularity, businesses embraced it not just as a tool for building software, but as a framework for managing work. What was once a lightweight, flexible approach became a rigid system of rituals: standups, sprint reviews, retrospectives, story points, and burndown charts. These rituals, originally intended to help teams communicate and collaborate, morphed into mechanisms for tracking progress and delivering frequent updates to stakeholders.

Suddenly, Agile was no longer about empowering builders—it was about serving the business. Stakeholders loved Agile because it gave them the visibility and control they craved. The two-week sprint cycle offered a steady stream of deliverables, giving the illusion of constant progress. Standups provided daily status reports. Backlogs created a sense of order and prioritization. Product owners became project managers. Agile became a comfort blanket for businesses, offering the appearance of control in a world where product development is inherently messy and uncertain.

But this shift came at a cost. The focus on delivering frequent updates often undermined the very principles Agile was designed to uphold. Teams prioritized velocity—getting something “shippable” done within the sprint—over meaningful problem-solving. Incremental changes took precedence over cohesive design. Product teams found themselves locked into a relentless cycle of delivery, with little time or space to think deeply about the problems they were solving.

The Illusion of De-Risking

One of the great promises of Agile is its ability to “de-risk” development. By working in small increments and gathering feedback along the way, teams can avoid the catastrophic failures that often plagued waterfall projects. In theory, this makes sense. But in practice, Agile’s obsession with speed and iteration can introduce as much risk as it mitigates.

I once worked on a project that perfectly illustrated this problem. We were tasked with building a complex feature that was part of a broader vision for the product. When I asked questions about how the feature would work, how users would engage with it, or how it fit into the overall experience, the answers were vague. When I pressed for more detail, I was told, “We’ll release it and learn.”

This is Agile at its most frustrating. The ethos of “release and learn” works for small experiments, but this was a six-month build. By the time we released it, the flaws were obvious. It didn’t align with user needs, and pivoting would take months more. All of this could have been avoided with just a week of deep thinking and planning upfront. Instead, Agile’s bias toward action over thought led to wasted time and effort.

Agile favors speed, but sometimes speed is a false economy. Building the wrong thing quickly doesn’t save time—it wastes it. And the illusion of de-risking through constant iteration can prevent teams from taking the time to design thoughtful, cohesive solutions.

Fragmentation in the Name of Progress

Agile encourages teams to work in small, incremental steps. This approach makes sense for some kinds of work—bug fixes, minor feature enhancements, or iterative design improvements. But for larger, more ambitious projects, it can lead to fragmentation. Teams focus on delivering “shippable” increments without a clear sense of how those pieces fit together into a coherent whole.

Human users don’t interact with products in increments. They experience the product as a complete entity. If the underlying vision is unclear—or if the pieces are bolted together without consideration for the overall experience—the end result is a product that feels disjointed and uninspired. You can’t iterate your way to coherence. It has to be baked in from the beginning.

The most successful products aren’t the result of endless iterations. They’re the result of deliberate, cohesive design driven by a strong vision. Look at the iPhone. Its revolutionary design didn’t emerge from countless A/B tests or two-week sprints. It was the product of deep thinking, ambitious goals, and a commitment to solving problems holistically. Agile can’t produce products like the iPhone because it doesn’t leave room for the kind of unhurried exploration and refinement such innovations require.

The Return of Silos

Ironically, Agile’s emphasis on small, self-organizing teams has reintroduced the very silos it was meant to eliminate. By empowering teams to own their own pieces of the product, Agile often neglects the hard work of building cohesion across teams. Each team is tasked with delivering its part of the product, improving a specific metric, but no one is truly responsible for ensuring the pieces fit together into a seamless whole.

This approach can lead to disjointed user experiences as the product grows. Features feel cobbled together, interfaces are inconsistent, and workflows are fragmented. In theory, this is mitigated by collaboration between teams—but in practice, that level of coordination is rare. Each team is too busy meeting its own sprint goals to focus on the bigger picture.

The problem isn’t empowerment itself—it’s that empowerment has become an excuse to abdicate responsibility. Instead of investing in the cross-functional effort needed to create a cohesive product, organizations push the responsibility down to individual teams under the guise of “Agile principles.” The result is a fractured product that fails to deliver the kind of unified experience users expect.

Creativity and Vision in a Sprint-Based World

Agile’s emphasis on velocity—the speed at which teams deliver “working software”—can be a double-edged sword. On one hand, it encourages momentum and progress. On the other, it creates pressure to move quickly, often at the expense of thoughtful exploration. Teams are so focused on delivering something tangible by the end of the sprint that they rarely step back to ask whether they’re working on the right thing or pursuing the right approach.

Creativity doesn’t flourish in this environment. Vision takes time. It requires stepping back, questioning assumptions, and allowing ideas to gestate. Innovation isn’t always linear, and it doesn’t fit neatly into a backlog or sprint cycle. By prioritizing speed and iteration, Agile often sidelines the slower, messier process of crafting something truly groundbreaking.

This is why the most innovative companies tend to use a lighter, more flexible version of Agile—or abandon it altogether. Consider OpenAI. Building something as transformative as ChatGPT isn’t about iterating your way to a better chatbot every two weeks. It’s about solving profound technical challenges and pursuing a long-term vision. Iteration plays a role, but it’s in service of deep thinking, not a substitute for it.

What happens next?

As a company grows Agile eventually succumbs to a businesses natural need to understand risk and control what teams are working. It's risky to allow too much creativity and flexibility. It's also hard to align multiple teams towards one cohesive user experience. Everyone loves a flat org chart.

My sense is that there will be two types of technology companies. Those involved in true R&D, rich customer experiences, and building superior brands, and those who think they are doing these things. Choose your reality wisely.