It’s 9:57 a.m. and I’m watching someone update a Jira ticket to “In Progress” so they have something to say in the stand-up at 10:00. Welcome to Scrum in the enterprise: a play we all agreed to star in, long after the plot stopped making sense.
I’m not here to burn Scrum to the ground. It served its purpose—just not the one it thinks it did. It helped kill off waterfall. It gave developers permission to talk to stakeholders more than once a year. And it introduced the radical idea that shipping working software might be more useful than delivering a 40-page Gantt chart with a straight face.
But Scrum hasn’t aged well. These days, it’s too rigid, too mechanical, and too easy to fake.
Let’s unpack that.
The Agile Manifesto Was a Declaration, Not a Method
Scrum was never supposed to be the agile process. It was just one of several interpretations. A lightweight framework. An experiment.
And like most experiments in corporate settings, it calcified.
Now we have product owners who don’t own products, scrum masters who aren’t empowered to master anything, and teams who spend more time grooming backlogs than building features. Every two weeks we engage in a sprint ritual, deliver… something, and act surprised when business outcomes stay flat.
We’ve mistaken the presence of a process for the absence of a problem.
Velocity Is a Lie
Scrum encourages us to track “velocity.” This is a fancy word for “how many made-up numbers we completed this sprint.” In theory, it helps with forecasting. In practice, it incentivizes point-padding and over-splitting.
- Got a 5-point ticket? Break it into two 3s and a 2.
- Want to look productive? Always finish just enough to beat your last average.
- Need to justify your burndown chart? Defer testing until the next sprint and mark it “done.”
It’s gamified project management, but nobody’s winning.
Meetings About Meetings
Daily stand-ups. Sprint planning. Backlog grooming. Retros. Demos. Stakeholder reviews.
Scrum promises “just enough process,” but somehow we’re all booked from 9 to 3. If I wanted to spend half my day in status meetings, I’d go back to waterfall—at least their meetings had chairs.
The most productive hours I’ve had in a sprint often happened in spite of Scrum, not because of it. Between the interruptions. After the stand-up. Before the retro. You know, when we actually got to work.
Cargo Cult Agile
The real problem isn’t Scrum. It’s how companies use it.
Scrum, in name only, is everywhere. Teams follow the rituals but not the principles. Product decisions are still top-down. Technical debt piles up because “there’s no room in the sprint.” And cross-functional teams? Not when QA, Dev, and Ops are still in separate departments with separate OKRs.
But hey, we’re “doing agile,” right?
What Modern Development Really Needs
Scrum helped us crawl out of waterfall. But we’ve stopped evolving.
Today’s teams need flexibility, not fixed-length sprints. We need tools that fit the work, not work bent to fit the tools. We need:
- Continuous delivery, not fortnightly drops
- Kanban-style flow, not backlogs that read like ancient scrolls
- DevEx focus, not burndown charts
- Outcome metrics, not story points
- Trust, not ticket choreography
Most of all, we need autonomy. If your team can’t say “no” to a feature, you’re not agile—you’re just fast waterfall.
Closing Thoughts from a Tired Dev
Scrum was a decent map for unfamiliar territory. But maps aren’t sacred. When the terrain changes, you draw a new one.
So if your team is spending more time on process than product, if your retros sound like déjà vu, if your stand-ups are just theater—maybe it’s time to stop sprinting in circles.
There’s a better way. You might not find it in a framework. But you’ll definitely find it in your team.
And probably not in the backlog grooming session you have scheduled at 3:00.