What people really mean is, if they can leave out certain Scrum elements in their specific Scrum implementation. Well, it's their company, so of course they can - but then they are no longer doing Scrum and have to rename their process to something else. Besides, they will most likely miss the benefit of the element they are ditching.
But do you have to follow Scrum forever, even after you have truly mastered Agility in your enterprise? Of course not.
Scrum is a tool, like a hammer. Once it served it's purpose (the nail was driven into the wall), you can put it away (stop using Scrum).
I mean, our goal is after all to improve the profession of software development (or of all knowledge workers in my case), increase the job satisfaction of the people and increase the return on invest for our companies. In my opinion, this means to transform organizations to become agile from the heart. Once they are there (and sustainable!), they are like grown children and can make their own decisions. So, sure: If they really know what they are doing, they can abandon Scrum.
BUT: None of my customers has reached that sustainable state so far. They usually are in a advanced learning stage (or even early beginners) when they decide to abandon some practice and tend to fail once they do so. Therefore, whatever they want to change, I never allow them to drop retrospectives and analyze with them what happened after they altered something. So far, they always went back to Plannings, Daily Scrums and so on.
Usually, if somebody wants to deviate from Scrum, that person is trying to cover some dysfunction instead of solving it's root cause. Let's take an example: A short while ago a development Team came up to me and told me that they had decided to stop doing Retrospectives. I asked them to come together the same day and worked with them on the root causes for their decision (so yes, I did a Retrospective with them even though they had decided to stop doing those - I apologize, guys!). The result was a deep frustration with their organization because everything that had to be changed outside the Team took ages and always got watered down to tastelessness. The Developers felt that the organization was not appreciating agility, or even their employees. "We are just numbers," one colleague said. And he was right.
In the end we continued to do retrospectives and tried to work harder on the corporate culture. This process is still going on and will most likely take another 7-10 years.
Whatever problem set we are talking about, you have to use the right process for it. Scrum is an empirical framework made for complex problems. If you try to apply it on simple problems, there is a mismatch. The same is true when you try to deploy predictive processes on complex problems. It just doesn't work the way it should. The same is true for corporate and personal values: Some value sets (or "cultures") will produce better suited solutions for specific problem sets than others. You can find out if there is a mismatch by looking at the success rate of your projects. If you encounter a bad yield rate (<90%), try to reflect on your problems, solutions and culture. Maybe you are using the wrong process. Maybe you are looking at your problem from the wrong angle. Maybe you should get up, spit into your hands, and solve your root causes without trying to apply the tools that led to the high failure rates in the first place.
