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.

https://newsletter.pragmaticengineer.com/p/project-managemen...

The category error of thinking scrum is the same as agile is a big contributor to the complaints.

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.

0. https://en.wikipedia.org/wiki/Agile_software_development

I've worked at 3 different companies now where the system worked well and teams moved quickly and created great software.

Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.

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.

This, boring things don't tend to be reported on as much.

The tale of the project launch that wasn’t missed because the client was onboard with iterative delivery?

Agile is a nebulously defined cosmic aura surrounding all software projects in the world that go well.

Scrum/sprints are kind if like the bureaucratized and ritualized version of that. The Catholic Church to Agile's Christian cult.