Agile Was Supposed To Save Us

Agile emerged during this time as an alternative way to build software. It was a radical departure from rigid, top-down project planning. Instead of lengthy specifications and fixed timelines, Agile emphasised adaptability, customer collaboration, and iterative development. The goal was simple: deliver working software quickly, respond to change, and focus on real user needs.

Yet, while the Agile Manifesto provided clear principles, its success depended on more than just changing how developers worked. It was a fundamental shift in how businesses approached problem-solving, decision-making, and customer value delivery. But understanding and addressing the systemic changes required for its success required more time and effort than most companies were willing to invest.

1. Process: Shifting from Features to Problems

Traditional software development began with a predefined set of features. Business stakeholders would decide what needed to be built, document it in extensive requirement specs, and hand it over to developers.

Agile turned this on its head. Instead of dictating what to build, organisations were supposed to empower teams to solve problems. Rather than saying, "Build this feature," Agile encouraged teams to explore customer needs, conduct research, experiment, and iterate.

This shift required not just new skills from development teams but also a cultural change in how organisations view their technology workers – from order-takers to problem-solvers. And it goes directly against one of the most ingrained processes in modern companies: the business case. Business cases are how budgets are allocated, projects are approved, and progress is measured. And it is hard that we should drop business cases. Who would be against doing some upfront due diligence before investing in a project?

Business cases would be perfect if we know what customers really wanted and how they would behave to a new product. But we don't. Locking in our scope means that we cannot do small increments and test what customers really way. Our business cases force us to stick with our original guesses - and our track record with our guesses is not great.

This is the biggest stumbling block for most implementations. But there are more challenges ahead for the teams that manage to get agreement to focus on outcomes over outputs.

Alignment: Ensuring Teams Solve the Right Problems

Assuming we get approval to empower teams to solve problems instead of building features, how could organisations ensure they focused on the right things? The reputation of a company is built over years, but can be destroyed in an instant. How can leadership be confident that teams will both focus on the highest priority items as well as ensure that any ideas align with the current corporate strategy?

The answer lies in clear strategic alignment. Every team needs to be aware of, and educated on, the product vision and strategy. They need to be able to determine what solutions would work and what would not. They also need clear metrics and targets (outcomes) so they know what success looks like.

It is much easier to tell someone what to do than to give them the full context that led to that decision. In the same way that when you are training up a junior person it is often more efficient to do the task yourself. However, if management revert to top-down mandates, this will remove the autonomy as well as the accountability for achieving outcomes and the team will revert to building outputs.

Structure: Preventing Duplication in Autonomous Teams

A lot of the Agile guidance is focused on how a single team should work. However, even reasonably sized products rely on a number of teams working in parallel. How should a company organise autonomous teams in a way that prevents duplication of work? If teams can choose what to work on, what stops them from building overlapping solutions?

Traditional hierarchical structures aren’t designed for this new way of working, but organisations often hesitated to make the necessary structural changes, fearing disruption to existing power dynamics and reporting relationships.

Funding: Rethinking Budgets and ROI

Linked to the business case point above, in traditional project management, funding was allocated based on detailed business cases and ROI calculations. If we move away from business cases, how much funding should we invest in a team? Do we need 1 team or 3? Should there be 3 people or 6 on each team?

While pre-Agile ROI calculations were often wildly inaccurate, they at least provided an illusion of control and a means for justifying budget spend. Agile requires a shift to funding teams aligned to products based on the strategic importance of that product.

Governance: From Project Management to Product Management

Business cases also deliver another benefit - they provide strict time and cost constraints that we can use to track progress. The shift from project management to product management is more than just a change in terminology. introduces new metrics and new ways of thinking about value and success.

The Rise of Frameworks: Agile on Autopilot

The reality is that most people are too busy to try to grapple with all of these different challenges. And it would be incredibly inefficient and wasteful to expect every company to re-invent the best practices. This is where frameworks like Scrum came in.

Scrum promised to make Agile implementation easier by providing step-by-step guides and predefined roles. While it addressed some aspects of Agile transformation, it focused too much on the, easier, delivery side of product development while neglecting the harder organisational changes required for success.

The result is that most orgnaisations that claim to be Agile today are more accurately described as "Water-Scrum-Fall". Teams hold daily standups and work in sprints, but still operate under fixed specifications, traditional funding models, and hierarchical structures. To address the structure, alignment and governance gaps, a new role of Product Owner was created with incredibly high expectations to magically bridge the gap between old and new ways of working, often without the necessary authority or organisational support.

Is Agile Dead?

The failure of many Agile transformations has led some to declare "Agile is dead." But the reality is that agility is needed now more than ever. Businesses still struggle with inefficiency, poor decision-making, and slow delivery cycles. The problem was never Agile itself—it was the way it was implemented.

A new approach is needed—one that addresses the full scope of Agile transformation, rather than just the easy parts. ZeroBlockers is a framework designed to implement Agile the right way, ensuring that organisations embrace the principles that make Agile successful while solving all of the challenges above.

The failure of Agile wasn't a failure of principles but a failure of implementation. Organisations that have successfully transformed demonstrate that Agile can deliver on its promises when implemented holistically. The challenge for the next decade will be helping organisations understand and commit to the comprehensive changes required for true agility. Without this commitment, we risk repeating the cycle of superficial changes and disappointing results that has characterised many Agile transformations to date.