We know the drill – agile is an approach to developing software that aims to satisfy the customer by continuously delivering valuable software. If you look online, you’ll find articles about its appeal everywhere.

But for every successful dream of agile fulfilled, you’ll find another sad tale from someone who couldn’t quite get it off the ground. Aside from simple lack of preparation, I believe agile failure stems from the inability to anticipate the nature of challenges correctly.

Agile failure isn’t an amorphous blob or singular concept. You can distil Agile failure into two categories: failure of implementation, and failure of development. Knowing what both kinds of failure entail is your key to maximising the success of agile transformations.

Implementing agile the right way
Agile implementation failure means failure to adopt. In a practical sense, this looks like an inability of teams to use or acclimatise to new agile ways of working, failure to communicate with or get your customers on board, and failure to ensure a culture of agile exists across the whole organisation.

Not surprisingly, the key to adopting agile successfully is flexibility. Setting a rigid line of “agile” KPIs or rules is often counter-productive. During the implementation process, the chance for teams to experiment with agile processes and find the ones that work best for them should be baked into the transformation timeline.

This is because agile shouldn’t be restrictive or prescriptive – when customer wants and needs are as varied as they are, teams must be allowed to self-manage to best help them deliver business value to the customer.

When working with an agile approach, it’s also important that the whole organisation understands the values and principles of agile. If the development teamwork works in an agile way but the executive team doesn’t, then delivering frequent incremental changes may be blocked or deadlines required when they don’t fit the agile practices.

With that in mind, it’s important to ensure leadership is on board too. Having top-down support for agile processes empowers the development team to find a way of working that suits them best.

Is agile a good fit for your company?
The other way agile fails is in the development process. Although a company may be eager and prepared to adopt agile, the development process can end up becoming convoluted and less effective as a result of moving to an agile approach.

There are some cases where agile just isn’t a good fit. For example, in projects where the deliverable includes detailed design documentation, use-cases or functional specifications, agile assumes these documents will change during deliveries and hence is less effective.

Agile works best in circumstances where it’s easy to talk to and deliver software to your customer. This makes sense: to be relevant, agile work should be done to provide value to the customer. In turn, getting their requirements and feedback on changes is vital to the success of agile.

At Objective, we’re fully supported to use agile methods that allow us to deliver change without worrying when things don’t go as we had planned. Time is allowed to focus on creating good-quality products that are well thought out and well tested. Technical debt is a focus at early stages of development, which means we can keep it under control and eliminate issues before they become significant problems.

None of this is an enforced process; it’s a way of working that our teams have been empowered to develop on our own, with the blessings of top-down management. If customer expectations were to change, our agile process would shift as well. Knowing we have the support to change things means that our initial implementation and our development process don’t fall into the ironically rigid agile trap.

Interested and experienced in agile? Check out our job listings, and be a part of a team that lets you develop in the way you want.