You might have heard someone use this characterization to describe what flavor of Agile their organization is following. “We’re doing Scrumbut Agile.” This is to say that they started with the Scrum framework, but now they have drifted away from a pure Scrum approach to something else. We have other names similar to Scrumbut, like Scrumban (used to describe a combined Scrum and Kanban approach) or Scrum/XP (Scrum with XP practices included). Because we like to name things, this is what we do.
Because Scrum is the most popular methodology being used sometimes we equate Scrum as the base definition of Agile. But Agile is not Scrum and Scrum done very rigidly is also not Agile. A traditional mindset is a mindset of knowing. When you say to someone, for example, “You are not doing it right.” This is coming from a mindset of knowing. You've read the book on Scrum (the Scrum Guide) and the things they are doing are not exactly as described in the book. Agile, however, espouses Evolutionary Development which flows out of a mindset of learning, and Scrum does not advocate against it. Evolutionary Development, as the name suggests, refers to the learning process of taking something described, perhaps in a book, and then evolving it to make it successful.
When you’ve done this and have something that is successful but it doesn’t look like the thing that you started with, some observer could say “You’re not doing it right.” That person, IMO, is not Agile. A better line of reasoning would be, “Oh, I see you’re doing it different that it is described in the book, how is that working for you?” If the answer is that it’s working great and we’ve solved these problems by doing it this way, and we know that we’re not doing as written but for some really good reasons, well, then you are doing it right. So, what are you going to call this new thing? Maybe Scrumbut.
Now, is there a downside to Scrumbut? Yes. When you drift to some approach that doesn’t produce the desired results, but there is just too much difficulty getting the right thing implemented, for whatever reason, then your compromises might be coming from inconvenience or some other form of laziness and lack of discipline. Maybe you just haven’t put in the effort to understand the impact of the things you are doing and the results that they produce. A typical compromise is not having dedicated teams. This comes from more traditional, siloed organizations where people are farmed out to assignments rather than work being given to a team and the team figuring out how to deliver. This practice more frequently does not lead to the desired results that represent the reason for doing Agile in the first place. But we might say, “that’s just they way it is” and “we can’t change some things”. Well, OK, but then you need to understand that it’s not Agile that’s failing, it’s your unwillingness to make the hard changes that is failing Agile.