Agile is broken. It‘s time to try something new.
Agile promised us a better way to build software. It started as a breath of fresh air — a rebellion against bloated requirements documents, year-long waterfall projects, and developers coding in the dark. Agile was about adaptability, collaboration, and delivering real value.
But somewhere along the way, Agile lost the plot.
In many companies today, Agile has devolved into a rigid, ritual-heavy process that enables dysfunction more than it delivers software. And while there are valuable elements worth preserving — collaboration between business and software to review requirements (grooming), regular planning sessions (planning), daily communication (stand-up) — the broader methodology, as it’s implemented, has become a shield for poor product thinking and broken organizational behavior.
The Rise of “Agile-In-Name-Only”
Let’s be honest: most teams aren’t doing Agile. They’re doing Agile Theater.
They go through the motions — story points, velocity charts, sprint reviews — but the soul of Agile is missing. Instead of collaboration and iteration, developers are handed vague or shifting requirements at the last minute, with the expectation to “just be Agile about it.”
In this warped version of Agile:
- Business stakeholders treat the backlog as a dumping ground for ideas they haven’t thought through — expecting dev teams to sort it out.
- Product owners are often absent or overwhelmed, unable to make clear decisions or set priorities.
- Velocity is treated as a performance metric, even though team composition, complexity, and context change constantly.
- Teams are held to arbitrary deadlines, even though Agile was supposed to focus on delivering value, not hitting dates.
The result? Burned out developers. Frustrated product managers. Poor quality releases. And an overall sense that no one is steering the ship — they’re just shoveling coal into the engine.
Agile Is Being Used to Excuse Bad Behavior
One of the most dangerous side effects of Agile’s misuse is how it has shifted the burden of forethought.
In traditional models, business had to commit to an idea — write it down, justify it, map it out. Now, “just get it into the backlog” is enough. Agile is used as a reason not to do the hard thinking upfront. Planning is dismissed as “anti-Agile.” Unclear requirements become the dev team’s problem. Rework is brushed off with, “That’s what iteration is for.”
This is not Agile. It’s abdication.
Velocity Isn’t Everything (Especially With a Rotating Cast)
Velocity, in theory, helps teams understand what they can accomplish and plan accordingly. But in practice, it’s often meaningless.
Why? Because most teams don’t stay the same for long. Team members rotate. Skills vary. Knowledge transfer is patchy. Measuring a team’s worth by how many points they “burn down” ignores all of this — and it pressures teams into point-inflation, corner-cutting, or playing the game instead of focusing on outcomes.
Velocity without continuity is a vanity metric.
When do we catch our breath?
Think about the word “sprint” – does that sound like something you can do forever? Yet that’s exactly how software teams are expected to work. They go from one sprint to the next to the next. There’s no downtime. This might sound great to the executive team, but they aren’t seeing the real cost. Devs burn out. Technical debt backs up. Bugs go unfixed. New features are “minimum viable products” rushed out the door, to be improved in the next sprint…maybe…if there’s room to squeeze it in.
Having short, regular intervals to plan work is not itself bad. Running as fast as you can. Having that interval be 2 weeks
What’s Worth Saving — and What Needs Fixing
Despite all of this, not everything needs to be thrown out. Some Agile rituals, when grounded in real purpose, still work:
- Grooming: When done collaboratively, backlog refinement helps catch problems early and build shared understanding.
- Planning: A regular cadence for aligning on goals is critical — but only if priorities are clear and realistic.
- Standups: These are valuable for identifying blockers, syncing the team, and staying focused — when they aren’t just status reports.
What needs to change is the context in which these practices live.
A Better Way Forward: Practical Fixes to Modern Agile
If Agile is going to survive — and be useful — it needs to evolve. Here’s where to start:
- Reintroduce Product Discipline
- Don’t let Agile be an excuse to skip vision and strategy. Product leaders must take accountability for direction, clarity, and validation.
- Demand Better Requirements
- Agile doesn’t mean building without blueprints. Require problem statements, acceptance criteria, and rationale for every story. It’s not bureaucracy — it’s responsibility.
- Stop Worshipping Velocity
- Focus on outcomes, not output. Did the feature solve the problem? Did users adopt it? Did we learn something? Those are the metrics that matter.
- Stabilize Teams
- Invest in long-term, cross-functional teams. Protect their focus. Minimize churn. Build real cohesion.
- Rebuild Trust Between Business and Engineering
- Developers aren’t ticket-takers. Give them context. Involve them in discovery. Respect their estimates. If engineering is always “saying no,” ask why — and listen.
Software teams need the freedom to try something new.
The spirit of Agile is still valuable — responding to change, delivering iteratively, empowering teams. But the cargo-cult version most organizations are practicing today is not serving us.
If software is going to get better — faster, safer, more impactful — we need to stop pretending Agile-as-usual is working. We need to return to first principles, cut the rituals that no longer serve us, and rebuild a development process that respects planning, empowers teams, and actually delivers value.
It’s time to stop hiding behind Agile. Let’s build something better.
