> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished"." I think this is a key insight, and I suspect for many people (myself included), the phrase you use when you say "Low-end Scrum" is just the only type of widespread Scrum we've ever seen practiced anywhere, ever, to the point that it makes us question whether Scrum itself is partly responsible, even in an idealized format. One of my good friends came up with the idea he called "barriers to anti-quality" to describe this. A good workflow process establishes inviolable norms that act like preventative barriers to doing things in an anti-quality way -- so that you specifically arrange the world such that trying to take a quality shortcut actually costs you more than just doing it in the quality way. We proposed trying to judge workflow and management practices based on how willing upper management was to give up control of the process in exchange for erecting barriers to anti-quality. If they wanted to force a team to pivot in some quality-destructive way, just on their whimsical preferences for reprioritizing different tasks according to vague business needs, they could not do it. Barriers to anti-quality would be like Odysseus pre-committing to be tied to the mast, so then when the Siren song comes, he cannot give in the temptation. I think a lot of the spirit of early Agile was meant to suggest something like this. Even though the method talks about being flexible and adapting when there are real business needs to adapt to, this gets bastardized when middle and upper management conflate adapting to real business priorities, and begrudgingly paying a cost in terms of quality lost due to pivoting developers, with demanding that people have to adapt to the management flavor of the month, unsubstantiated ideas about business priorities, often stemming from political power struggles, restructurings, quarterly earnings, etc. etc. What I really wish Scrum or Agile had, was a more unbreakable way to let development teams say no, and decline work or decline pivots. Basically to veto changes made to the backlog, and say that it violates an anti-quality principle for no good reason. A key failing of modern Agile / Scrum is that it doesn't create any type of stop-increasing-our-entropy-with-unsubstantiated-management-preferences notion of a barrier to anti-quality. Don't get me wrong, this is hardly a failing that us unique to Agile / Scrum. But I think when people talk about why in principle these methods fail, it's that they lack any mechanism of enforcement for this. As a result, they can be so easily politically subverted to just be a pivoting, bludgeoning tool of misguided or unexplained management choices, that almost always trade-off quality for anything else, and instead of ever looking back to understand when an under-investment in quality actually cost them, they just explain it away as some other team's fault. In a sense, Agile / Scrum (or 'Low-end Scrum' as you call it), is a tool to create managerial Dutch books. A manager gets to unilaterally disrupt on-going investment in quality without ever being held accountable when that gamble on short-term anti-quality causes losses. By the end, it makes developers very cranky that they are being jerked around with all this prescriptive and time-wasting overhead of meetings, planning, estimating, etc., only for this political anti-quality nonsense to go uncorrected anyway. If that's going to happen anyway, then what's the supposed value of all that costly Agile-specific overhead?