The Agile Manifesto says "responding to change over following a plan."
It talks about adaptability, flexibility, collaboration. It explicitly pushes back against the rigid, deadline driven approach of waterfall.
And yet, modern Agile is full of deadlines.
Sprint deadlines. Release deadlines. Quarterly planning cycles with committed roadmaps. OKRs with end of quarter targets.
How did a methodology built around flexibility end up recreating the same time pressure it was supposed to eliminate?
The Compromise
Here's what happened: Agile had to interface with the rest of the business.
Finance needs to know when features will ship so they can forecast revenue. Sales needs dates to promise prospects. Marketing needs lead time for launches.
So Agile teams, which wanted to be flexible, got squeezed into fixed timelines anyway.
The solution? Smaller deadlines.
Instead of one big 18 month release cycle, you get two week sprints with sprint commitments. Instead of annual roadmaps, you get quarterly planning with "committed" vs "aspirational" features.
The deadlines didn't go away. They just got more frequent.
The Sprint Commitment
In theory, sprints are about sustainable pace and predictability. You plan what you can accomplish in two weeks, you commit to it, you deliver it.
In practice? Sprint commitments become mini deadlines. The team feels pressure to "finish the sprint" even if priorities have shifted. Incomplete work feels like failure, even if it's incomplete for good reasons.
You traded one deadline for twenty six smaller ones.
Why Deadlines Persist
The uncomfortable truth is: some amount of time pressure is useful.
Without any deadline, some work would expand forever. Parkinson's Law: work expands to fill the time available.
Deadlines force prioritization. They force you to ship something instead of endlessly polishing. They create a shared sense of urgency.
The problem isn't deadlines themselves. It's arbitrary deadlines. Deadlines that exist because it's the end of the sprint, not because there's a real reason to ship by then.
The Healthy Version
Good deadlines are:
Real: There's an actual external constraint. A conference. A contract. A seasonal opportunity. Not just "because it's Q3."
Negotiable: If priorities shift or complexity emerges, you can adjust scope or timing.
Rare: Most work doesn't have hard deadlines. Only the stuff that genuinely has to ship by a certain date.
Bad deadlines are:
Artificial: They exist to create pressure, not because there's a real need.
Fixed: No matter what happens, the date is sacred and scope will bend to meet it.
Constant: Every sprint, every quarter, every release has the same urgency, so nothing actually feels urgent.
The Agile Trap
Here's the irony: Agile was supposed to give teams the freedom to respond to change. But by institutionalizing sprints and velocity and commitments, it created a different kind of rigidity.
You're not locked into an 18 month plan anymore. But you're locked into whatever you committed to on Monday morning, even though it's Thursday and the world has changed.
The timebox became just another deadline.
What to Do Instead
Some teams are experimenting with continuous flow instead of sprints. No artificial two week boundaries. Just a prioritized backlog, and you work on the most important thing until it's done.
Others keep sprints but drop the commitment aspect. The sprint is a timebox for reflection, not a contract.
The key is: use deadlines when they add value, not because the process demands them.
If there's a real reason to ship by Friday, great. If not? Ship when it's ready.
Agile was supposed to free us from the tyranny of the Gantt chart. Let's not replace it with the tyranny of the sprint burndown.
Ready to try Bonjour?
A hyper-focused feed for your team. No endless lists. Just the work that matters.