Why Scrum Fails

This ubiquitous thing called “Scrum” is an oppressive tool for micromanagement. It’s all about story points and velocity. It has earned the utter contempt of developers, designers, product managers, and middle managers alike. The maddening thing about it is that there are well-known solutions to all of these problems, and they can be found in a concise, 14-page document called the Scrum Guide. The Guide is pretty clear about what is and isn’t Scrum: <blockquote> The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. </blockquote> Very few of us have ever actually worked on a Scrum team (as the Scrum Guide defines it), but there’s no shortage of us who’ve worked in Scrum cargo cults. There is no virtue in following Scrum in and of itself. Agility is important, but Scrum is just one way to achieve that. But almost everyone who “adopts Scrum” removes crucial elements that make it work before they begin even a single sprint. This isn’t about a religious devotion to the chapter and verse of the Scrum Guide, but simply understanding how it works. That’s why we use the metaphor of a cargo cult, because we end up mimicking the outward appearance of the system while removing the vital pieces that would make it work. This raises a deeper question, then: why is it that we all follow a process called Scrum, and yet no one actually follows the process that the Scrum Guide defines as Scrum? There are many problems that arise in agile transformations, but I find two passages from the Scrum Guide that come up particularly often <a href="https://betterprogramming.pub/why-scrum-fails-ac92cab05c6a">Visit Now</a>