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.
One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?
Essentially every project I've worked on in the last 9 years has been agile, most of them Scrum, and almost all of them succeeded in achieving their goals. There's a clear correlation on all of them between the skill of the project manager at applying the agile approach, and how difficult the delivery was.
Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50%.
Usually when agile approaches (kanban or scrum) fail it is because there's an unsolvable bottleneck.
Typically too small team, lacking knowledge or skill for the scope, problematic environment (development or socially) or someone is pushing "done" work causing skyrocketing development debt that quickly comes to a head - typically a prototype remains in production, switching too early to maintenance mode for business reasons.
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.
Most of my career has been working at places using scrum/kanban. And the vast majority of those projects delivered valuable software to customers at the estimated pace.
The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.
It pans out more often than not, which is why it's the default. For now. Eventually something better might come along, but until then, this is working for many, many, many productive teams. Including mine.
Strict Scrum is really not the default in tech. "How Big Tech Runs Tech Projects and the Curious Absence of Scrum" is good reading here & matches my experience.
Who said anything about scrum? The comment was about "agile," of which scrum is only one possible implementation[0]. Sprints are not only found in scrum, but also in other agile approaches, like kanban.
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.
Was it Agile that made this possible, or perhaps the organizational abilities of the companies that made this possible? In other words, if the same organizations used a different methodology do you think the results would be completely different?
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.
In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile.
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.
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".
