Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.
Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50%.
Waterfall cannot identify those risks without huge experience. Scrum tends to exacerbate some of them. Kanban with sufficient number of phases tends to expose the problem, but not necessarily fix it.
The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.
https://newsletter.pragmaticengineer.com/p/project-managemen...
Two-week sprints seem to be the default in tech, although I've worked at a company that very successfully used one-week sprints. That's completely separate from how strictly companies try to follow "scrum," if at all. I've run into kanban more often than scrum, personally.
Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.
I am a firm believer that one, "does not get chicken salad out of chicken shit." Thus, well ran and well organized companies would produce similar quality of products regardless of methodology, and in the same vein, poorly ran and disorganized companies will produce garbage regardless of the methodology.
Scrum/sprints are kind if like the bureaucratized and ritualized version of that. The Catholic Church to Agile's Christian cult.
The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile.
We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc.
We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.
Both have manifestos.
I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.
All engineers are equal, but some are more equal than others!
Philosophically, agile is more like democracy/capitalism: it decentralises control to teams, where the information and expertise are. Failures in agile are things like "I didn't like using story points".
Waterfall is more like communism: it centralises control away from the people doing the work. Failures in waterfall are things like "we spent millions and got nothing out of it".