Note that this is failure to deliver on time, not failure to deliver full stop.

I also think a lot of places claim to be agile, but don't follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what's in the agile manifesto and claim that it's a representation of what it says.

Maybe that's a fundamental problem with agile. It's just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it's just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.

For anyone that wants to refresh their memory on the agile manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."

Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.

One Agile developer criticized the daily stand-up element, describing it to The Register as "a feast of regurgitation."

The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.

The study's sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don't adopt agile if you were already successfully delivering projects.

Agile went through the mgmt human centipede and now it's an unrecognizable broken system built on conflated ideas. I bet a good number of those projects are 'agilefall' anyways.

According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.

Is this not self-evident to most teams? Of course you will not reach your destination if you don't know where you're going.

It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.

It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.

Right off the bat i read

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."

You need clearly defined requirements to write a good user story. Documentation comes after.

However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.

Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.

However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.

I liked agile as it was practiced in the "Extreme Programming" days.

• Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.

• Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.

• Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.

.

But it's just a corporate buzzword now. "We're agile" often enough means "we have no plan, take no responsibility and expect the team to wing it somehow" or "we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers."

Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the "project owner") are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.

Maybe we need a new term or an "agility index" to separate the cases of "incompetent manager uses buzzword to cover up messy planning" from the cases of "project owner with a clearly defined goal creates a low-bureaucracy work environment for his team." :)

I've literally never actually seen a self proclaimed "agile" company at all get agile right.

If your developers are on teams that are tied to and own specific projects, that's not agile.

If you involve the clients in the scrum meeting, that's not agile.

If your devs aren't often opening PRs on a variety of different projects all over the place, you very likely aren't agile.

If your devs can't open up a PR in git as the way to perform devops, you aren't agile.

Instead you have most of the time devs rotting away on the sane project forever and everyone on "teams" siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because "they worked on it so they knpw how it works"

Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.

Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.

Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.

A really helpful metric, to be honest, of agile "health" at your company is monitor how many distinct repos devs are opening PRs into per year on average.

A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.

I’m curious what they mean by “failure.” I read the article but didn’t get a clear definition. Isn’t one of the expected outcomes of agile the ability to experiment rapidly and move on when the experiment fails?

So what if you fail 300% more? If you’re able to get 300% more ideas to the stage where you can test their viability, then it’s a success.

With 65 percent of projects adopting Agile practices failing to be delivered on time

They're not "failing to deliver", they're being Agile in disappointing everyone involved!

Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

Which shouldn't surprise anyone, but I know some managers, directors and users loathe the idea of the people who'll do the actual job having any say other than "yes, sir".

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.

Good documentation is critical and process-agnostic. If people can read and understand it, it's good. It's something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.

Agile is LinkedIn religious bollocks. Might as well just pray. Bunch of corporate nonsense.

BUt YoUrE NoT DoINg it RIghT!!1!

Should be reciting the creed in Latin, presumably.

Fail fast baybee

I just hate how companies cling to agile like it's some kind of cult. Like a company I know gave all the employees very nice swag embroidered with a big "agile development" slogan on it like your development methodology is supposed to be a source of pride or something. Of course like most companies they don't really follow agile practice very much except where they can use it as an excuse to skimp on requirements and such.

Hum... That implies that at least 30% of some subclass of projects are successful.

Not to mention that this Agile methodology is burning out people pretty fast. It puts a lot of pressure on developers.

Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it's a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I've been exposed to. No days or weeks of design meetings, just "hey we want this feature" and it's in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.

Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

I'm not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.

A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

Again, not sure how shipping with bugs is an agile issue. My understanding of "fail fast" is "try out individual features to quickly see if they work instead of including them in a large update", not "release features as fast as possible even if they're poorly tested and full of bugs." Our team got itself into a "quality crisis" while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.

The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book "Impact Engineering," conveniently available on Engprax's site. Not to say this necessarily invalidates the study, or that agile hasn't had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he's no hack when it comes to engineering.