The World Is Moving Beyond Scrum
How elite teams solve customer problems with software
Scrum, the world's most popular development framework is beyond its peak. Here's why that's actually good news for tech teams everywhere.
The end of an era
Remember when Scrum was revolutionary? That was two decades ago - before your junior developers were even born. Today, this aging framework is holding companies back from true agility. Big Tech has already moved on.
Why Scrum is too rigid for 2025
Continuous Integration/Deployment is the new normal.
Two-week sprint reviews before a feature can go live? That's prehistoric.
Your competitors are shipping features hourly.
For many teams, Scrum is too much overhead.
Estimation, velocity and planning usually don’t work as intended.
The real problem
Here's the irony: Scrum, designed to make teams agile, has become the very thing preventing true agility. Think about it - why would you:
Wait two weeks to review a feature? (Scrum does not force you to wait, but many Product Owner do.)
Force artificial timeboxes when coding/learning/adapting can happen anytime?
Add unnecessary process layers in a real-time world where people are collaborating all the time?
Not include discovery and understanding into the process?
I get it: Scrum lets you play it safe. Nobody gets fired for choosing Scrum. If you're an agency or a consulting firm, of course you're going to set up a Scrum process, because that's what everybody does. Customers just don't question it, even though they should.
What elite teams are doing instead
The future belongs to companies that:
Run rapid experiments, A/B tests, and prototyping
Deploy continuously without sprint boundaries
Use lightweight frameworks like Kanban
Embrace modern methodologies like Shape Up
In fact, I once almost joined a company using their own version of Shape Up. They identify one or two of the most important problems and commit to solving them. Then they spend several weeks of real collaboration on discovery, understanding the problem, finding good solutions, selecting one of the solutions, building prototypes, validating the prototypes, and delivering the final code. The result is:
Real problems get solved.
You can see the metrics moving during the cycle.
More time spent on value-adding activities and less time spent on artificial meetings and calendar dates (at least, people often perceive them as artificial).
The Path Forward
The most innovative companies have already figured this out. They've ditched rigid Scrum ceremonies for truly fluid, responsive approaches, prioritizing problem understanding and collaboration. The question isn't whether Scrum will die - it's whether your team will be ahead of the curve or playing catch-up.
Take Action Now
Don't let your team fall behind. The future is lightweight, continuous, collaborative, empowered, and truly 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 >800) at https://www.digital-product-management.com. These are today’s picks:
AI transparency framework: Deciding when and how to disclose our use of AI-based tools.
How to Lead Your Team when the House Is on Fire: Leading low-morale teams through ambiguity, hard constraints, frequently changing goals, and intense pressure to perform.
Why Changes Take So Long: A sample explanation why changes/features takelonger than people assume.
I started reading this post with the expectation that the author would have an opinion about what else we could look into as inspiration for Scrum.
But got disappointed midway through because there's no opinion on what better other than "not-scrum".
I didn't read any consideration of real alternatives, like Kanban, or XP, or FDD or anything else.
The only mention to ShapeUp (the 37signals process which is basically a "we just like 6 weeks better"+ small changes when compared to Scrum) is quite brief and does not show how the author thinks ShapeUp would improve the situation.
Then there's the "less meeting" passing comment, but no suggestion on what is the right level or number of meetings.
I was very disappointed by the end, as I expected to have an opinionated view on Agile software development, but left the article with a sense of lack of resolution.
I would encourage the author to publish his ideas about the solution. We can have a chat on the Scrum Master Toolbox Podcast or at the Global Agile Summit.
We must reassess our ways of working, but let's design experiments, and inspire others to try them. We need more.
Scrum is a great training wheels framework. It helps you move on from waterfall and adapt to iterative development.