The Scrum decline: It's three years later, and I was right
After three decades, the sprint-based framework is losing ground to more flexible alternatives
Something’s happening in software teams worldwide. Most people haven’t noticed yet.
Three years ago, I made a controversial prediction: Scrum would die. The article gained traction. Fierce debates erupted in comment sections and Slack channels. Today, I’m not backing down. The evidence? It’s only gotten stronger.
Scrum has been around for over three decades. It’s not innovative anymore. It’s legacy. Modern engineering practices have evolved far beyond the constraints of two-week sprint cycles. Teams now deploy multiple times per day. They gather real user feedback instantly. They pivot within hours, not weeks. The sprint boundary has become an artificial limitation rather than a helpful structure.
Critics were quick to challenge me. “The Scrum Guide doesn’t forbid mid-sprint deployments,” they said. They’re correct. But here’s what actually matters: the framework’s rigid ceremonies, fixed timeboxes, and sprint-based planning mentality create psychological barriers. These barriers discourage continuous delivery. The structure itself works against modern flow-based development.
The alternatives to Scrum
So what’s replacing Scrum? Kanban offers genuine flexibility with its continuous flow model. No artificial sprint boundaries. No forced batching of work. You visualize your workflow, limit work in progress, and optimize for actual throughput. Simple. It adapts naturally to your team’s rhythm and your product’s real needs.
Then there’s Shape Up, which is gaining serious momentum. Companies are adopting its six-week cycles and hill charts because they solve real problems that Scrum doesn’t address. Meaningful project scoping. Honest progress tracking. Built-in cooldown periods. These aren’t just cosmetic differences. They represent fundamentally better ways to organize product development work.
Scrum is dead, long live Agile
The trend is undeniable: Scrum is declining. But agile thinking? That’s not going anywhere. Understanding customers deeply and adapting quickly to new insights matters more than ever. The difference is that we’re finally moving beyond outdated frameworks to embrace approaches that actually support agile values.
Original Article
That’s a bold statement, given that Scrum is the development framework used in most companies in the world. It has tens, of not hundreds of millions of users. An entire fleet of trainers and coaches is available, forming a new industry just related to a framework.
Beyond its peak
But Scrum is beyond its peak. It is a framework that with diminish in importance and will eventually die.
Scrum is beyond its peak.
But wait, is Scrum not part of the new, agile way of working?
Well, no. Scrum originated in the 1980s, used in the 1990, described to the masses in 2001, and since then became more and more widely used. That means that Scrum is well-known for about 20 years now and your junior software engineer was not even born when Scrum took off! There is nothing new to Scrum by now.
Let’s not examine all the differences between Scrum as a framework and Agile as a philosophy.
But in today’s software world, Scrum is just too slow.
Engineers set up pipelines for Continuous Integration / Continuous Deployment in the meantime. Changes can be applied weekly, daily, or even hourly. That actually happens in productive systems: Companies update their products (especially in the cloud) several times a day.
What good does a Sprint Review every other week do? Why would a Product Owner wait for two weeks until looking at a feature? Why would you plan a delay when something is potentially shippable at any point in time? Scrum is just too slow for today’s software world.
Why would a Product Owner wait for two weeks until looking at a feature?
Is Agile dead?
No, not at all. Agile has gotten more agile. This is why companies conduct experiment, A/B tests and other tools to generate insights. This is possible because people can segment users, update the product, learn, and merge product versions on an hourly basis.
In fact, Scrum has become a preventer of “Agile”. If you want to be agile, do not use Scrum by its book.
Recently, a nice survey showed that “Big Tech” mostly do not use Scrum. I presumed that is (partly) because they are also companies that use quick Continuous Deployment strategies. Instead, they iterate on an idea until it is ready, usually in more agile ways than Scrum.
Alternatives
Of course, you’d expect some alternatives at this point. Well, a good vision is a start. Then you may use a lightweight framework with little overhead and the ability to move fluently without fixed timeframes. There comes Kanban, but recently also Basecamp’s Shape Up methodology.
Conclusion: Ditch Scrum for software project, become more agile!
What I Read
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:
How product companies operate without BAs, Scrum Masters, Release Managers, etc: Qhy you don’t see roles like BAs, Scrum Masters, Release Managers, etc in product-tech companies - and why traditional enterprises need them.
Managing Through Reorganizations: Once leadership has committed to a change, your job is to communicate it as quickly as possible while still being thoughtful.
What do great managers actually do all day? 6 pillars the best managers consistently work on.