Disclaimer:
No Scrum Masters were harmed in the writing of this article. Several were mildly inconvenienced. Add it to the backlog.
The author acknowledges that his own team also says “no blockers” while being completely blocked, and is working through the shame in therapy.
This is a brutally honest eulogy for Agile methodology in the age of AI pair programmers, vibe coding, and sprints that somehow never end on time.
Written by frag, a senior dev who never submitted to jira tickets
It’s 9:03 AM.
You’ve been up since 6. You’re in the zone. That async thing that’s been breaking your brain for two weeks? It finally clicks. Coffee’s perfect. Music’s good. Your AI copilot is finishing your sentences.
Then your phone buzzes.
⚠️ Daily Standup in 12 minutes.
You stare at it. Close your eyes. Open the meeting link.
You already know your lines. You’ve said them a hundred times: “Yesterday I worked on the auth service. Today I’ll keep working on the auth service. No blockers.” Forty seconds. The meeting is thirty minutes. You do the math. You don’t feel good about the math.
Welcome to Scrum. Somewhere out there, a goat farm is calling your name.
A Brief and Painful History
Scrum was born in 1995. Jeff Sutherland and Ken Schwaber (genuinely good people) looked at the software industry eating itself alive with waterfall projects (18 months of planning, 6 months of coding, 2 months of crying) and said: there has to be a better way.
And there was. Scrum was better. In 1995. When “collaboration” meant printing a doc and walking it to someone’s desk. When your deployment pipeline was a guy named Dave with a floppy disk.
The core idea was clean: break work into small chunks, ship often, get feedback, adjust. Simple. Elegant. Actually correct.
Then the consultants found it.
“What started as a liberation movement became its own bureaucracy. Agile got waterfall’d.”
By 2010, every company on the planet had a Certified Scrum Master — two-day course, $140k salary — whose main job was telling people to “keep it to two minutes” in standups that ran 47 minutes.
By 2015, we had SAFe — Scaled Agile Framework — which is basically Agile for organizations that hate Agile but need 200 slides to justify why. The SAFe diagram looks like someone threw spaghetti at a whiteboard and called it a “PI Planning ceremony.”
By 2020, we had story points in Fibonacci numbers, velocity charts nobody could explain, and sprint retros where everyone blamed communication and nothing ever changed.
And now it’s 2026. Your AI writes 60% of your code. Let me give you a picture of the reality I am referring to
| Metric | Reality |
|---------------------------------------------|----------------|
| Avg standup length | 31 minutes |
| Devs checking their phone during standup | 47% |
| Story points for "refactor legacy" | ∞ |
| Retros that actually fixed communication | 0 |Let’s go through each ritual. With love. And a chainsaw.
The Daily Standup
Supposed to be 15 minutes. Stand up, sync up, get out. Great idea on paper.
In practice it’s a performance. Ten engineers doing their best impression of productivity for a manager who is technically “not needed in this meeting” but is definitely there, definitely listening, definitely forming opinions.
The script never changes: yesterday X, today X+1, no blockers. Except nobody actually has no blockers. We’re all blocked. Blocked by requirements that say “make it better.” Blocked by that PR sitting in review for four days. Blocked by a microservice that started throwing 503s at 3am for no reason anyone can find.
But we say “no blockers” because raising one means watching two senior devs debate infrastructure for 25 minutes while the rest of the team slowly loses the will to live.
Sprint Planning
The game where your whole team sits down to answer one question: how long will this take? A question developers have been getting wrong for 30 years and will keep getting wrong until the sun burns out.
You estimate in story points — deliberately unitless, because time estimates create “false precision.” This is technically true. It doesn’t stop the PM from converting your points to calendar days in their head and telling stakeholders the feature ships in two weeks.
It will not ship in two weeks.
The Retrospective
My personal favorite. Structurally it’s therapy — except there’s no therapist, and nothing has consequences.
Everyone fills a Miro board with sticky notes. Green: what worked. Red: what didn’t. The red column always wins.
Action items get created. “Better documentation.” “More communication.” Nobody owns them. They get archived. The next retro begins.
Real action items from real retros (composite, but you’ve seen these):
Sprint 1: “Improve async communication”
Sprint 4: “Improve async communication”
Sprint 9: “Improve async communication”
Sprint 14: “We need to improve how we communicate asynchronously”
Sprint 23: Three people have left. New item: “team cohesion.”
The Sprint Review
You demo to stakeholders. They asked for a horse. You’re showing them a slightly better saddle. They nod. They say “nice.” They open a new ticket requesting the horse. It goes into the backlog.
The backlog is immortal. Things go in. Nothing dies. Right now yours has a ticket from 2019 called “Improve UX.” No description. Three story points. Label: someday. It was there when you joined. It’ll be there when you leave.
Let’s Scrum in the AI era (what can go wrong?)
We are living through the biggest productivity shift in software history. Copilot. Cursor. Claude. Gemini. Pick your poison. It’s embarrassingly fast. Not magic. Not perfect. But fast.
A good developer with a decent AI assistant today ships code at a pace that would’ve felt unrealistic in 2019. Prototypes in hours. Boilerplate in seconds. Unit tests before your coffee’s done (reason for which I consume much less coffee than before). Depending on the task and how honest you’re being, solo coding time has dropped somewhere between 30% and 70%.
And yet. The ceremonies remain. Same story points. Same two-week sprint. Same morning standup. Same planning poker cards.
“We gave developers Formula 1 engines and kept them on roads with 30mph speed limits enforced by a Scrum Master.”
The whole structure of Scrum was built around a world where writing a function took an afternoon. Now it takes four minutes and a prompt. The planning cycle didn’t get the memo. The human coordination layer is now the actual bottleneck.
And then there’s vibe coding.
Quick explainer for the uninitiated: “vibe coding” is a term Andrej Karpathy coined for a style of development where you describe what you want in plain language, the AI generates it, you run it, it mostly works, you tweak, repeat. You’re not writing code so much as directing it.
It’s messy. It produces technical debt at speed. It can generate security holes that a careful review would catch. Juniors using it without understanding the output is genuinely worrying. Also, and I say this with 20 years of backend work behind me, it is deliriously fun and occasionally brilliant and represents a real shift that nobody has fully processed yet.
But here’s the question nobody in your sprint planning is asking:
What does vibe coding do to story point estimates?
If a three-day feature now takes half a day with an AI copilot, your velocity is fiction. If a prototype that needed a senior dev now ships in two hours, your capacity planning is fiction. If your Definition of Done doesn’t include “AI-generated code reviewed by someone who actually understands it,” you’re shipping risk you’re not tracking.
Scrum has no answers for any of this. The Scrum Guide was last updated in 2020. The word “AI” doesn’t appear in it once.
A tale of two tickets:
2019: “Build auth flow. 13 points, ~4 days. Login, logout, JWT, password reset.”
2026: Dev opens Cursor, types “full auth with JWT, refresh tokens, Google OAuth,” reviews the output, ships in 90 minutes. Points: ???
Your velocity chart just became fan fiction.
Okay. I’ve had my fun. Time to be straight with you.
Yes, the velocity metrics are often misleading. Yes, most retro action items die quietly. And yes, Scrum is seriously overdue for a rethink in the AI era.
But here’s what it actually solves, which we forget when we’re venting:
Coordinating ten engineers on one codebase is genuinely hard. Without any sync mechanism, you get duplicated work, conflicting changes, and nobody agreeing on what “done” means. The standup is annoying. The alternative, for non-trivial teams, is worse.
Short feedback loops still matter. The core Agile insight — ship small, get real feedback, adjust — is as true as ever. An AI can generate a feature in an hour. If it’s the wrong feature, generating it faster just gets you to wrong faster. Iteration still matters. Validation still matters.
Psychological safety is load-bearing. A retro run by someone who’s actually good at it is one of the very few places in corporate life where you can say “this is broken” without it becoming a political problem. That’s rare. Most organizations don’t have anywhere else like it.
The principles aren’t the problem. The cargo cult is the problem. Companies that adopted the vocabulary of Agile without the values underneath it, and ended up with all the meetings and none of the adaptability.
What Actually Needs to Die
Story points as a proxy for time. Dead. Bury them. In an AI world, time estimation is more unpredictable than ever.
Velocity as a performance metric. Dead. Velocity was never meant to compare teams or sit on a management dashboard. It’s a team-internal planning tool. If your engineering manager is asking why Team A’s velocity is lower than Team B’s, they have fundamentally misunderstood velocity. This is common.
Standups as status reports to management. Dead. If your manager is the main audience for your standup, you don’t have a standup. You have a surveillance ritual with a time limit. Replace with async written updates. Use the reclaimed time to solve actual problems.
Retro action items nobody owns. Dead. If your retros never produce change, stop adding more action items. Have one meta-retro about why the retro isn’t working. One item. Make someone own it. Actually fix it. Then continue.
The Certified Scrum Master who has never shipped software. I’ll leave this one without comment. You know.
Now, here’s my real prediction, no sarcasm, for how the best software teams operate in three years:
Async-first, event-driven coordination. Most communication is structured and written (decision logs, short async video updates, shared context docs). Synchronous meetings are reserved for genuinely hard problems where two humans need to think together in real time because the ambiguity is too high for async to resolve.
Outcome-based planning. We stop asking “how long will this take?”, a question AI makes harder to answer, not easier, and start asking “what problem are we solving, and how will we know we solved it?” Ship small. Measure real. Iterate on what actually happens.
AI as part of the process, not just the code. Not just generating functions, but synthesizing retro notes across sprints. Critiquing ticket descriptions before anyone picks them up. Playing devil’s advocate on architecture decisions. The process itself gets smarter.
The standup becomes optional. Ten minutes max, for teams that genuinely need it. Async video updates for teams that don’t. Both tracked by outcomes, not attendance.
“The goal was never Scrum. The goal was working software, delivered reliably, by people who aren’t burned out. We confused the method for the mission.”
Frankly speaking, scrum isn’t dead. Agile principles aren’t dead. Ship small, get feedback, adapt. That’s still right. It was right in 1995. It’s right now.
What is dying, and it should, is the rigid ritualism. The idea that holding the right meeting at the right time with the right artifact is what makes teams effective, instead of what those meetings are supposed to produce: shared understanding, cleared blockers, validated direction.
AI isn’t just changing how we write code. It’s changing the fundamental economics of software development, such as the speed, the bottlenecks, where the risk lives. The process has to move with that reality.
So here’s the question worth asking in your next retro, instead of “how’s our communication?”:
If we were designing our process from scratch today, knowing what AI can and can’t do, knowing where our real bottlenecks are, knowing what actually helps us ship good software to real users, would we design this?
If yes: keep it. If the honest answer is “we’d build something completely different”: congratulations. You just discovered what retrospectives are actually for.
Now go be blocked in silence. Standup’s in twelve minutes.