Right now, a developer is sitting in their third meeting of the day. A product owner drags sticky notes across a Miro board, explaining why the sprint commitment needs to change. Again.
This isn't a failure of that particular team. It's where an entire industry ends up when it adopts a methodology as religion instead of tooling.
The question is no longer "how do we do Agile better?" It's "what comes after Agile?"
The Exhaustion Is Real
Agile in most organizations isn't the lightweight, developer-empowering methodology described in the original manifesto. It's a bureaucratic overlay combining the worst aspects of rigid planning and chaotic improvisation.
Planning poker has become performance art. Eight engineers hold up Fibonacci cards for a vague user story. The person who knows the codebase says 21. Everyone else guesses lower. After 30 minutes, they "agree" on 8. The number means nothing.
Daily standups are attendance rituals. "Yesterday I continued working on the authentication refactor. Today I'll continue working on the authentication refactor. No blockers." Repeat fourteen times. Nobody learned anything they couldn't have gotten from a Slack message.
Retrospectives change nothing. Every two weeks, teams identify the same problems: too many meetings, unclear requirements, technical debt. Every two weeks, action items quietly disappear.
Pre-Agile Practices Worth Reconsidering
In our rush to reject everything associated with "waterfall," we discarded practices that actually worked.
Upfront Design Isn't Evil
There's a vast middle ground between six-month specification marathons and "we'll figure it out as we go." When you're connecting to seven external APIs and three legacy databases, spending two weeks on architecture diagrams isn't waste. It's the only way to avoid building something that needs to be torn down.
Written Specifications Have Value
"Working software over comprehensive documentation" has been weaponized into "documentation is waste." The result? Knowledge trapped in heads, context lost when people leave, new team members spending weeks on code archaeology.
A few pages describing what a feature should do, why it matters, and how it interacts with existing systems? That's not overhead. That's professionalism.
Distinct Project Phases Provide Clarity
Some projects have natural phases: research, design, implementation, stabilization. Forcing these into identical two-week sprints creates artificial pressure and obscures actual progress.
Phases don't mean waterfall. They mean acknowledging that discovery work and production hardening are fundamentally different activities.
Teams Are Already Moving
The documentation-first team: A fintech backend team requires written technical specifications before implementation. Result after six months: fewer surprises, faster onboarding, reduced defects, faster overall delivery.
The meeting-purge experiment: An infrastructure team audited ceremonies with one question: "What decision does this meeting enable that couldn't happen otherwise?" They eliminated daily standups, moved to monthly planning, reclaimed ~12 hours per developer per month. Velocity increased roughly 20%.
The phase-gate revival: A platform team adopted explicit phase gates with specific owners and actual authority to block progress. They ship less frequently but with significantly higher quality.
How to Start
Audit your ceremonies. For each meeting, document time spent, decisions that emerged, and what would happen if you skipped it.
Identify actual pain points. Requirements ambiguity? Coordination failures? Technical debt? Map your problems, then ask which your current process actually addresses.
Run small experiments. "For this quarter, let's try written specs for large features." "Let's experiment with async standups for one month." Measure outcomes.
Create a team working agreement. Document what you will and won't do. Review quarterly. Evolve deliberately.
The Path Forward
The Agile Manifesto was written in 2001. It would be strange if a methodology designed for 2001's challenges was perfectly suited to 2025's reality.
The best teams are pragmatic rather than dogmatic. They use standups when standups help and skip them when they don't. They write detailed specs when complexity demands it and use lightweight user stories when simplicity allows.
They don't ask "is this Agile?" They ask "does this work?"
That's the only question that matters.
The frameworks, the certifications, the consulting methodologies—these are tools, not religions. Use what works. Discard what doesn't. Stop feeling guilty about it.
Full article with case studies and implementation details at agilelie.com