Agile Development Failure rate is crazy high compared to Lean Software Development

Vidas Vasiliauskas ·

2019 - Present Co-founder and CEO @ Teamhood. 2015-2019 Head of software engineering department at Danske Bank. 2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course 2011 - 2015 Managed numerous smaller IT teams at Prewise. Co-founder of RaveIT, Eylean, No Brakes Games Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products. MSc of Software Engineering at Vilnius University. Hobbies: Racing, MTB cycling, Windsurfing

agile project failure rate

The punch line

The internets are going crazy over this recent study conducted by Junade Ali PhD CEng FIET and J.L. Partners published on engprax. And there is a very serious reason. Study writes that Agile development projects had a 268% higher failure rate compared to not using any methodology at all. Secondly, it showed that 65% of projects conducted with Agile failed to achieve time, budget and quality targets. 65% of projects and 268% higher than no methodology!! Those are outrageous numbers. Study also showed that Lean software development failure rate is 7% higher than not using it. No comfort here, still sounds awful…

Can we trust data from this study?

The study saw participation from 600 software engineers (250 in the UK and 350 in the USA). Fieldwork was conducted from 3rd to 7th May 2024. J.L. Partners is a member of the British Polling Council and abides by its rules.

Junade Ali PhD CEng FIET and J.L. Partners

Below you will find one of the data tables provided in the research.

So can we trust this data? It depends. First, we need to recognize that engprax as a company is associated with practice and book called “Impact engineering”. They are using this study as a marketing vehicle. Let’s have a grain of salt there and keep it in mind – they are biased. Secondly, study numbers sound fine on paper. In order to learn something, I will stay away from “impact engineering”.

agile development vs lean development

So what’s the problem?

Study authors argue that one of the most critical contributors to higher failure rate are poor requirements engineering and lack of upfront/early specification. Well that makes sense, when you can specify stuff and you have certainty. What if you cannot do that at least without up front work? First option is that you can split research/figuring out part and doing it part. Then apply Agile on doing it part only and call it a day.

I am already getting ahead of myself. I still would like to have more detailed data to better understand what kind of projects were evaluated, how competent the teams were, what was the track records of doing chosen methodology by those teams. Because, it just depends on many factors. It is very easy to drive results by own intentional bias towards something you are proposing yourself as a better alternative.

My main concern is why such a big gap between Agile and Lean? Kanban and Scrum as concrete implementations of Agile and Lean are often discussed and compared. And there is quite a strong tendency to treat Kanban as an easy way out compared to Scrum. As far as I experienced, in majority of cases (been there myself) it’s just about maturity and how truly you do one or the other approach. Which raises the following questions:

  • Can this also mean that some of the study subjects were those immature practitioners who drifted to Kanban just because Scrum was too demanding?
  • Where they also in the same sample group who responded about failures with Agile?
  • Who were those people and what were those projects which did not have any methodical approach at all?

As you see, there are quite a few questions and I am skeptical that you can easily compare and do such study. Every single time it depends, on many, many, …, many things. Starting from people culture and ending with simple daily tools. My personal 2 cents would be that people probably can contribute 99% of failure impact compared to 1% of tools. Truly competent professionals will succed with pen and paper, I have no doubt. Tools make you faster and better, but they cannot make a race car from a rock.

Some takeaways

  1. Do not blindly follow every study without clear answers. 💥
  2. When doing projects, think about your team, skills, context. Choose wisely how you will do things but do not be afraid to change.
  3. If something does not work, dive deep to discover root cause and switch or endure if need be. But make sure you got to the bottom of the real source of a problem.
  4. Requirements engineering indeed is very important part. It is a worthy discipline on it’s own. Many skip it. Having a conversation directly with future end users can cure a lot of the problems. Agile has ideas how to facilitate that with demos/reviews.
Teamhood uses cookies, to personalize content, ads and analyze traffic. By continuing to browse or pressing "Accept" you agree to our Cookie Policy.