SlashDot [1] points to The Register [2] which points to ENGPRAX [3], where it claims this was part of the research for a book. Apparently Agile has a 268% higher failure rate than 'Impact Engineering'. What the hell is that? ENGPRAX kindly sell a book [4] for you to find out!
It's like expert witnesses hired by lawyers - you're not supposed to be able to influence what they say, yet unfailingly they tend to arrive at conclusions the people hiring them want to hear.
Alternatively, if you can get clear requirements up front, your 3x more likely to "succeed".
Fun fact: I once talked to a pmo person who claimed that 95% of their waterfall projects finished on time and under budget (but only if you include the avalanches of change requests that were approved 8p% of the way through, a time that somehow corresponded with the software going into test)
I have an idea on this, and I'd appreciate your feedback and opinions on that.
Could it be that agile projects fail more often (or take longer to complete) because people with a different "mindset" are able to work on projects like these because they are being enabled to do so due to a different "way of working"?
Example: We have a shop relaunch going on and marketing is in the lead. Project is almost double over budget and at least two months over time, they fail so set clear expectations and requirements and there's sprint after sprint after sprint to get things to a release-ready state.
Without agile project management this relaunch would have long been counted as a fail and consequences would have followed OR marketing wouldn't have been in the lead because they would not have been able to set expecatations and a clear goal from the start on.
That’s pretty much the entire promise of capital A Agile (Scrum, Safe etc). It provides a framework for people without any knowledge or passion for software development to micromanage software engineers while ignoring agile principles and not bothering to conduct user research or to investigate product-market-fit or do anything else that might be worth doing other than creating extremely loose requirements they pulled out of the ether on a bi-weekly basis. The argument used to refute this is usually that people aren’t doing agile right and if only the people and companies were more competent and or did MORE Agile then things would be fine. Generally speaking successful tech companies don’t often put unskilled dispassionate middle managers in charge of software projects and don’t often use Agile processes
Software development is a lot like photography. If your work sucks it’s because the engineer/photographer isn’t close enough to the subject/user/business goal. Agile tends to silo engineers away from their ideal motivations (users/business goals) in favour of meeting the needs of the egos of management.
One case in point was a hedge fund who had increased their engineering team by a factor of 10 because they couldn’t get any work done after the Agile people took over. Their productivity had stabilised at a pre-agile /10 level. I was part of a group of consultants brought in to build them something because they were so unproductive. The consultancy’s solution was to do MORE Agile. So we ended up building a large but not very useful set of features instead of doing the smaller, more technically complex and much more useful feature. We completed the work on time only because of the generous bonuses offered to the outsourced developers. I believe it was unlikely to be worthwhile for the hedge fund.
> Agile tends to silo engineers away from their ideal motivations (users/business goals) in favour of meeting the needs of the egos of management.
No idea where you get this from. I've never seen teams closer to customers than with agile thinking. Waterfall with a programme manager at the top setting the timeline, the budget and the features, an army of business analysts getting between the team and the customers, and project managers making GANTT charts - you don't think this silos away information?
> The argument used to refute this is usually that people aren’t doing agile right and if only the people and companies were more competent and or did MORE Agile then things would be fine.
> Generally speaking successful tech companies don’t often put unskilled dispassionate middle managers in charge of software projects and don’t often use Agile processes
But do you think this problem is inherent to the agile process itself? We (as in "more technical department") manage to get our things done on time and budget with the same external agency. It might be due to us formulating clear expectations and behaviours and iterating over improvements, but I'd say this whole process of "lots of little steps" works fine for us.
On the other hand, when I think about it right now, we might be doing fine with a more traditional project management process too, because we are able to set expectations... Hm... not sure...
As one who has participated in many Agile teams as both an individual contributor and as a lead/manager I would say Agile adds a lot of complexity and overhead due to the number of people involved--engineers, designers, product managers, etc.
When companies have too much money, they feel they have to spend it, and so they spend it on hiring too many engineers, designers, product managers, etc. And they also feel they have to keep tweaking things when things are good enough to be left alone, in order to justify all the hiring. It's basically busy work on top of busy work.
My most productive times as a programmer was when it was just me and another programmer hammering out 500+ lines of code per day and where we were our own product managers. When you have a team of 10-12, you need to spend a lot of time creating well-sized tickets (that really are ludicrously small) that are doable in the allocated time of the sprint. Then each programmer spends, say 2 weeks in a 2-week sprint, producing about 50 lines of code, testing it, and then deploying.
TL;DR: There are too many hires (engineers, product managers, etc.) and not enough work, so we end up doing a lot of busy work. That is Agile.
Is it also possible that Agile projects recognise lack of product-market fit or lack of technical feasibility faster, because of shorter feedback cycles?
if so, this avoids wasted effort, and is a feature not a bug.
Since it's talking about putting requirements first - arguably if it's possible or easy for a project to have all the specs immediately ready, it is also likely an easier project that has been solved many times in the past.
There are projects for which you can't know everything ahead of time and you need to iterate and seek customer feedback. These are likely more innovative projects, and of course more risky and more likely to fail.
Readit News
[1] https://tech.slashdot.org/story/24/06/06/022253/study-finds-...
[2] https://www.theregister.com/2024/06/05/agile_failure_rates/?...
[3] https://www.engprax.com/post/268-higher-failure-rates-for-ag...
[4] https://www.engprax.com/work/impact-engineering-transforming...
Take it with a huge grain of salt.
Hazardous levels of sodium with this one.
What matters is not the "268% higher" failure rate than whatever they are selling. It's the 65% failure rate of projects using Agile.
That said the true question is how they define failure? Missed deadline? Project stopped? Etc.
Reminds me of the study saying "a teaspoon of honey per day is healthy" with funding from the American Honey Something Association.
Not implying it is true, but there is the possibility that Agile allows you to fail early, fail more often, lose less money, try more things, maybe?
Fun fact: I once talked to a pmo person who claimed that 95% of their waterfall projects finished on time and under budget (but only if you include the avalanches of change requests that were approved 8p% of the way through, a time that somehow corresponded with the software going into test)
Study finds 268% higher failure rates for Agile software projects - https://news.ycombinator.com/item?id=40584901 - (170 comments)
Could it be that agile projects fail more often (or take longer to complete) because people with a different "mindset" are able to work on projects like these because they are being enabled to do so due to a different "way of working"?
Example: We have a shop relaunch going on and marketing is in the lead. Project is almost double over budget and at least two months over time, they fail so set clear expectations and requirements and there's sprint after sprint after sprint to get things to a release-ready state.
Without agile project management this relaunch would have long been counted as a fail and consequences would have followed OR marketing wouldn't have been in the lead because they would not have been able to set expecatations and a clear goal from the start on.
Any ideas on that?
Software development is a lot like photography. If your work sucks it’s because the engineer/photographer isn’t close enough to the subject/user/business goal. Agile tends to silo engineers away from their ideal motivations (users/business goals) in favour of meeting the needs of the egos of management.
One case in point was a hedge fund who had increased their engineering team by a factor of 10 because they couldn’t get any work done after the Agile people took over. Their productivity had stabilised at a pre-agile /10 level. I was part of a group of consultants brought in to build them something because they were so unproductive. The consultancy’s solution was to do MORE Agile. So we ended up building a large but not very useful set of features instead of doing the smaller, more technically complex and much more useful feature. We completed the work on time only because of the generous bonuses offered to the outsourced developers. I believe it was unlikely to be worthwhile for the hedge fund.
No idea where you get this from. I've never seen teams closer to customers than with agile thinking. Waterfall with a programme manager at the top setting the timeline, the budget and the features, an army of business analysts getting between the team and the customers, and project managers making GANTT charts - you don't think this silos away information?
> The argument used to refute this is usually that people aren’t doing agile right and if only the people and companies were more competent and or did MORE Agile then things would be fine.
> Generally speaking successful tech companies don’t often put unskilled dispassionate middle managers in charge of software projects and don’t often use Agile processes
But do you think this problem is inherent to the agile process itself? We (as in "more technical department") manage to get our things done on time and budget with the same external agency. It might be due to us formulating clear expectations and behaviours and iterating over improvements, but I'd say this whole process of "lots of little steps" works fine for us.
On the other hand, when I think about it right now, we might be doing fine with a more traditional project management process too, because we are able to set expectations... Hm... not sure...
When companies have too much money, they feel they have to spend it, and so they spend it on hiring too many engineers, designers, product managers, etc. And they also feel they have to keep tweaking things when things are good enough to be left alone, in order to justify all the hiring. It's basically busy work on top of busy work.
My most productive times as a programmer was when it was just me and another programmer hammering out 500+ lines of code per day and where we were our own product managers. When you have a team of 10-12, you need to spend a lot of time creating well-sized tickets (that really are ludicrously small) that are doable in the allocated time of the sprint. Then each programmer spends, say 2 weeks in a 2-week sprint, producing about 50 lines of code, testing it, and then deploying.
TL;DR: There are too many hires (engineers, product managers, etc.) and not enough work, so we end up doing a lot of busy work. That is Agile.
EDIT: to fix typo.
if so, this avoids wasted effort, and is a feature not a bug.
There are projects for which you can't know everything ahead of time and you need to iterate and seek customer feedback. These are likely more innovative projects, and of course more risky and more likely to fail.