More importantly, is there any actual evidence that Agile is works better than alternatives?

We eventually moved to Lean (a type of Agile) which worked well with this six-month requirement. It gave engineers the ability to work on different pieces and in whatever order they pleased, as long as everything landed in the six-month block.

Yes, plenty.

I once worked at a CMM level 4 company. Network hardware vendor, before the days that FPGA was really useful. You had to get your shit right, the first time.

Yes. My last company was squarely "Waterfall" (though it wasn't called that) and is moving to "Agile."

This happens to everything. It's a pattern as pervasive as Sturgeon's Law, and may well be related to it. Musical genres come about as a reaction to the excesses of dominant genres, then become a dominant genre themselves. This happens to books, TV shows, movies, video games -- basically everything in modern culture. It even happens in academia and in startups.

The reason for this pattern, is that it's often hard to understand the underlying forces and the cost-benefit factors and incentives that shaped _X_ and _Y_. The solution for getting yourself out of the churn of rejecting the old "paradigm" or whatever and adopting the new, is to understand the underlying forces and react directly to them. If you're going to react and deal only with the surfaces of things -- isn't that kind of the definition of the "Cargo Cult" mentality?

(also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.)

At my last company, Agile was the specific response to smaller competitors having quicker iteration cycles. I think it's wholly appropriate response in that case. Also, at one company I interviewed at, it seems that their version of Agile was going towards the "mini-iterated-waterfall" variant, with the manager advocating that every story be broken down to minute-enough detail that estimates would finally be nearly 100% accurate. Are those mistakes or the right move? Time will tell.

From the article: What Agile actually is remains vague, even more so than Object Orientation ever was, and that’s no simple feat.

Object Orientation is just a vague strategy for code organization. What it actually is depends on the particular techniques and the context of the group actually implementing those. In that, there is a deep parallel to Agile and to religious dogmas and personal philosophy: It's pointless to talk about something so vague, while it's productive to examine specific groups in their success or failure in implementation.

In other words, don't confuse guidelines and techniques for silver bullets and magic. Don't comply with _Y_ just so you can label yourself "Y." Look at your structure of cost/benefit and the team's incentives and figure out how guidelines and techniques mesh with those.

This is sort of a tangent, but does this really happen anymore? I think that you're right, but I can't really think of any genres that have come about in the last 30 years that are a response to the excess of dominant genres. Come to think of it, what you're saying may have just been a 20th century phenomenon. Or maybe as early as late 19th century.

Bzzzt! No. Try again.

Actually, changing costs and cost-benefit coming from advances in technology did have a tremendous effect on 80's music.

https://www.liverpoolmuseums.org.uk/wml/exhibitions/thebeatg...

all successors would seem out of place?

What's out of place late at night in a dark smoky club? It depends. Be in the moment. Adapt! It's the static, dogmatic mindset that is based on the over-application of a fictional timeless comprehension (which can't possibly fit in a tiny human mind) which results in strawman questions like: "Are you saying if we only understood the cost-benefit factors and incentives that shaped music genre _X_ we'd only need on genre of music and all successors would seem out of place?"

Cynefin is great, but it is merely an abstract set of principles.