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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Join the AMAZING CTO newsletter!
By signing up I agree to receive your newsletters and accept the terms and conditions and data protection

About Stephan

As a CTO, Interim CTO, CTO Coach - and developer - Stephan has seen many technology departments in fast-growing startups. As a kid he taught himself coding in a department store around 1981 because he wanted to write video games. Stephan studied computer science with distributed systems and artificial intelligence at the University of Ulm. He also studied Philosophy. When the internet came to Germany in the 90 he worked as the first coder in several startups. He has founded a VC funded startup, worked in VC funded, fast growing startups with architecture, processes and growth challenges, worked as a manager for ImmoScout and as a CTO of an eBay Inc. company. After his wife successfully sold her startup they moved to the sea and Stephan took up CTO coaching. You can find him on LinkedIn or on Twitter @KingOfCoders

Other interesting articles for CTOs

Best books for CTOCTO versus CTOExperienced CTO CoachEngineering CoachingCTO JobsCTO MentorCTO MentoringCTO NewsletterCTO RoleHow many developers do you need?Outsourcing Guide Product Roadmaps for CTOsHow to become a CTO in a company - a career pathWork from home and remote with ScrumWaterfall and Scrum
Other Articles

Scrum is no longer fit with remote work

How many developers do you need?

CTO vs CEO - how cooperation can work

Keyboard with Display for Developers - Kwumsy K3