It is not uncommon to hear a phrase like this in software development:
Our team does Scrum, but…
Supposedly, some teams are not able to execute Scrum with all its parts. So they compromise by doing Scrum, but the Scrum Master runs the Daily Scrum or something more extreme.
If we look at the Scrum Guide, at the bottom. The End Note says this:
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
It seems from the above that there is no such thing as the fabled ScrumBut, but rather implementing only parts of Scrum is called NotScrum as defined by the guide itself!
Sure, it could make some semantic sense to use “but” in a sentence to explain the way in which your team departs from Scrum. However, NotScrum is an important distinction. At the top under the Definition of Scrum, it says:
Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
Running your team with ScrumBut institutionalizes tolerating avoidance of visibility into the relative efficacy of current management, environment, and work techniques, so that improvements can be missed. The opposite function of Scrum! NotScrum!
Instead, if you run your team with NotScrum, it is made painfully clear the compromise that is in play. It is absolutely possible to get paid to successfully deliver software and not hate it running a team on NotScrum or any other methodology.