Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"
First, if that's really true, i'm really happy to see a group that's done so much deep improvement. There are exceptions to what am about to describe, and for those exceptions, i say, "Good for you!"
But what I actually see when i go to gemba (not in a room with managers telling me their state) in almost every one of these cases of claimed advancement is not that they have advanced beyond Scrum, but that something else is going on. What's that?
It's that adopting real by-the-book standard Scrum exposed weaknesses that the group did not want to deal with. And as a variation, the group is demonstrating Larman's Laws of Organizational Behavior and hiding the self-serving efforts by specialists and managers to maintain their privileged status-quo positions. How? By shifting attention away from their desire to cling to the status quo by claiming, "We are more advanced than Scrum", which really means "We don't want to change in any way that would challenge our positions."
So for example, a group of 5 teams working on one product together is actually unable to be disciplined and efficient and effective enough to work in a 2-week timebox and deliver a "done" product increment and ship it. Rather than fix the root cause problems, they shift the problem and say, "Scrum doesn't work here, let's try Kanban." Or, "We're more advanced than Scrum."
Another reason for "being too advanced for Scrum" is not understanding the benefits of the practices.
For example, consider timeboxing. Timeboxing is not a panacea for all product development problems, but it has advantages:
Although there are various advantages to timeboxing, little known except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. AFTER a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
This excuse is most often used to avoid deeply improving and revolutionizing practices. For example, I'll visit a group that says, "Having teams doing the requirements analysis (refinement) is so inefficient." But on looking closely, the real problem is lack of skill, lack of participation, lack of good techniques. Or they are doing complicated and slow planning and estimation techniques; rather than retrospect, revolutionize, and improve, they shift the blame to Scrum.
Sometimes, this complaint comes from not understanding what is and is not part of Scrum. For example, a group will say, "The planning and estimation techniques in Scrum are too heavy." I'll ask them, "What techniques are those?" And they will give some answer. It doesn't matter what the answer is; the key point is that Scrum does not define any technique for planning or estimation. But the group does not know that, incorrectly associates some technique with Scrum, and then blames Scrum.
Another common shifting of blame to Scrum is related to new teams. The organization previously had single-function teams and there is an extraordinary knowledge and skill debt in the group as a result. And massive levels of WIP and handoff waste. But all this is hidden within by organizational systems other than Scrum, which is based on cross-functional and multi-skilled flexible workers. When the group moves to Scrum and the huge knowledge debt (and weak workers) is exposed, there is a lot of learning and improvement to do to addresses those weakness. In the pre-Scrum (or "post-Scrum") group, there's the illusion of local optimization and it seems all very efficient from a local perspective. But from the systems perspective, there are massive weaknesses. But groups don't want to pay down that knowledge debt or address these weaknesses, and then say, "Oh, we have advanced beyond Scrum." Sure. ;)
You've got a group of 5 teams working on 1 product, with true continuous delivery, great code, a real flow of value without pause or impediment, continuous learning and improvement, simple practices, etc.? Great. We in the Scrum community salute you!