Why the phrase "If Agile Isn't working, you're doing it wrong" is wrong

It has been 23 years since the Agile Manifesto was published, and 20 years since the first book on Scrum was published. In that time, Agile replaced waterfall as the dominant methodology for software development. But despite its popularity, the results are still poor. On-time and on-budget delivery has improved, but when we look at the business outcomes, 90% of features fail to deliver the expected value.

The elements needed for change

We rely too heavily on motivation to trigger change. If we can just convince people of how the new, shiny way of working is better than the old way, then they will change. However, motivation is only one of three elements needed for change. The other two are ability and trigger.

Change only happens when prompts occur above a trigger line. What this means is that we can either push motivation, reduce complexity or do a mix of both.

Scrum became the dominant Agile methodology because it was simple to understand and easy to implement. The latest version of the Scrum guide is just 14 pages long, and that covers all of the roles, events, and artifacts required to build software products. Rather than large-scale changes across the organisation you could just rename your Project Managers as Scrum Masters, your Business Analysts as Product Owners and split up your build phase into 2 week increments.

The managers tasked with implementing the shift to agile are busy building and supporting the products that make the company successful. They don’t have time to think through the intricacies of agile implementations and invest months in convincing people across the company to

“You're doing it wrong”

This lack of clarity has led to the never-ending cycle of agile transformations, followed by "Agile doesn't work" and then "You're doing it wrong" articles. But the problem is there is no guidance on what "the right way" is. Every person has different views and definitions of the same thing.

The fact that companies are not getting the business outcomes they want from Agile is not a failure of the companies, it is a failure of the design of our current implementation frameworks and supports.

As heretical as it sounds to the agile purists, most people don’t think about their processes. They just want to know what they should adopt to improve their performance.

Making it easy

The challenge is that if you want to improve outcomes you do need to make significant changes. Our business case process locks in scope too early so instead we need to empower teams to make decisions. On top of that, we need to make them autonomous so they can release early and often, and we need to change our governance approach to hold teams accountable for outcomes instead of outputs.

These are not simple changes to make. When companies are faced with an existential crisis it can push motivation up enough to trigger the changes. But most companies don’t have that level of motivation. Therefore we need to make it easier for companies to adopt better practices that will actually improve performance.

Introducing ZeroBlockers

We've collated over 800 case studies of how companies are improving their ways of working to create the ZeroBlockers framework. Instead of a 14-page guide we’ve written over 500 pages covering the different team types required, how they work, the artifacts they produce and the principles underpinning their practices.

Instead of asking people to figure out how the process, structural, alignment, funding, governance and scaling elements should work we’ve documented the best practices from our research so people can readily adopt them.

It is opinionated, but intentionally so. We didn’t want to leave the wiggle room that has resulted in so many “fake agile” implementations and scaling frameworks that revert to waterfall ways of working.

We’d love to know your thoughts so please check out the docs at https://docs.zeroblockers.com and let us know how we can make them even better for you.