Technology

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.

That's because they forgot the meaning of the word agility and want to apply the rules what ever the cost

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.

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.

Pbpbpbp...agile fails fast by design.

The counter from the article is you need a specification first, and if you reveal the system wasn't going to work during requirements gathering and architecture, then it didn't count as a failure.

However, in my experience, architects are vastly over priced resources and specifications cost you almost as much as the rest of the project due to it.

TLDR...it's a shit article that confuses fail fast with failure.

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.)

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.

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.

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"?

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.

Cries in waterfall.

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.

The few times I’ve been on an agile project it amounted to start writing without understanding what product we’re building.

... 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.

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

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.

Wtf is Agile ? I can't get my head around that.

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.

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." 😱

No to all cults in general, as a rule of thumb

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.