3 Failed agile projects and where they went wrong

Think using Agile development is a surefire way to ensure project success? It’s not that simple. Agile is the software development design methodology that allows developers to do work in small increments (Sprints), and produce client deliverable in a way that allows the project to continue and evolve through an ongoing feedback loop. 

Agile is generally viewed as a way to reduce the risk of project failures, with a 28% greater chance of success than traditional software workflow methods according to PwC. But that doesn’t mean that it always goes right. Today we check out 3 failed projects to see where they went wrong – and how Agile played a large part.

SIREN; An ICT suite for Surrey police

In 2005, Surrey Police Force made the decision to embark on an Agile project to replace their existing crime, intelligence and custody suite. The project was ambitious in terms of its goals, but the police believed the public would benefit from the good of the new system, which was required by this time with their legacy system rapidly becoming obsolete. But it was not to be.

By 2007, scope creep had turned the project into an all-encompassing suite of ICT tools for the police force.  Having already suffered from mismanagement and miscommunication between the provider and the police, which was not a good sign. By 2013, after more than 6 months of deliberation, the project was abandoned (with the developers needing to be paid out in full) at a cost of £15m.

The issues with Agile for SIREN

When the project began, the police had zero experience with Agile development methodology. Even though using Agile can be highly successful due to constant customer feedback, none of the modules that the developers were delivering were being accepted. Instead of changing tactics, this practice continued. 

This combined with scope creep early on in the project lead to complete blow outs of timelines. When finally the project reverted to a known Waterfall methodology it was discovered there were significant issues related to integrating all modules. 

Lessons learned: Clients need experience with at least small Agile projects before embarking on a large project. If there are issues with Agile early on then you need to adapt and change strategy. Know when to use an Agile development environment vs traditional waterfall.

Universal Credit; A welfare system for the UK department for work & pensions

In 2010, the UK government announced their intention to develop Universal Credit. It would be a new welfare system designed to simplify and replace six legacy systems.

While the project itself will wind up being finished – as there is “no practical alternative to continuing with Universal Credit” (NAO Report: Rolling out Universal Credit) – Agile may be jointly to blame for its timelines stretching from 2017 to a now-estimated 2023.

Just last year, there were service centre workers complaining to The Guardian, saying “The IT system on which universal credit is built is so fundamentally broken and poorly designed that it guarantees severe problems with claims.”

The issues with Agile for universal credit

Universal Credit was the largest Agile software development project the government had ever undertaken, plus the department itself had no prior experience working on Agile projects. 

Agile at scale can be tricky if not done right. Clients need to know and understand how Agile works too, not only the software team. Instead of having clear requirements to begin with, the project was to just be developed case-by-case from the ground up – leaving it to Agile to refine the system, according to NAO’s 2013 report. A project of this size developed in that way? Was bound to get into plenty of trouble.

Lessons learned. Don’t jump into a massive Agile project your first time around. Draw up detailed requirements in the beginning if you have legacy systems you can learn from.

Project X; A scheduling system for a large organisation in the energy sector 

An old case but a good one, the tale of a multi-region and multi-vendor Agile project that failed in the eyes of one of the engineers on the project. Why was the project deemed a failure? The project took 3 times as long as anticipated and came in a whopping 5 times over budget.

It was ambitious to begin with. Teams from Canada provided by one vendor, and the US and parts of Europe by another, to come together for a year long project with monthly Agile sprints. The 4 Scrum teams were a mix of co-located and remote staff. 2 of the teams the Scrummaster was a remote role, with on-site presence around once a month. 

The issues with Project X

It’s now 2019 and many companies are only just getting the hang of remote working. Over 10 years ago we didn’t have the same technologies that we do now. That being said; as ‘individuals and interactions over tools and processes’ is one of the key principles of the Agile Manifesto. If communication were placed foremost in a remote Agile project back then, it could have been successful. Unfortunately, it was not.

Communications between teams, and particularly between vendors was fractured and non-time sensitive. Standups were not compliant to Agile practices. On top of that, the non-co-located Scrum master was not effective in their role. The client didn’t have the same expectations of the Agile software development process as Vendor A. In short, their Agile practices lacked maturity.

Lessons learned. Have a clear Agile development plan in advance and stick to it, ensuring everyone is on the same page. As clear communication is essential to Agile. If remote work is necessary then a specific real-time tech communications infrastructure must be used consistently to support it.

The key takeaways? 

The key takeaways here are outlined in the paper Does Agile Work?, with ‘degree of Agile planning’ a predictor and ‘quality of the vision/goals,’ ‘project complexity,’ and ‘expertise’ moderators of project success. Keep these in mind before embarking on your next Agile project.

At 4mation we follow software development best practices and know when Agile is the right move for a project. We coach you through the Agile implementation approach to speed a project along and have better outcomes. If you’re ready to start a new software project then contact us now.