I've never worked in a supremely functional scrum org, but as others have stated it may only really work if the whole org is on board. In places that I've work

I've never worked in a supremely functional scrum org, but as others have stated it may only really work if the whole org is on board. In places that I've worked there has always been a fundamental tension between how developers/makers work best ("leave me alone! It'll be done when it's done!") and how the rest of the world expects things to happen ("I need to know if it's going to be next week or next year"). I imagine organizations that can take the "it'll be done when it's done" approach are very much the exception. So in the usual case that means that developers have to "waste" a not insubstantial amount of time making plans (that may largely be thrown away) and estimates (that might be off by an order of magnitude), and then course-correct over time (trading off time, scope, and quality) as they learn things while doing the project. The other thing I've found over the course of the last ~25 years is that any kind of system (waterfall, scrum, GTD) is an abstraction that inevitably leaks. It's not somehow provably correct that if you follow a system perfectly that nothing will fall through the cracks. You can either admit that any model of the world is necessarily simplified, or you can keep retroactively adjusting your definitions of things in the model and at some point end up like a game developer treating a subway train as a piece of clothing, or arguing about whether a particular body of water is a "pond" or a "lake".