Why Agile Fails

Agile isn't for everyone, nor is it for everything. Products that require a certain level of quality and adherence to regulations are often more suited to Waterfall. When there are tight restrictions, it's essential that nothing is missed. Agile can work for development of software and services but it's not for companies which produce products that require an elevated level of safety.

Agile is a project management methodology focused on incremental development.

Originating in software development, it has now expanded into other type of product development.

Agile is pro-action! It values tangible progress per iteration in the developmental life cycle, delivering value faster. Consider a group of people travelling from A to B—the agile project management approach emphasises breaking down the overall journey into checkpoints, checking the map often and learning from navigational mistakes quickly. Adjusting the guiding compass to the next checkpoint and promoting feedback at frequent intervals.  

As the name suggests, it is nimble to adapt to changes in the goal post. 

Waterfall project management, on the other hand, is a technique where the progress is linear and mostly sequential. Waterfall relies on having a clear end goal from the start and views development with the perspective of a mostly fixed budget with limited buffer.

With the goal set, from the start, waterfall methodology allows limited scope creep in comparison to Agile and hence is more likely to adhere to the set budget.

Agile Vs Waterfall

Agile isn’t for everything or for everyone

Although flexibility is good especially when companies or product development teams are still defining the end state of a solution simultaneously whilst in development. With endless number of requirements that keep adding to the list, development teams can get stressed. 

We often overestimate what can be achieved in a short period of time and underestimate what we can in the longer term, this leads to inherent complications as product teams try to pack more than what can fit in the smaller deliverable chunks (sprints) resulting in work from previous sprints consistently getting pushed into future sprints or in the ever-growing pile of backlog; never to be looked again. 

Added pressure and over-commitments therefore results in cutting corners where a race to finish the sprint becomes the primary goal, and quality checks become less important. The race starts easily, but the expectations inevitably end up forcing development teams to introduce workarounds with the mindset to fix them in the future and often the workarounds never get fixed, and as a result Agile fails to deliver.  

One can say that the problem isn’t with Agile, the problem is how companies implement it. But our organisations are complex, with work spanning across multiple different teams or divisions. Therefore, the flexible nature of Agile is appealing, adapting guidelines as they see appropriate, but it leads to organisational difficulties.  

Teams are required to track their work, update progress, give and take feedback at regular intervals. All of which requires control, boundaries and discipline. What some people see as tools and ways to collaborate, others see them as administrative work which has no value towards the end goal.  

Emphasis is on motion as the root word “ag” suggests for Agile, but that doesn’t mean to move at such speeds that it creates chaos or confusion. To move and not create chaos, adherence to certain rules or methods is essential. 

Agile is not for everyone, it’s also not for everything. Products that require a certain level of quality, adherence to regulations and policies can often be more suited to Waterfall ensuring those with tight restrictions when it is essential that nothing is missed. Agile can work for development of software and services but it is not for companies which produce products that require an elevated level of safety.

So, what’s next? 

It’s natural to hit the extreme left (Agile), when trying to achieve centre, especially when we have been seeing the pain points of extreme right (Waterfall) style of project management for decades. But changing the hand from right to left does not change the Law of the hammer; it’s still true for either hand. Hence keeping our cognitive bias in check, we should aim for a hybrid approach between the two, embracing boundaries and regulations as required and developing in increments to ensure that we fail fast, and not our Agile approach that fails. 

If you’d like the experience and expertise of a team that understands project management and service design for your team and customers, get in touch with Three6 below or email us at hello@three6.com.au and let’s have a conversation about how we can assist your company get it right the first time!