Scrum proponents take pride in the fact that Scrum can work anywhere, in any domain. But keeping it in its generic form leaves big gaps in the practices people should be using.
The result of this is often that people have to reinvent things and don’t have ready access to concepts that would guide their adoption. These challenges are exacerbated when the immutable aspects of Scrum need to be modified a little. What often happens is people try to follow Scrum, often referring to the Scrum Guide and what they learned in their CSM class. They should be using Scrum as an open framework as it’s intended.
Scrum is based on the premise if your company has its proposed values (which you may not, even if you’d like to) and do those things in the Scrum guide (which may not be optimal) you’ll get where you want to go.
By considering the intentions of Scrum and adding core software development practices to it, you can start with a more complete set of concepts to use (e.g., managing WIP, micro-flow, test-first). This shifts teams from following Scrum to using this new “Scrum” as a guide for what to do.