Scrum had a moment. I lived through it, ran it, defended it, and tried to make it work in teams that had no business running two–week theater. In 2025, I do not need another ceremony calendar, another points debate, or another sprint “commitment” that collapses the first time reality shows up.
Scrum is not modern. It is a ritual from a different era that now gets in the way.
Scrum solved a 2001 problem, not a 2025 one
Scrum came from a world of colocated teams, quarterly releases, and product owners who sat ten feet from the developers. That world is gone. Today I have:
- Remote and hybrid teams across time zones.
- Continuous delivery pipelines pushing small changes all day.
- Feature flags and progressive delivery to de-risk releases.
- Product discovery running in parallel with delivery.
The original pitch of Scrum was simple guardrails: short iterations, a thin backlog, and tight feedback loops. In practice, it calcified into roles, ceremonies, artifacts, and a cottage industry of certificates that says “do it by the book.”
Modern teams need speed and adaptation. A prescriptive framework that assumes synchronised cadence, shared office hours, and a single prioritised backlog is friction, not leverage.
The rituals: cadence, meetings, and points
The sprint model pretends that work arrives in tidy chunks and fits a two–week box. Real work does not. Hard problems have discovery and delivery mixed together. Urgent issues ignore the calendar. Dependencies land when they land. The sprint board becomes a stage set: we slice tickets thinner, rename things to fit the template, and celebrate “done” while the actual outcome is still unknown.
I have watched teams move the same story across three sprints because the estimate was wrong from the start. The response was not to change the model. The response was to invent more ceremony. Add a spike ticket. Add a refinement session. Add a roll-over label. Add a sprint goal so vague it cannot be wrong. None of this ships value faster.
Points were supposed to be a relative measure to help with planning. Instead they became a performance metric. Managers compare velocities. Teams game the system. Points drift up, then drift down when someone tries to “normalise.” The only truth points deliver is that they are arbitrary.
If I want to know whether we are getting better, I look at lead time, cycle time, change failure rate, and time to restore. I look at how long it takes for a validated idea to reach a customer. I look at the ratio of planned work to unplanned interruptions. None of this requires points. It requires good flow and honest data. Scrum puts estimates at the center and outcomes at the edge.
Then there is the meeting factory: daily standup, refinement, planning, review, retrospective. That is five recurring meetings before you count ad hoc sessions, stakeholder reviews, and production incidents. For a distributed team, the overhead is brutal. People repeat updates across time zones. Work gets blocked waiting for the right ceremony to unblock it.
We build slide decks for sprint reviews like it is a quarterly business review every ten days. Async status with a written update beats a standup. A focused incident review beats the retro ritual. The less time I spend in mandatory ceremonies, the more time I have for the work that matters.
Scrum also loves graphs; burndown, burnup, velocity, that look objective while erasing context. A pretty slope on a chart can hide a rough week of incidents and heroics. A velocity dip might simply be school holidays, sick leave, or a staging environment that was down for days. These charts assume constant capacity and a smooth arrival of work. Software never behaves like that.
The reality your dashboards flatten:
- Sick leave, caretaking, and staggered annual leave across regions.
- Incident response, on-call churn, and downtime fire drills.
- Infrastructure limits: flaky CI/CD, slow builds, broken test data, locked change windows.
- Compliance and security reviews that land off-cadence.
- External dependencies and vendor throttling you cannot accelerate.
- Resource limitations: thin senior coverage, context switching, hiring gaps
When leadership steers by these lines, teams optimise the numbers instead of the system. We move tickets to satisfy the burndown rather than unblock flow or reduce risk.
What modern teams actually do instead
I do not need a capital-F Framework to behave like professionals. The guts of modern delivery are simple and boring:
- Continuous delivery to production with feature flags and dark launches.
- Kanban flow with explicit WIP limits and a real pull system.
- Trunk-based development with small, reversible changes.
- Outcome-driven roadmaps that say why before what.
- Dual-track product work: discovery in parallel with delivery, not piped through a “refinement” funnel.
- Strong ops hygiene: alerting, SLOs, and incident reviews that change behavior.
- Lightweight, async updates and written decisions people can read on their own time.
This mix is not radical. It is a practical response to the world we actually live in. It lets teams move faster when the path is clear and slow down on purpose when something is risky. It treats planning as a rolling conversation rather than a performance inside a sprint boundary.
Why it persists
Scrum is easy to buy. It promises repeatable output, a vocabulary, and a calendar full of control points. It gives leaders burndown charts, sprint reports, and a person with “owner” in their title to absorb ambiguity. It also creates the illusion of predictability. When things slip, the process has knobs to turn: more refinement, stricter acceptance criteria, stronger “commitment.”
Those knobs do not fix the root problem. They only transfer pressure onto the team. I have seen executives cling to Scrum because it frames delivery as a schedule problem. If the team just committed harder, planned better, and refined longer, then the plan would become real. In reality, the risk is upstream: poor strategy, no clear problem, or a dependency chain that makes dates meaningless. Scrum masks that pain long enough to kick the can to the next quarter.
The roles and artifacts do not age well either. Scrum assumes a neat division of labour: a product owner who speaks for the business and a team that executes. In practice, decisions cut across product, design, engineering, legal, security, and data. The “owner” model breaks under that weight. Either they become a proxy for every decision, which slows everything down, or the team ignores the role and decides where the knowledge lives.
The backlog as a single ordered list is another antique. Healthy teams maintain multiple queues: experiments, refactors, defects, platform work, regulatory obligations, and bets of different sizes. Priority is multi-dimensional. You cannot reduce that to one line of cards without hiding risk and debt. Even the sprint goal turns into a wish. The moment a critical incident lands or a dependency slips, the calendar wins and the goal loses.
I hear the pushback: “We need discipline.” I agree with the premise and reject the solution. Discipline is keeping WIP low and finishing what we start. Discipline is shipping small, observing outcomes, and adjusting quickly. Discipline is writing things down so people are not blocked by calendars. Discipline is owning incidents and making the system safer next time. None of that requires a sprint plan, a burn chart, or a set of roles. It requires leaders who remove friction and teams who take responsibility for flow and quality.
Scrum is also catnip for micromanagers. It provides a daily roll‑call, a sprint “commitment” to police, and a backlog they can reshuffle to exert control. In a low‑trust environment the standup turns into an interrogation, not coordination. “Where are we on ABC‑123?” replaces “What is blocking flow?” Velocity targets become a stick. People manage optics. The work becomes about feeding the dashboard instead of improving the product.
Keep the spirit, ditch the scripture
Short feedback loops are good. Teams talking to each other is good. Inspect and adapt is good. You can have all of that without the overhead. Take the bits that help and drop the rest.
If a recurring meeting is not pulling its weight, kill it. If points are hurting more than helping, delete them. If the backlog is a graveyard, archive it and start fresh with a one–page map of problems worth solving. A better pattern than a sprint goal is a weekly intent written in plain language and reviewed async. If it changes, write that down too. The point is to move the work, not satisfy a ritual.
Scrum had utility as a stepping stone out of the waterfall era. It gave us a common language to talk about iteration. It does not fit a world of continuous delivery, distributed teams, and product discovery as a first-class activity.
I am tired of pretending that a process from another decade is a good default. In 2025, the most respectful thing I can do for a team is to say it plainly: Scrum is irrelevant. Drop it. Do better. Keep moving.