It's the other way around: the wisdom was always there and is as true and pertinent as ever.

The claptrap and nonsense is the stuff that was added later, as Agile or as we call it Fauxgile. If you look at it in detail, you will notice that it pretty much invariably violates most of the actual agile principles in the manifesto: they set up plans (epics etc.) to be followed in tools (Jira) following rigid processes (Scrum) enforced by "masters" (really?!) with an entire industry behind them.

Now all of that seems completely farcical, so bad that one almost has to assume cynical motives. But when you go into these teams, it at least looks like they're being very earnest and honest in their efforts, even if they're consistently, insistently, doing the opposite of being agile. Teams/orgs will actively resist and route around efforts to help them become more agile, again while honestly (or at least it seems so) professing their desire to become more agile.

One example was the org that had a regularly scheduled weekly pre-meeting to the regularly scheduled weekly meeting on "how can we reduce process in our org". <raises hands> Ummm...I might have an idea.

Another was an org that was following the highly dysfunctional but extremely common process for mobile development: product managers think of new feature, spec it out, hand it to design, design does screens and then throws them over to engineering.

Raise your hands if you're in mobile development and this sounds familiar.

There's so much wrong with this that I don't really know where to start, but one thing it certainly isn't is "agile". Yet they were very sure they were "doing Agile™". I tried to suggest that in order to get feedback loops going, it might be better to involve development a little earlier.

They thought that was a great idea and instituted a new meeting involving design/engineering/product mgt. before the handoff to design.

Khaaaaaaaaaaaaaaaan!!. I mean aaaaaaaaaarrrrrrrrgggggghhh.

The Gitlab CEO Sid Sijbrandij has also written about this. A lot. Though under the label of "iteration" rather than "agile". These are largely identical. To him, good iteration is possibly the most powerful development technique, but he also writes that it is hard. That is where I think the people difference that I mentioned earlier comes in: for some people this is both extremely useful and also natural and easy. For the other group, the techniques are just as valuable (the reasons why they're valuable are not people-dependent), but don't appear to come naturally.

My guess is that most of the signatories of the AM belong to the former group, and so they thought that all that needed to be done was to free people from the shackles of their dysfunctional processes and all would be good. That appears to have been naive, these waterfall-ish style processes seem to be very attractive and comfortable to a lot of people, while being no less dysfunctional.

And so the coaches/scrum-masters etc. stepped in. And gave their customers what they wanted: a prescriptive "process" for achieving Agile. And since their customers were managers, they focused on management ceremonies, hence Scrum. Which IMHO is not just useless, but actively harmful.