The 5 Reasons Not to Use Scrum
Scrum started with good intentions but went bad
After years of Extreme Programming (XP), I became a Certified Scrum Master in 2007. I’ve introduced Scrum in several companies, in fact, it was often the first thing I did to get order into chaos as a CTO.
Over the years, I became unhappy with Scrum. First, because people did use it wrongly, to implement Waterfall instead of going Agile (Agile is too scary for most companies). Then I became unhappy because Scrum does not work at its core. Remote work then broke the camel’s back.
Here are the five reasons not to use Scrum:
It’s not an engineering process. I once argued Scrum is so good; you can manage everything with it. Indeed, my wife managed her sales department in her startup with Scrum. It should have given me some thoughts that Scrum does not say something about engineering. If you develop software as engineers, have a process that is about software engineering.
Scrum has too many meetings. I hear this complaint a lot; it became a meme. Nevertheless, this is true, especially if you have one-week sprints. Teams often go for four weeks to have fewer meetings, but then they are not mature enough to keep up the pace. At its core, it has too many meetings.
It does not help with the real problem, what to work on. The real problem today is what to work on. Too many teams work on shallow features, on features that don’t take off. And Scrum doesn’t help here. Everything goes to the backlog - it grows and grows and grows. Estimations make the problem harder; people focus on how long it takes instead of what to build. Something that seems shorter gets pushed to the top. Forget that the numbers 3, 5, 8 have no meaning at all, and a developer who said 8 might easily be convinced it to be a 5 - a nearly 40% reduction in time (yeah yeah, I know complexity) - “Ridiculous Poker” as a friend called it.
The good things don’t outweigh the bad things. There are good things in Scrum. The Scrum Master who helps developers along and keeps an eye on the process (though I’d rather have an additional senior developer lead than a Scrum Master on my payroll). A Scrum Master who often takes away ownership and leadership - self-organized teams, ha! The review meeting (which often solves the easy things and then gets stuck on the unchangeable CEO). The daily standups where everyone blocks time to talk, so they don’t need to be interrupted later (seldom used this way, too often people interrupt developers an hour after a standup instead of having been there). Nice things, but you can do them without Scrum. They don’t outweigh the bad parts.
It does not work with remote work. Remote work means interacting better and less often. In Scrum, there is too much interaction. There are too many meetings. Remote Scrum Master, anyone? And it does not help with the new challenges remote work brings, so why use it?
What should you do instead? More important than a development process is a process to come up with great ideas and decide on what to work on. Focus on GitOps, continuous deployments, trunk-based development, and DORA metrics as engineering practices. Instead of a process, have a strong engineering culture. Have a golden engineering vision and an engineering strategy that makes sense. If you insist on a process, try Shape Up from 37Signals.
