To Be Agile, or Not to Be, or Pretend — That Is the Question
A developer's very personal, slightly traumatized account of surviving the software industry's favorite buzzword.

I've been on all three sides of this spectrum. I've been Agile. I've tried to be Agile. And I've sat in standups that were so far from Agile they might as well have been called "Daily Group Therapy for People Who Just Want to Merge Their PRs."
So let me take you on a journey. Pour your coffee. Or your third coffee. You know who you are.
🏃 Stage 1: You Discover Agile and Think You've Found Religion
It usually starts with a LinkedIn post, a YouTube talk, or a very enthusiastic new Scrum Master who just got certified over the weekend.
You read the Agile Manifesto. All 68 words of it. And you think: "This is it. This is what's been wrong with every project I've ever touched. We just need to collaborate, respond to change, and stop writing 47-page requirement documents nobody reads anyway."
You walk into the office on Monday with the energy of someone who just did a 10-day silent retreat.
"We should do two-week sprints," you say.
"We should have a backlog," you say.
"The team should self-organize," you say.
And everyone nods. Beautiful, affirming nods.
Then your manager schedules a 3-hour requirements meeting. For that same afternoon.
📋 Stage 2: The Ceremony of Ceremonies
The next phase is what I call Ceremonial Agile — where you do all the meetings Agile prescribes, but none of the principles.
The Daily Standup becomes a 45-minute status update to the project manager. You start answering the three questions — What did I do? What will I do? Any blockers? — but by question two, someone has already shared their screen and is narrating their Jira board like a sportscaster.
"So here on the board, we can see ticket #432 has been 'In Progress' since the second week of November. Carlos, do you want to walk us through that one?"
Carlos does not want to walk us through that one.
The Sprint Planning becomes a negotiation exercise where the business tries to fit 40 story points into a 20-point sprint, and the dev team dies a little inside every time someone says "But it's just a small change."
"It's literally just changing a label."
[Three database schema migrations, two API contract updates, and a full regression cycle later...]
And the Retrospective — oh, the retrospective. The meeting where everyone writes sticky notes about what went wrong, puts them on a digital board, agrees it was a rough sprint, and then does the exact same thing next sprint.
The sticky notes pile up. The problems do not go away. Someone adds a new color of sticky note as if that will help.
🎭 Stage 3: Pretend Agile — The Dark Arts
This is where things get creative.
Pretend Agile is when your organization has the aesthetics of Agile without any of the substance. You know you're in this zone when:
Your "sprint" is 6 weeks long because "that's how long it takes to get approvals."
Your backlog is actually just an Excel file your PM emails around.
You do daily standups at 4:30 PM.
Your Definition of Done is "when the client stops asking about it."
Velocity is tracked, but only to justify why the team needs to work weekends.
Someone scheduled a "Sprint Review" but it's actually a formal demo with a 40-slide PowerPoint prepared three weeks in advance.
I once worked on a project where we had a Scrum board — physical Post-its on the wall, very aesthetic, very startup-y — and every single ticket was perpetually stuck in "In Review" for weeks. Not because nobody reviewed. But because the reviewers needed approval from their manager before approving.
The Post-its turned yellow. Some fell off. A fan blew three tickets under the refrigerator.
We called it "Kanban."
🔥 The User Story Crimes
Can we talk about user stories for a second?
The format is: "As a [user], I want to [goal], so that [reason]."
What actually gets written:
"As a system, it should do the thing so that the thing works."
I have seen user stories so vague they could describe literally any software ever written. I have seen acceptance criteria that contradict the title of the story. I have seen a story titled "Performance" with no description, no criteria, and a story point estimate of 13.
Thirteen.
Nobody could explain why 13. It had been in the backlog for two years. It had outlasted three developers. It was load-bearing in a way nobody understood. Nobody touched it.
🏋️ The Estimation Circus
Story point estimation deserves its own comedy special.
Planning Poker sounds fun in theory. Everyone picks a card simultaneously. Numbers are revealed. Debate ensues. Eventually you arrive at a consensus.
In practice:
The senior dev says 2 because they've solved this before.
The junior dev says 13 because they're being honest.
The PM says 1 because they don't fully understand what a story point is but they have a deadline.
Someone always picks the Fibonacci number that means "I have no idea what we're building."
The discussion that follows lasts longer than the actual task would have taken.
And then there's the manager who sits in on estimation and says:
"So when you say '8 points', that's about 8 hours, right?"
No. No it is not. We've explained this. We have a wiki page. The wiki page has a diagram. The diagram has been there for two years. The question still gets asked every sprint.
🚢 "We Need to Be More Agile" — The Meeting
Possibly the most ironic experience in software development is when someone schedules a two-hour meeting to discuss how the team needs to move faster and be more responsive to change.
This meeting will have:
A 20-slide presentation about Agile principles
A guest speaker who is not a developer
Action items that will be reviewed "in the next meeting"
A follow-up survey
Zero code shipped as a result
It will be scheduled over your sprint planning.
💡 But Here's the Thing...
Between all the chaos and the ceremony theater, I've seen Agile actually work. Not perfectly. Not textbook. But genuinely work.
It worked when a team I was on actually killed a feature mid-sprint because user feedback came in and made it clear we were building the wrong thing. No drama. No 3-week change request process. Just: "Pivot. Here's why. Let's move."
It worked when a retrospective got honest enough that we admitted the real blocker wasn't technical — it was that two teams weren't talking to each other, and nobody wanted to say it out loud. That conversation, uncomfortable as it was, saved months.
It worked when developers were trusted to estimate their own work without someone halving it in the name of "business urgency."
Agile isn't a process you follow. It's a trust fall between the business and the team — and someone always has to jump first.
🧘 What I've Learned (The Hard Way)
After years of living inside sprint boards, retrospectives, and backlogs that could fill a small novel:
Agile done right is actually uncomfortable. Real transparency, real accountability, real ownership — that's harder than waterfall, not easier.
Ceremonies are the skeleton, not the muscle. If you're doing the meetings but not the mindset, you just have a very well-scheduled dysfunctional team.
The best sprints I've ever been in had almost no process. Just a shared goal, a small team, and a chat thread that never slept.
"We do Agile" often means "we have Jira." These are not the same thing. Jira can survive without Agile. Agile cannot survive inside Jira alone.
Velocity is a compass, not a speedometer. The minute you start optimizing for velocity numbers, you start gaming them. And then they're useless.
🎬 Final Thoughts
Shakespeare asked: "To be, or not to be?"
The modern developer asks: "To be Agile, or to pretend to be Agile while slowly losing my will to live in a 3-hour sprint planning meeting for a two-week sprint?"
The honest answer is: most of us are somewhere on the spectrum, most of the time. We're all trying to ship good software in a world that keeps changing its mind about what "done" means.
And maybe that's the most Agile thing of all — accepting that it's messy, iterating on how we work, and committing to the next two weeks even when we don't fully know what we're building yet.
Now if you'll excuse me, I have a standup in four minutes and my git pull is still running.
If this resonated with you, share it with a colleague who just scheduled a two-hour meeting about improving meeting efficiency. They need this more than they know.
And if your sprint board looks like mine did circa 2022 — a monument of amber "In Progress" tickets and crushed dreams — just know: you are not alone. The retrospective is coming. Write your stickies. It probably won't fix everything. But at least we'll have talked about it.





