No fucking shit. Nobody can do Agile right. I would argue that if something is so hard to get right, then it is effectively worthless.
Note that while we call what they are doing waterfall, in fact it isn't. All (nearly all?) projects are doing releases. They do go back and change things made in the past, just that the timeline is very long. They do discover things are not working and stop - sometimes they don't realize this in time to stop early, but they do stop.
What the world needs is a process for large numbers of people to develop software without stepping on each other. I do not have an answer to this problem - I'm not even sure if it exists.
I’ve worked in plenty of teams that did this sort of thing. All different. And at different scales - startups to big tech to game jams.
The motto is "individuals and interactions over processes and tools" because if a process or tool isn't working for you, you're not supposed to use it.
It's like communism in the sense that it's defined with all the good quantities you'd want in a society or workforce and has several conflicting methods to get there. It's a set of principles that invites people to argue about how their approaches fit into them. Maybe that's the point.
And most teams get the core ideas right in my opinion: small, tight knit teams working closely together, with a "reduced amount" of process (yeah, think the number of meetings in agile is bad, in waterfall, meetings seem like crush you like a tsunami).
The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.
Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.
It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.
I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.
In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.
The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?
Agile always fails because it's undermined from the inside.
Communism always fails because it's undermined from the outside.
Points, t-shirt sizes, figmas, etc... these are _tools_ and _processes_. Why the hell are you complaining about it when it says very clearly that you should focus on people and interactions?
Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way.
Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions.
In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people.
C'mon, it's not that hard. Doesn't need to have strict rules.
Which team? My team of 5 people or the entire project of several hundred? Focusing on the small teams finds a lot of local maximums that are very bad for the entire project. Many of the small changes small teams want to make are not possible because they would impact some of those several hundred other developers. Often small pain for us is much better than the pain our change would force on those others.
As I mentioned before, there is no one size fits all recipe. And there are no multiple recipes of different sizes.
There are infinite variables a group of people can express. There is no point in making recipes, agile is about ideals.