Except at most companies that use Scrum, there are very rigid rules sent down from above regarding the implementation of Scrum. These rules apply to the whole company and can't be questioned or changed via retros.
This is definitely the case for me. I work at a reasonably large (~5-7000 total employees) company that had a top-down Agile Mandate imposed about a year ago. It’s worked reasonably well, honestly, but there was a lot of chafing initially, and there’s still some resistance. Problems with the process are occasionally solved by abandoning it entirely, with mixed results.
The thing to be careful of is that a lot of developers also don't like certain parts of agile, and those don't get used. They may have a preference to continue to use long cycle approaches (code reviews) where a shorter cycle approach is now necessary (pair programming). The end result is they pick and choose the bits they want and end up failing to ever do the process even once, not because its impossible but because it isn't their preference. They didn't do it out of knowledge, infact they failed to see the interplay in the processes working together and how the entire thing feeds together to produce the whole.
I think most teams drop agile practices before they have knowledge to show they aren't appropriate, they usually never get used at all. They adopt what they have to because they don't really want to do it at all because they consider a large chunk of it doesn't work.
Changing the process from a position of knowledge and experience on it is one thing, doing it without that knowledge is the more usual thing and its harmful.