Alex Polyakov's Analyst's Corner piece makes the strongest case I've read this year that Scrum is obsolete. The job market signal, the static defense, the XP comparison, the way Scrum normalizes failure. All correct.
He stops one paragraph short. The thing he is right about (Scrum is obsolete) needs a named replacement, and the piece doesn't name one. This is the move that lets every Scrum org read the article, agree with every paragraph, and keep doing Scrum on Monday.
This post is the missing paragraph.
The short version
Polyakov is right that Scrum is obsolete. Hiring data, content-volume-vs-demand divergence, the framework's ceremony-over-rigor drift, and the way Scrum normalizes missed timelines all support the case. The piece stops at diagnosis. A diagnosis without a named replacement loses the argument inside the room, because "Scrum is obsolete" without "and here is what we do instead" reads as nihilism to the people who have to schedule next week's sprint. The replacement has a name. Four-to-six person builder pod. Three artifacts: a prototype, a five-row eval, an outcome ledger. Cadence: 30 minutes weekly, 5 minutes Friday. No Scrum Master role.
For the structural argument, see Agile Is a Coping Mechanism. For the artifacts that replace the Scrum stack, see Kill the PRD: The Prototype Is the Spec and The Five-Row Eval Template.
What Polyakov nails
Five points worth repeating.
1. The market is voting with hiring. Scrum Master roles are being merged into Engineering Manager roles or removed. Job descriptions are renaming themselves. This is the most honest signal you can get about whether a framework is still alive. Content volume is not signal. Hiring is signal. Polyakov's line about LinkedIn loud, demand quiet is the cleanest one-liner I've seen on the topic.
2. Scrum borrowed XP and dropped the rigor. This is the historically accurate read. Extreme Programming (Beck, Fowler, Jeffries) came from practitioner research and required engineering discipline (pair programming, test-driven development, continuous integration, refactoring). Scrum took the iteration cadence and shipped without the engineering practices because the engineering practices were hard to sell to non-engineering buyers. The trade-off worked for adoption and failed for rigor.
3. The framework normalizes failure. Polyakov's observation that "everything is an experiment, nothing is truly late" is one of the sharpest critiques of Scrum I've read. The ceremony of the retrospective converts missed commitments into "learning opportunities" indefinitely. When learning is the primary success criterion, delivery becomes optional. This is correct and load-bearing for the broader argument.
4. Ownership dissolves into consensus. Decisions belong to the team. Outcomes belong to the team. Which means they belong to nobody in particular. This is the structural problem that the PM/PO split (see the post on Huryn's piece) was created to paper over, and it never worked because the consensus problem is not a role problem. It is a framework problem.
5. Engineers see the theater first. Yes. Newer engineers ask why so many meetings exist, learn to survive ceremonies without changing the work, and develop a fast nose for when planning is performance rather than planning. This nose is correct. The instinct to escape Scrum is sound.
These five points stand on their own. The piece is worth reading just for them.
Where the piece stops short
The article ends with "developers want time back, fewer meetings, smoother flow, less micromanagement." All true. None of it is an operating model.
The reason orgs run Scrum is not that they believe in Scrum. It is that they need something to schedule, to staff, to report on, to point at when leadership asks "how are we tracking against Q3." If you tell those orgs "Scrum is obsolete" without giving them a replacement that scales the same way, you have not actually moved them. You have just made the existing framework feel slightly more embarrassing.
The piece needed one more section. What replaces Scrum?
The named replacement
A four-to-six person builder pod.
Composition. One PM, one designer who prototypes in code, two to three engineers. The pod owns one customer-facing outcome end-to-end. Headcount is small enough that everyone can hold the work in their head. Headcount is large enough that the pod can ship in parallel streams.
Artifacts. Three of them, total.
- A working prototype, built in Claude Code or Cursor in four to six hours per iteration, real enough for customers to use
- A five-row eval suite that defines "done" as falsifiable behavior, not a checklist
- An outcome ledger with three to seven active bets, each with a decision deadline two to four weeks out
That is the entire artifact set. There is no backlog. There are no user stories. There is no velocity. There are no story points. There is no sprint commitment.
Cadence. Weekly. A 30-minute Monday review covering each active bet. A 5-minute Friday update on what moved. A quarterly three-hour retro that's a real retro, not a ceremony.
Roles that do not exist. Scrum Master. Product Owner (as a separate role from PM). Release Train Engineer. RTE. Agile Coach. None of these have work to do in the builder pod.
This is not theoretical. I've run this structure with several teams over the last 18 months. The numbers it produces (time from customer signal to shipped prototype, eval pass rate at first ship, decisions per quarter) outperform every Scrum team I've measured against, with significantly less ceremony overhead.
What about agile-the-philosophy?
The agile manifesto's four values are defensible.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
None of these require Scrum. None of these require sprints. None of these require story points or velocity. The builder pod is more aligned with the manifesto than Scrum has been since roughly 2010, because the pod actually optimizes for the right side of each value statement instead of using the left side as a coping mechanism.
If you want to keep calling the builder pod "agile" in the manifesto sense, fine. The Scrum implementation of agile is what is obsolete. The principles are not in dispute.
What to do this week
If you run Scrum and you can't get permission to kill it, the smallest first move is to retire the sprint commitment.
Keep the cadence. Keep the standup if your team likes it. Drop the language of commitment and replace it with the outcome ledger. Three to seven active bets. Each one has a decision deadline. The team's job is to learn enough to decide, not to deliver against a fixed scope.
That one change strips most of the ceremony tax out of Scrum without requiring a re-org. The Scrum Master's role gets quieter inside a quarter. The PM's role shifts from backlog steward to outcome owner. The retro becomes a real conversation about what to kill.
If you can get permission for more, pilot one pod on the builder structure. Same headcount, no Scrum frame. Track the outcome-to-shipped-prototype time. Compare against the rest of the org. The numbers make the argument for you.
Polyakov is right that Scrum is obsolete. The next move is naming what replaces it, so the orgs that agree can actually do something different on Monday.
The builder pod template, the outcome ledger format, and the 30-minute weekly review agenda are on the toolkit. For the broader kill list this post belongs to, see Kill the OKR and Kill the AI Office Hours.
Sources: Alex Polyakov, "Scrum is not Dead. It's Obsolete!" (Analyst's Corner), Kent Beck on Extreme Programming, 2020 Scrum Guide, Larman and Basili on iterative history (IEEE 2003), agile manifesto.
Further reading
Frequently asked
Is Scrum actually obsolete?+
Yes, and the market is voting with hiring decisions. Scrum Master roles are being merged into Engineering Manager roles or removed entirely. Job market signal is the most honest signal you get about whether a framework is still load-bearing, and the signal says no. Alex Polyakov's January 2026 piece on Analyst's Corner captured this correctly.
What does Polyakov get right?+
Five things. (1) Scrum borrowed XP's good ideas and dropped the engineering rigor. (2) Adoption beat rigor because Scrum was packaged for non-technical buyers. (3) The framework normalizes failure by reframing missed timelines as 'learning.' (4) Ownership dissolves into consensus inside Scrum teams. (5) Engineers see the theater first. All five are correct.
Where does the Polyakov piece stop short?+
He names Scrum as obsolete but does not name what replaces it. 'Developers want time back, fewer meetings, smoother flow' is right but it's a description of an end state, not an operating model. Without a named replacement, orgs that read the piece will agree and keep doing Scrum because they don't see another option.
What's the named replacement?+
A four-to-six person builder pod that runs on three artifacts (a prototype, a five-row eval, an outcome ledger). No sprints, no story points, no velocity, no sprint review, no retro-as-ceremony. The work is the prototype and the eval. The cadence is a 30-minute weekly review and a five-minute Friday update.
What happens to the Scrum Master role?+
It does not exist in the builder pod. The Engineering Manager handles flow if a flow problem exists. The PM handles outcome alignment. The retro becomes a 20-minute kill list review where the team retires bets that aren't paying off. There is no separate role whose work is 'facilitating the framework.'
Doesn't agile have valuable principles even if Scrum is broken?+
The agile manifesto's four values are still defensible. The problem is that Scrum (and SAFe, and the broader ceremonial layer that grew on top of agile) became the proxy for the principles. Killing Scrum does not mean abandoning iteration, customer feedback, or working software. It means abandoning the ceremony that claimed to deliver those things and rarely did.
Is this just Falk's agile-is-a-coping-mechanism post again?+
Adjacent. The agile-coping-mechanism post is the structural argument (planning ability vs build speed). This is the Scrum-specific argument. Both share a thesis: the framework was a 2010s coping mechanism that no longer matches the build speed and signal cycle of a 2026 product team.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn