Agile Is Dead, Long Live Continuous Delivery

This is absolutely wrong, I have seen first-hand people seriously advocating (and actually trying to practice) it, even within the past 10 years.

The thing to remember though is that the 'pure' version of the process (in which you never return to the previous level - hence the name 'waterfall') was regarded as an ideal, not as something achievable. Nobody expected that there would be zero bugs found in testing that would require more coding work (why test otherwise?), but it was regarded as a kind moral failing, to be met with a lot of hand-wringing about why we can't be like real engineers, who never make mistakes &c. And the same applied to revisiting the design or requirements phases.

The next level of idealism held that even if avoiding returning to a previous stage was impossible, you could at least limit it to the immediately preceding stage. As Royce pointed out in the first paper to provide a convenient diagram of the established software lifecycle to cite, this never happened in practice either.

Over time the necessity of doubling back became less of a moral failing and was incorporated into the teaching of the process, without any acknowledgement that the entire concept was fatally flawed. It was also succeeded by several iterative but still waterfall-like processes (starting with Royce's paper and eventually followed by Spiral and RUP). Thus there are many folks who still believe that the pre-Agile process (they may not recognise that there was more than one) was just fine, and that the pejorative 'waterfall' was applied to something that never really existed. In a certain sense that's true, but it gives a completely misleading picture of the history.

Agile's contribution was the idea that any or all of the phases could be happening simultaneously - and, more importantly, that was OK. Plenty of people had been ignoring the orthodox methodologies and working that way, of course, but don't believe anyone who tells you that was an orthodox idea before Agile.

I don't know what to think about it. The gradle.org website screams consulting with its slickness and free user guides/books etc. It does not look like honest, no-nonsense build software.

The source code is about 6000 Java files + 3200 groovy files besides many others. To me it appears excessive and over designed software. I will be very reluctant to use a build software which needs 300+ pages user guide.

TBH it is entirely possible that I just do not work on such complex software projects which needs tools like these.

Agile isn't about predictability so much as it is about 1: ensuring productive work is always going on; 2: ensuring the thing that ships is what the client wants; and 3: ensuring that something functional will actually ship.

Agile grew as a bulwark against the bad old ways of the "enterprise" trenches that led to the original "software crisis". There was a time when big software projects would not deliver, at all, as often as they would succeed. And even when they succeeded they often delivered the wrong thing. Daily builds, continuous integration, using the software itself as the source of truth (instead of elaborately negotiated specs), and focusing on iteration, these are how you can extract productivity from any team, and how you can keep on target and deliver something of value. It's not necessarily the best way, but it's one reasonably reliable way to get stuff done.

I was there in the mid-nineties, and it was absolutely a thing in enterprise style IT.

There were also several books on the matter, and also revised waterfall models. The very term was not always used early on (though around the nineties it did), but the schemes were the same.

Lots of public projects, including some I've been involved, were designed and managed in such a way.

There were no changing requirements until the things were delivered, which could take 1-2 full years. The design phase resulted in monstrous 400 or 800-page documents covering every aspect, and to apply for such a software tender you needed to write those in excruciating detail (I did that too for several projects).

The waterfall model, with the name and all, was also taught at our university (early/mid nineties). XP wasn't even mentioned back then at our level, though we discovered it on our own, reading Fowler, Beck et al in the late nineties.

There's some tinfoil conspiracy theory thrown around that Waterfall was never a thing etc, and it was just used to push Agile etc. I wonder what its adherents did in the 80s and 90s, but surely not programming in large enterprise/public/military etc software projects.

(That Waterfall cannot work is another thing altogether -- nobody did it 100%, as nobody does Agile 100% today).

You're wrong. Look at the responses you're getting, many of us were there in the 90's and if you think waterfall wasn't the dominant method of developing then you just don't know what was going on back then. It doesn't matter if they called it "waterfall" or not, it matters that it's simply what they were doing. Massive requirements gathering and spec writing with development being considered like construction of a blueprint at the end of a months/years long cycle. That's how development was done before agile came around.

Waterfall still isn't dead and will never die because it's how people think by default, plan it all out, then build it. That's how buildings are made and thus it becomes the default methodology of all new managers who don't know what they're doing.