Upvoted (although I'm not sure I agree with the last point, but the top 2 are definitely spot-on)
The agile manifesto is tiny and a scrum guide like this one: https://scrumguides.org/scrum-guide.html is readable in a couple of hours. But the version of "scrum" forced on many people is a far cry from that.
For the last one, basically if a process is essentially never implemented in a way that respects the principles it’s designed around something is very wrong.
Yes, I agree. But I'm not sure what you do about that though. Stronger "dictacts" from an international "scrum committee" putting out material telling you what is "correct" scrum and what is not?
The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective. When this is included and is permitted to include not just code/product issues but also process issues, it has worked very well even when they skimped out on other elements of Scrum. But most often the retrospective is absent or the process is not permitted to be included in it. This makes you fundamentally anti-Agile as you literally have a rigid, static process.
The one consistent element that I have found across nearly every reading of Agile I've done and my experiences over the past (now almost 20 professional) years has been that the critical element of agile is its responsiveness and introspectiveness. Lacking those two things you do not have anything that can be called Agile, at best it's an imitation, at worst it's SAFe and you should run fast.
DevOps, Lean, Scrum, Theory of Constraints (realized in software, at least in part, as DevOps) to the extent that they have defined processes they are not the same. But the consistent element is introspection and responsiveness leading to adaptation to the team, organization, customers, and systems being developed/maintained.
This is the critical element missing from many organizations and teams at the time of the manifesto. See Waterfall, any CMMI office. They become static, they delay their feedback loops to extraordinary time frames. Waterfall (may it die a fiery death), in some spectacular failures I've witnessed, had 5 years from start to delivery for customer test, not deployment. CMMI has a strong association with Waterfall (unjust in my opinion), but it still promotes a static process that is only reviewed when it's time for your next appraisal (technically it promotes continuous monitoring and improvement, but like with Scrum everyone ignores it).
It's still a crucial element missing from many organizations who have cargo culted their way into Agile or adopted "Agile" processes (like SAFe, may it suffer the same fate as Waterfall). If your processors ever become truly static, you either found The One True Process (for your team and situation) or you're failing to recognize and adapt to your circumstances.
I find retrospectives demoralizing. I don't want to reherse what we messed up the last 3 weeks every three weeks we allready know that. The constant pressure to "improve" makes you feel bad even though things are going OK.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
I suppose there are good and bad ways to do retrospective. I have seen good ones. I admit I haven't seen many bad ones, mostly because most companies I worked at simply do not have retrospectives at all.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
I think the thing is to go back to the point of the retrospective which is to improve how you're working. You can do that with a regular meeting but that's not the only way to approach things.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.