One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
I'd like to work in that company.
Try medical software and devices. The requirements and specs are mandatory before doing anything. It’s actually very fun and I have less burnout thanks to this.
I couldn’t disagree more.
In medical I would end up being apart of endless retirement gathering meetings, then draft up the SOW doc only to have stakeholders change requirements when they were reviewing the doc. Then months later once the doc was finally finished and I could do the development, when UAT time finally came, they’d say the build wasn’t what they wanted (though it matched the written requirements).
Most of the projects I saw executed in the last 4 years either got scrapped altogether or got bogged down in political bs for months trying to get the requirements “just right”.
It was a nightmare. You could blame me, or the company, or bad processes all you want, but I’ve never had fun on a waterfall project, especially not in medical. (Though, in my opinion, we are severely understaffed and need like 4 more BAs.)
It's almost like the methodology is less important than the people.
Do you think the problem is that the person driving the requirements doesn't know what they actually want?
I think a good BA is critical to the process because lots of end users have no idea how to put their ideas onto paper.
I also think an MVP helps a lot because people can see and touch it which helps focus their needs.
I would say yes, the problem is stakeholders not having thought critically about what they really wanted from the project.
The motivation for projects were usually “regulatory told us we need to have this new metric for federal reporting”, or “so-and-so’s company can do this, why can’t ours” rather than, “we’d like to increase retention by 6% and here’s the approach we’ve researched to make that happen”.
I ended up experiencing that people in the highest positions weren’t experts in their field, but just people who had a strong intuition. This meant they would zero-in on what they wanted by trial and error rather than logic. Likewise, it meant they were socially adept enough so their higher-ups would never get mad at them when we finished “late and over budget”. People lower on the totem received that blame.
I think humans are just really bad at estimating and keeping their commitments, which is why I enjoy working with agile more. It’s a forgiving framework (imo).
That's because they forgot the meaning of the word agility and want to apply the rules what ever the cost
And also because it's a comfortable cover up for any kind of money saving stupidity. We don't need proper requirements engineering, we're agile. We don't need an operations team we're doing an agile DevOps approach. We don't need frontend Devs, we're an agile team you all need to be full stack. I have often seen agility as an excuse to push more works towards the devs who aren't trained to do any of those tasks.
Also common problem is that still tons of people believe agile means unplanned. This definitely also contributes to projects failing that are just agile by name.
100% my experience.
A lot of places seem to view it as "we just work from the backlog" with no requirements on when features are delivered, or their impacts on other parts of the project.
You still need a plan, goals and a timeline. Not just a bucket of stuff to get done.
Or, even worse, they want to apply some of the rules, cherry-picking bits and pieces of a framework without truly understanding it.
Today, new research conducted for a new book, Impact Engineering, has shown that 65% software projects adopting Agile requirements engineering practices fail to be delivered on time and within budget, to a high standard of quality. By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
All you need to know about this study.
It almost sounds like a project team that is actually and actively looking to solve known and recurring problems instead of "just do whatever everyone else is kind of doing" might be why they are successful.
It's the difference between "how should we go about this" vs "see how we go" regardless of what you label those approaches as.
I think the take away should be:
new research conducted for a new book, Impact Engineering,
By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.
So the people who want to sell you 'Impact Engineering' say 'Impact Engineering' is better than Agile.... Hardly an objective source.
Even if they have success with their 'Impact Engineering' methodology, the second it becomes an Agile-level buzzword is the second it also becomes crap.
The short of the real problem is that the typical software development project is subject to piss poor management, business planning, and/or developers and that piss poor management is always looking for some 'quick fix' in methodology to wave a wand and get business success without across the board competency.
A more proper title would be “study finds 268% higher failure rates for poorly planned software projects”.
“Agile” as a word is mostly an excuse of poor planners for their poor planning skills.
Yeah, Agile isn't really at fault here. If done right - if you've got a scrum master, a proper product owner, proper planning and backlog grooming, etc. - it works really well. The problem is some companies think Agile is just "give the devs some pie-in-the-sky hopes and dreams, let 'em loose, and if they don't give half a dozen execs exactly what they want (despite their massively conflicting ideas on what they want), cancel the project."
In one the worst “poor planning” projects I’ve been in the product owner just kept sneaking in new “high priority” issues to the top of the backlog throughout the sprint. I don’t think we had a single sprint where we ended up with fewer open issues in the backlog than when we started.
Needless to say, he was the main reason why I quit.
In my experience it's just kanban, but make the devs feels guilty between sprints for not meeting their goals.
Agreed. The problem is people mistake “zero planning and structure” to mean “agile”. Of course it fails.
Agile to me was always mini waterfall. You always know who’s doing what, why, and what success looks like on a 2 week sprint horizon. When you see people on a sprint without a clear understanding of what they are doing over the next couple of weeks - then you know your project is in trouble for sure.
I don't have much direct experience working in agile since I tend to work on the business side but I can tell you that the term agile is WAY overused. So many projects are described as agile when they are just waterfall with more steps. Leaders love to say they are working in agile because it sounds 'techy' and cool, but I don't think they fully appreciate what it is vs other methods. I wonder if a lot of the failed projects described in the article are some of those agile in name only kind of things.
An even better title would be "'Study' by firm pushing new technique finds old technique is bad."
If you know exactly what you need, then specs are great. Proven solutions for known problems are awesome. Agile is pointless in that circumstance.
But I can count on one hand the number of times stakeholders, or clients, actually know what they want ahead of time and accept what was built to spec with no amends.
When there is any uncertainty, changing a spec under waterfall is significantly worse. Contract negotiation in fixed price is a fucking nightmare of the client insisting the sky is red when the signed off spec states it's to be green.
Personally, I was never great with agile projects. I get that it’s good for most and sort of used it when I was a CTO but as a solo developer, there are days when I’d rather eat a bowl of hair than write code and then some days, I’ll work all night because I got inspired to finish a whole feature.
I realize I’m probably an exception that maybe proves the rule but I loathed daily stand-ups. Most people probably need the structure. I was more of a “Give me a goal and a deadline and leave me alone, especially at 9am.” person. (Relatedly, I was also a terrible high school student and amazing at college. Give me a book and a paper to write and you’ll have your paper. If you have daily bullshit and participation points, I’ll do enough to pass but no more.)
Stand-ups can become so proforma. What did you do yesterday? I coded. What are you doing today? I am going to code. Do you have any blockers? No. It gets a little repetitive after a while.
Feels like the old php metric. PHP had a ton of great code and successful projects but it also attracted very bad devs as well as very inexperienced devs leading to a real quality problem.
Honestly kinda see thing in a lot of JavaScript applications these days. Brilliant code but also a ton of bad code to the point I get nervous opening a new project.
My point? It may be a tough pill but it's not the project framework that makes projects fail, it's how the project is run.
I witnessed a huge number of failed projects in my 25-year career. The cause was almost always the same: inexperienced developers trying to create a reusable product that could be applied to imagined future scenarios, leading to a vastly overcomplicated mess that couldn't even satisfy the needs of the original client. Made no difference what the language or framework was or what development methodology was utilized.
I feel like that's the same underlying issue: The requirements are not understood upfront.
If a customer cannot give you any specific information, you cannot cut any corners. You're pretty much forced to build a general framework, so that as the requirements become clearer, you're still equipped to handle them.
I guess, the alternative is building a prototype, which you're allowed to throw away afterwards. I've never been able to do that, because our management does not understand that concept.
Does that surprise me? Not at all. "Agile" was never about making programming better. It was a management buzzword from the start.
We once had a manager who came to me with the serious idea "to make the development process agile". He had heard of this in a discussion with managers from other companies. The problem? I'm the only person in this department. I program everything alone. How the F should I turn my processes "agile"?
Isn't it more that people tend to use agile as an excuse for not having any kind of project plan.
It'd be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn't actually experienced in project management.
In my experience It's not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.
I'm all for and good eye rolling at institutional Agile (basically checkered with bad management who doesn't know what to do, but abuses buzz words and asserts Agile instead), but this article has a lot of issues.
For one, it's a plug for someone's consultancy, banking on recognition that, like always, crappy teams deliver crappy results and "Agile" didn't fix it, but I promise I have a methodology to make your bad team good.
For another, it seems to gauge success based on how developers felt if they succeeded. Developers will always gripe about evolving requirements, so if they think requirements were set in stone early, they will proclaim greatness (even if the users/customers hate it and it's a commercial failure).
This article doesn't make any sense. A project's "success" can't really be measured in any objective way like the article is implying. Even saying that a project is "on time" is a vague statement depending on the situation, and it's not a good way to measure the quality of the end result or the efficiency of the development team.
The article even states this is a thinly veiled ad for some other "method".
The agile manifesto is fantastic. Scrum can work wonders as a means for providing a framework to hang "agile principles" onto.
Most organizations don't do "scrum" well or quickly lose sight of the "why" behind it.
Companies are gonna company at the end of the day. Process + bureaucracy + buzzwords + ill-informed management + vendors promises + shit customers/product owners = late projects.
Agile done right, works. The benefit agile has over waterfall(the process it replaced in a lot of places), imo, is that it's predicated on working software, responding to change and working collaboratively/iteratively.
Cries in waterfall.
... I cannot count the number of times at my different workplaces where we had an agile process, dailies and everything else of the agile BS for projects which where either trivial or not solvable. No worries, the managers, product owners and agile coaches made money and felt good, we developers went for greener pastures...
Agile is a scam, nothing they do is based on any facts and when you challenge agile coaches / other people which profit it is always 'I believe' or 'proven by anecdote'.
Combine this with the low quality of people in the average software projects and you have a receipt for failure.
Writing the requirements first at least forces people to think trough a project (even if only superficial), so I am not surprised the success rates for this projects goes up.
Agile has its uses, but like everything you need a bit of both. You need a bit of both waterfall and agile.
Example : you need to have your requirements before development, yes. But how far do you go in your requirements? If i were to make all the requirements for my current project ill still be busy in 3 years and will have to redo bits due to law and workflows changing. however , we need requirements to start development. We need to know what we need to make and what general direction it will be heading to a make correct software/code design.
Agile also teaches you about feedback loops, which even with waterfall, you need to have to know that what youre developing is still up to spec with what the product owner is expecting. So even with waterfall, deliver features in parts or sit together at least once every x weeks to see if youre still good with the code/look/design.
Pure agile is bullshit, but so is pure waterfall. Anything that isnt a mix is bullshit and in the end, it all depends on the project, the team and the time/money constraints.
The few times I’ve been on an agile project it amounted to start writing without understanding what product we’re building.
I'm always sceptical about results like these. I was told that waterfall always failed when I'd worked on successful waterfall projects with no fails. The complaints about waterfall were exaggerated as I think are complaints about agile. The loudest complaints seem to always be motivated by people trying to sell sonething
My crazy wacko conspiracy theory - software development is just a really weird discipline, most of the people in the field are bad at it, and it doesn't have the same amount of standardization and regulation that other engineering fields have, so doing it "right" looks a lot fuzzier than doing, say, civil engineering "right".
The biggest thing though is that most people are bad at it. It's really hard to evaluate high level organizational concepts like waterfall vs. agile when we still have developers arguing over the usefulness of unit tests.
It seems very biased to say the least. A title like that would be ok if it was comparing agile to pre-existing models like waterfall. A valid title for this would have been "new sw development methodology seems to have a much lower failure rate than agile dev. "
ALSO I would like to see the experiment repeated by independent researchers.
As someone who practices agile software development I find this baffling. I've never started a new project without at least 3 weeks worth of research and requirements gathering (and obviously more as the project rolls on). There are seriously companies out there who are like, "Mmm, I feel like this is gonna be an Electron project. Let's just lay the groundwork and we'll flesh out the nitty gritty in a week or so." 😱
what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.
I haven’t read the book they’re advertising here, but I’ve found these challenges to be socially created, not caused by agile.
Not gonna read it because we, elsewhere in engineering land, have been forced to eat Agile shit from the water hose to make us better and faster. Fucking hell! I can't re-compile a mirror if it comes out wrong!
I hope "New Impact" includes hammers.
An Agile Project eh. Like an Agile Waterfall process? cool. Cool cool cool.
I know PMI has an Agile thing but by and large Agile can't be "projects" and vice versa.
Oh well, time to switch back to the waterfall model I guess
lol, no.
This is a most excellent place for technology news and articles.
