That is too bad. When I first read the Manifesto, I said “These folks got it!”
I tend to work that way, now.
Myself.
Things get difficult in teams. Especially cross-disciplinary teams, and aggregate efforts.
Much as we like to denigrate managers (DISCLAIMER: I was one), they are necessary; and not as a “necessary evil.” Good managers can be amazingly effective and well worth it.
Unfortunately, like in any vocation, the good ones are rare. The same goes for good software developers.
The Agile Manifesto was written by a group of working software engineers, with decades of experience, at the top of their game.
Precisely the type of engineer that today’s hiring process tends to filter out. They don’t really represent the current field of practitioners.
Like so many “perfect world” scenarios, the Agile Manifesto was designed for a “perfect audience.” As the article points out, when the manifesto hit the real (imperfect) world, the wheels fell off. To make matters worse, the designers tend to get huffy, and blame the people making a hash of it; which doesn’t make friends. They may be technically correct, but humans are messy, chaotic beings, that tend to have highly individual worldviews, abilities, intelligence, education, experience, workflows, and motivations. Most folks expected to actually implement an objective bear little resemblance to the ones that developed the plan. If the planner fails to account for this, then (in my opinion, as a planner) it’s the planner’s fault.
That kind of sums up human history. Groups of elite thinkers develop a Grand Plan, then it gets bloodied and bruised, once it hits the proletariat. Sometimes, with horrendous results (Cultural Revolution, anyone?).
As someone that actually designed a successful system for the proles[0], I can report that designing real-world solutions for a distributed, heterodox, self-driven, target audience is difficult, messy, unintuitive, humbling, frustrating, and, quite often, absolutely infuriating. Not the kind of work that folks at the top of their game like to do. Frankly, it sucks, but I think that it’s also the best way to make something that actually has a chance.
I wanted to add that follow-through is also important. When I designed the system I referenced, I did it with an understanding that it would be a years-long commitment. It's like having children: Making them is fun. Having them is easy. Raising them, however, is not fun, and not easy.
But we need to do it. For myself, I spent ten years, traveling around, giving presentations, classes, gladhanding, answering questions that I thought "should have been obvious," suffering some withering attacks, and fine-tuning the system, as I realized I screwed something up. I also went around, looking for successors. I wanted to become obsolete (which I have).
But that’s just my experience. YMMV.
[0] https://littlegreenviper.com/miscellany/bmlt/