Scrum Does Not Work (for You)

The software world appears to be split into three fractions. At least, when it comes to Scrum. Everybody likes to be called agile, many claim they are, some say they're doing Scrum. And Scrum saved their projects, fixed their work-life balance, brought back joy and empowerment to the workplace and changed so many things. Scrum evangelists come up with productivity gains by 1000% and more, lossless scalability, a smooth flow of creativity and flawless quality. This is our pro-Scrum fraction. The other side is composed of skeptics, critics and disappointed Scrum victims. They point out every shortcoming of Scrum, especially under special circumstances, in comparison to other methods, or in general. I would call them anti-Scrum. Finally, there's the third fraction - let's call them Scrum-buts. They'd love to do Scrum right, but do not see how they could ever get there in their environment. There are many reasons that prevent them from doing Scrum as intended, BUT with some slight adjustments - specification sprints, separate architects, they could have a process that fits in without disruptions of the old status quo.

As a Scrum trainer, I am supposed to be pro-Scrum. And a Scrum Pro, by the way. But there is more beyond evangelism and the motivation to try the first steps. I am deeply concerned about the general misconceptions about Scrum: Companies inject Scrum into their development units and expect better quality and faster output. Developers argue with their Scrum Masters about tools, rules and rituals, because Scrum was self-organizing. Quality managers wave there QM bibles helplessly, but the flood of defects threatens to drown their testers. The team lead should become Scrum Master. The best developer should become Scrum Master. The worst developer. Well, you see where that leads. I want to clean up with some of these misconceptions to help you to a clearer picture about what Scrum is - and what not. And that Scrum does not - and will not - work for you. That it provides the frame to discover necessary changes in your organization. And the urge and pain to make these changes, if you want to create better products in a better way.