First, I think there is no other reasonable way to run a company than to assume that everyone is acting in good faith. Most people are. Weed out those that cons

First, I think there is no other reasonable way to run a company than to assume that everyone is acting in good faith. Most people are. Weed out those that consistently are not. Trust but verify. The other remarks are all good responses to "cargo cult" Scrum. No, it's not about death-marching the teams, it's about keeping a sustainable and realistic pace by time boxing activities, and constantly assess the velocity. The end goal is to increase predictability and reduce the number of concurrent activities in all stages of the "delivery pipe". Limiting the Work In Progress is a "Lean" thing. Managers should have a goal and identified the needs, but premature detailed planning should be avoided. (Also a "Lean" thing) "All jobs now belong to developers" is clearly not ideal but probably a reaction to a high ratio of non-developers which is typically not a good thing if the main product or services are software or produced by software. I'll give you that dividing complex deliveries with many dependencies can be very hard - you probably can't plan or replace infrastructure in 3-week increments, but measuring and possibly delivering some sort of value in 3-week time-boxes is most likely doable, although realistically you'd probably go live in larger chunks. You still need a plan and most important a goal though. One reason to be a bit fundamentalist here is to challenge the structures within a product or a company - maybe the bottlenecks just get more visible? Is it possible to divide complex behemoths into smaller parts, for instance? Maybe centralized solutions drives down fixed costs while increasing dynamic costs - those are typically much harder to understand.