Why Agile projects fail

It’s pretty much impossible to have not worked on or alongside an ‘Agile’ project.

Why? Because Agile is no longer the preserve of start-ups and software development companies, it’s mainstream, and a subject of conversation for the CEOs of multinational companies worldwide.

But the ‘promise’ of improved speed to market and lower costs is not always realised, supplanted either by the speedy launch of sub-standard products or a painful and costly cycle of constant rework. Agile must be the bad guy! In this short opinion piece, I argue that misinterpretation of the word Agile, and misapplication of Agile principles in the delivery of design projects, is driving unjust negative PR; and that a few small tweaks can lead to significantly improved outcomes for you, your business and your clients. 

Agile is no longer the preserve of start-ups and software development companies, it's mainstream, and a subject of conversation for the CEOs of multinational companies worldwide.

Breaking down Agile

Use of the word Agile, with a capital A, increased dramatically from 1994, consistent with the gaining popularity of Agile software development methods and the 2001 publishing of the Manifesto for Agile Software Development. Whilst it’s very easy to become consumed by the technicalities and subtle differences between the many methodologies, Agile doesn’t need to be complicated, nor should it be taken too prescriptively, for I believe it helps to think of Agile more philosophically. Agile, put simply, means to move quickly and nimbly with ease and grace. 

Where does it all go wrong? 

Just five minutes of googling can find you a whole host of Agile horror stories. But in my experience, Agile projects fail not because of some huge blunder or technical flaw, but usually due to the early mis-setting of expectations. I believe there are three key expectations, tied to the values and principles outlined in the Manifesto, that should be clear up-front during the sales process and re-set early in the project lifecycle.

The first is the concept of the minimum viable product (MVP), the lynchpin of Agile delivery. Do your clients understand that focus will not be on delivering the full product, but on delivering a product to market as quickly as possible? If not, then your delivery will not meet client expectations, and your Agile project will fail. We do this because we believe that seeing an early version of a product live in its natural environment, interacting with real customers, allows us to learn much more about how to develop that product further than some internal environment tested by over-fussy clients. It’s really important that we don’t see this as a failing to deliver quality product, a typical concern of practitioners and account managers alike, but rather a method of delivering the right product as quickly and cost-effectively as possible.

The second is the importance of planning and prioritisation, and the client’s role in it. A common misunderstanding of Agile is that it is fluffy and unstructured, where anything goes. However, in order to get a product to market quickly, our clients need to understand that the product doesn’t need to be all-singing-all-dancing, rather a Product Owner, with the authority to make decisions quickly, should identify only the key features required to hook early customers and validate the core value proposition. It is the job of those selling and delivering Agile projects to help clients understand that compromise is a friend not a foe, and to make prioritisation of features, through sprint planning and backlog refinement sessions, feel like an inclusive and exciting, not a limiting, exercise. 

The third is helping your clients to understand that they don’t know what they want. How can a single Product Owner know, with confidence, every detail about the product they think their customers want? They cannot, it’s unrealistic to think they can, and that’s the beauty of Agile. Let us not waste time trying to define the perfect solution, instead we should be inviting real customers, through focused Design Research, into the process of defining product requirements, iteratively over time.

In my experience, Agile projects fail not because of some huge blunder or technical flaw, but usually due to the early mis-setting of expectations.

Tweak your way to success

Failing to set expectations effectively is undermining the success of our projects, leading to an understandable, but unjust, condemning of Agile methodologies. I recommend a number of small tweaks to improve the success rate of your Agile projects.

To sales folk, ensure a practitioner with experience of Agile projects is involved throughout the sales process. Your clients must understand the values and principles of Agile when buying an Agile project. They may not be able to commit to the expectations we have of them, and as such Agile may not be the best way to go. Better to find this out before contracts are signed and delivery teams are underway.

To practitioners, embrace the kind of relationship with your clients that Agile projects demand. Forget being a supplier and embrace the partnership. Co-locate with your clients, bring them into your meetings and ceremonies, be prepared to challenge them and, metaphorically, spoon-feed them where necessary. If expectations have been set correctly during the sales process, your clients will welcome this level of engagement, and the closeness you form with your client and their business should become a rewarding learning experience for you too. 

And finally, if your agency is new to Agile, hire an Agile Coach. The cost of failed projects amounts to a lot more than the cost of three-six months of a professional consultant.