I don't know, it seems popular to complain about Scrum on here, but I've never had that many problems with it. I've both been in the team, and acted as the manager.
I think most of the failures come down to that all those rituals have a reason for them, but that only works if the team is actually on board. That needs a good manager in place, somebody who understands what the point of it all is, pushes people in the right direction, and adapts to problems. There's a lot of room for minor changes as needed.
Take the first complaint, "My standup is people reading Jira tickets out loud". That's obviously wrong. Jira's already there for everyone to look at. Standups to me are mostly about the non-obvious things. It's where John announces he's figuring the build system needs a bit of a change, so that might conflict with other work. Where Carol complains that the ticket is taking ages because testing takes too long. Where Bob says he's not making progress because there's this weird thing with this API, and does anyone know what's up with this?
Now I'm not going to say Scrum is a magic wand or anything. It's just a bit of structure that IMO is overall a pretty decent idea overall, I just have a feeling that some organizations get lost in the bureaucracy and forget that the point is getting stuff done.
My personal biggest issue with Scrum in years of dealing with it is that I think sometimes teams should be split up. I've been on teams where a project is really made of parts with little overlap, and IMO in such a case you should consider splitting the team, because you can end up with situations where people sit through meetings where they have nothing useful to contribute. That's about the biggest time waster I've personally noticed.
My favorite scrum story: When I worked at reddit, we were still owned by Condé Nast, and we worked in the corner of the Wired magazine office. Condé Nast got a new CTO, who was completely all-in on agile. To the point that she called everyone into a conference room to read us the agile manifesto word for word.
We then went back to our little corner conference room and continued to build things in an agile way, like we had been doing for years, without all the meetings.
The poor Wired folks suffered a worser fate, and had to have all the meetings.
I'm not actually sure who you are mad at here. The engineer who is being super productive with AI, or the author for suggesting that an engineer can be that productive with AI.
I think I like this article and I haven't finished it yet, but I don't think the bottleneck has shifted to non-human with the advent of agentic AI. It's still the human (deciding what product direction to take, reviewing code, etc)
Yes this is my observations. Task chunking, Sprints, MVPs - A lot of this exists because it makes the human process simpler to go through but now this is not the limitation anymore. Deciding what to do what will drive value was always the most important thing and it now became more critical than ever.
Correct. The constraint is the human’s ability to internalize and make tradeoffs. This will continue to shift and there will be fewer decisions that rely on humans relative to the work being completed, but the humans will still remain the constraint in many types of complex work for some time to come.
I was a manager when we merged with our competitor. I was in a committee to decide what committees were needed for the new, joint company. I left shortly for a startup...
People must realize that it's people who book meetings, not processes.
And some of them book meetings to try to justify their presence.
Blaming scrum for having meetings on the calendar is a scapegoat. You will have those meetings show up regardless of what processes you chose to replace scrum.
in fact, I like this topic, because usually people use the motte and bailey of Agile. (as in, Agile is a manifesto to some, or a process to someone else) but scrum is super well defined, and it is defined by: structured meetings.
I have been feeling that something - a few things - has to change about Agile rituals given a team is using Claude extensively. I haven't yet found any thoughtful writing on the topic.
The most obvious impacts have been shorter synchronous conversations for planning and refinement because so much more specification is written. I've also found myself doing more spiking.
The thing is, all the changes I see to Agile are matters of degree, not fundamental breaks with the Agile manifesto or tradition. I'm not sure whether that's because a) all that's needed is tweaks or b) because the existing way of doing Agile is so in-grained that it's hard to see that it doesn't fit today's reality.
Interesting idea if you write it yourself. Genuinely if you think the article isn’t worth the time to write yourself why should anyone give the time of day to read it? God damn
So an author whose company sells AI tools to organizations has published an AI-written sensationalist website detailing how horrible the "old way" of doing things is, in the hope that more people will pay them for their "new way" products. Wow, color me shocked.
Yeah, this seems like it could have been a few paragraphs. It goes on and on.
I’ll give my hot take without reading.
I’ve been in a lot of kinds of scrum and it seems like a YMMV thing. The most effective scrums are the ones which start from first principle and create a process for the teams current needs.
Many of the most effective ones worked out of a spreadsheet or Google doc rather than an issue tracker. Sometime the PM would update the issue tracker behind the scenes to keep devs out of it.
Anyways, my point is that most effective things are custom built rather than trying to apply a blanket process across a company or to different situations.
LLM slop article. But as for the topic: To me, "Kanban with refinements and retrospectives" is the sweet spot. The concept of Sprint seems not only superfluous but to add unnecessary rigidity. But you do want everyone to understand the tickets, so refinements are useful, and you do want to try and improve "meta" issues where possible (and have the amount of effort going into that limited so you don't end up in the methodology equivalent of yak shave hell), so retrospectives are useful, too.
When I was doing the scrum master role I just did sprints flexibly.
It's not a law of the universe that there's got to be a sprint every 2 weeks. For instance I'd schedule them around holidays and vacations. Try to make sure for instance that the next sprint planning coincides with a team member returning from vacation. That way they're in the loop about where things are at, and we don't make a plan based on some assumption of what Bob might do when he returns mid-sprint without him being there.
Overall I think sprints are a fine idea, projects can be complex, it makes sense to me to periodically sit down and figure out if we're getting there or not and what the next steps are. We'd also try to have demos each sprint to make sure that something actually works.
Big picture, it's all kind of funny. Over a decade ago, I ended up having to be an undergraduate instructor in Project Management (despite zero experience in it) and kind of speedrunning all of that philosophy. And then, learning the "new" things like Agile, Waterfall, Scrum, whatever.
It was immediately apparent to me why these existed, it was because "software development" somehow collectively decided to abandon core principles of PM.
Like the most basic stuff, e.g. Projects have a beginning and an end.
I chose to not take any of it too seriously in terms of what I taught undergrads, and post-mortems like this make me feel quite justified in that.
Specs need detail and refinement. Generated code still needs reviews, edits, and perhaps iterations and extra tests. None of this is automatic or fast.
There an aspect of this that I find it hard to describe in words but I will try here. The shift I observe is that we are moving from a step curve to a smoother curve; The development cycle has never been so fluid and focused on the outcomes than it is (Or should be) today.
The interactivity seems to be a substitute for coherent global organization (and a rationalization by the human author for not reviewing the LLM's strange stylistic / wording choices). It's incredibly distracting, and fatally weakens the argument! The entire time I was thinking "ok, then we just do the same old scrum on specs instead of code, seems like the human management advantages are still as relevant as ever." Perhaps if this were written as an essay the author could have collected their own thoughts a little better and addressed this point. They only did, offhandedly at the end.
UGH I tried to copy-paste that part ("Start writing specs in a way..."), but I couldn't because of this obnoxious fucking interactivity! Why write an essay if people can't share the parts they find interesting???? Again this stuff is designed to impede critical long-distance thought by throwing up a bunch of short-range distractions. It even works on the humans and LLMs writing it. This essay really is incoherent.
Also as someone who used to work manual QA for fairly sensitive finance/pharmaceutical software, this part is darkly funny (I actually could put it on my clipboard, god I hate JS):
Then · circa 2001
6 weeks
Submit code. Wait for QA. Get a bug list. Negotiate. Fix. Wait again.
Now · 2026
6 seconds
Type, save, hot-reload, AI suggests a fix, tests run in parallel. The build itself talks back to you.
"AI suggests a fix" but who finds the bug? AI, I suppose. Good luck with that. Meta is desperately training AI to use a mouse correctly by snooping on its tens of thousands of its own workers. A very important part of my job was clicking on stuff. Maybe in a few years of mass surveillance AI will figure it out. Until then, it seems like Mantyx needed to hire a human who knows how to use a computer and review this website. It's incredibly hard to use because it's obviously vibe-coded. HIRE HUMANS TO AT LEAST LOOK AT YOUR SOFTWARE. Even if it's just a website.
Speaking of, it's so depressing to see this written by an actual company trying to sell stuff:
Treat agents as teammates
Specify, dispatch, and verify. Stop treating AI as autocomplete; start treating it as a junior engineer who works at machine speed.
Junior engineers: do not work at Mantyx! They have announced their intentions to mistreat you. It's LLM-boosted corporate hideousness.
I've been hoping for a paradigm shift away from scrum for years! It was good for like 5 minutes after it replaced Waterfall and then it morphed into a freaking hellscape of grifters and non-techies invading the business space. It's never worked out, never! Some of the ceremonies are fine, but overall, it's crap. And people live it like a religion and become angry if you complain about it. It's a freaking work process, not a religion! All it did in large enterprises was become another way to bludgeon developers and take away their agency. Hmm, I recall it was supposed to be ABOUT the developers, not about JIRA and filling out all the idiotic fields in the JIRA tickets. Story points, t-shirt size estimates, RETROSPECTIVES--that never, ever, not even once, led to a positive change. All so a bunch of r/e/t/a/r/d/s who say things like "I'm not very technical, but here's what I think..." to which I always responded--"If you're not very technical, then what makes you think you can lead a technical process?" Idiots and scammers.
I don't know, it seems popular to complain about Scrum on here, but I've never had that many problems with it. I've both been in the team, and acted as the manager.
I think most of the failures come down to that all those rituals have a reason for them, but that only works if the team is actually on board. That needs a good manager in place, somebody who understands what the point of it all is, pushes people in the right direction, and adapts to problems. There's a lot of room for minor changes as needed.
Take the first complaint, "My standup is people reading Jira tickets out loud". That's obviously wrong. Jira's already there for everyone to look at. Standups to me are mostly about the non-obvious things. It's where John announces he's figuring the build system needs a bit of a change, so that might conflict with other work. Where Carol complains that the ticket is taking ages because testing takes too long. Where Bob says he's not making progress because there's this weird thing with this API, and does anyone know what's up with this?
Now I'm not going to say Scrum is a magic wand or anything. It's just a bit of structure that IMO is overall a pretty decent idea overall, I just have a feeling that some organizations get lost in the bureaucracy and forget that the point is getting stuff done.
My personal biggest issue with Scrum in years of dealing with it is that I think sometimes teams should be split up. I've been on teams where a project is really made of parts with little overlap, and IMO in such a case you should consider splitting the team, because you can end up with situations where people sit through meetings where they have nothing useful to contribute. That's about the biggest time waster I've personally noticed.
My favorite scrum story: When I worked at reddit, we were still owned by Condé Nast, and we worked in the corner of the Wired magazine office. Condé Nast got a new CTO, who was completely all-in on agile. To the point that she called everyone into a conference room to read us the agile manifesto word for word.
We then went back to our little corner conference room and continued to build things in an agile way, like we had been doing for years, without all the meetings.
The poor Wired folks suffered a worser fate, and had to have all the meetings.
> By the time the meeting ends, an AI agent in a teammate's terminal has shipped two pull requests, refactored a service, and updated the docs
Screw you
I'm not actually sure who you are mad at here. The engineer who is being super productive with AI, or the author for suggesting that an engineer can be that productive with AI.
I think I like this article and I haven't finished it yet, but I don't think the bottleneck has shifted to non-human with the advent of agentic AI. It's still the human (deciding what product direction to take, reviewing code, etc)
Yes this is my observations. Task chunking, Sprints, MVPs - A lot of this exists because it makes the human process simpler to go through but now this is not the limitation anymore. Deciding what to do what will drive value was always the most important thing and it now became more critical than ever.
Correct. The constraint is the human’s ability to internalize and make tradeoffs. This will continue to shift and there will be fewer decisions that rely on humans relative to the work being completed, but the humans will still remain the constraint in many types of complex work for some time to come.
And also fuck scrum and purist agile too.
If you're having meetings about meetings, you're not doing scrum or agile. You're probably trapped in "agilefall."
I was a manager when we merged with our competitor. I was in a committee to decide what committees were needed for the new, joint company. I left shortly for a startup...
“We hold a meeting to talk about the meetings, and another to plan the meetings about the meetings.“
I dropped scrum last year.
People must realize that it's people who book meetings, not processes.
And some of them book meetings to try to justify their presence.
Blaming scrum for having meetings on the calendar is a scapegoat. You will have those meetings show up regardless of what processes you chose to replace scrum.
Lies, damned lies.
SCRUM by definition is meetings.
in fact, I like this topic, because usually people use the motte and bailey of Agile. (as in, Agile is a manifesto to some, or a process to someone else) but scrum is super well defined, and it is defined by: structured meetings.
I have been feeling that something - a few things - has to change about Agile rituals given a team is using Claude extensively. I haven't yet found any thoughtful writing on the topic.
The most obvious impacts have been shorter synchronous conversations for planning and refinement because so much more specification is written. I've also found myself doing more spiking.
The thing is, all the changes I see to Agile are matters of degree, not fundamental breaks with the Agile manifesto or tradition. I'm not sure whether that's because a) all that's needed is tweaks or b) because the existing way of doing Agile is so in-grained that it's hard to see that it doesn't fit today's reality.
Interesting idea if you write it yourself. Genuinely if you think the article isn’t worth the time to write yourself why should anyone give the time of day to read it? God damn
I am a big fan of the Scaled Agile DevOps Maturity Framework and it's certificates: https://scaledagiledevops.com/certifications/
It is actually less SAD than SAFe
So an author whose company sells AI tools to organizations has published an AI-written sensationalist website detailing how horrible the "old way" of doing things is, in the hope that more people will pay them for their "new way" products. Wow, color me shocked.
I ain't reading all that. I'm happy for you tho, or sorry that happened.
I ain't reading all this AI crap. Just do a "buy me" website.
“Interactive obituary - 22 min”
Ugh is there a regular text version I can read at my own pace?
Also why light text on black background? Hurts my eyes and is very difficult to read.
Guess I’ll wait for someone with more patience and better eyesight to maybe provide a summary or something :)
Yeah, this seems like it could have been a few paragraphs. It goes on and on.
I’ll give my hot take without reading.
I’ve been in a lot of kinds of scrum and it seems like a YMMV thing. The most effective scrums are the ones which start from first principle and create a process for the teams current needs.
Many of the most effective ones worked out of a spreadsheet or Google doc rather than an issue tracker. Sometime the PM would update the issue tracker behind the scenes to keep devs out of it.
Anyways, my point is that most effective things are custom built rather than trying to apply a blanket process across a company or to different situations.
Nearly 100% of the scrum processes I was involved with at Fortune 500 companies were top-down mandates that could not be deviated from.
hey! Sorry - I just always wanted to write a piece with some interactivity so maybe I went too far with this one.
Here is a more static one: https://death-of-scrum.net/static/
I hope that helps!
> Also why light text on black background?
im really curious how you think this is worse than the other way around
I don’t like “dark mode”. It’s blurry, makes me have to squint and hurts my eyes.
Mobile safari reader view fails too with this layout / style.
LLM slop article. But as for the topic: To me, "Kanban with refinements and retrospectives" is the sweet spot. The concept of Sprint seems not only superfluous but to add unnecessary rigidity. But you do want everyone to understand the tickets, so refinements are useful, and you do want to try and improve "meta" issues where possible (and have the amount of effort going into that limited so you don't end up in the methodology equivalent of yak shave hell), so retrospectives are useful, too.
When I was doing the scrum master role I just did sprints flexibly.
It's not a law of the universe that there's got to be a sprint every 2 weeks. For instance I'd schedule them around holidays and vacations. Try to make sure for instance that the next sprint planning coincides with a team member returning from vacation. That way they're in the loop about where things are at, and we don't make a plan based on some assumption of what Bob might do when he returns mid-sprint without him being there.
Overall I think sprints are a fine idea, projects can be complex, it makes sense to me to periodically sit down and figure out if we're getting there or not and what the next steps are. We'd also try to have demos each sprint to make sure that something actually works.
Big picture, it's all kind of funny. Over a decade ago, I ended up having to be an undergraduate instructor in Project Management (despite zero experience in it) and kind of speedrunning all of that philosophy. And then, learning the "new" things like Agile, Waterfall, Scrum, whatever.
It was immediately apparent to me why these existed, it was because "software development" somehow collectively decided to abandon core principles of PM.
Like the most basic stuff, e.g. Projects have a beginning and an end.
I chose to not take any of it too seriously in terms of what I taught undergrads, and post-mortems like this make me feel quite justified in that.
Flagged as sensationalist AI hype slop. No original or useful thoughts detected.
Website was too long.
ScrumMaster - a qualification you cannot fail. (Pls pay fee)
Ultimately big company look for things to help them sort their terrible product and software processes.
The whole point of agile, its that you don't know!
If you are SaFE, or 4 week sprints.. you are in management imposed bs.
Your company is a about to be eaten.
Specs need detail and refinement. Generated code still needs reviews, edits, and perhaps iterations and extra tests. None of this is automatic or fast.
There an aspect of this that I find it hard to describe in words but I will try here. The shift I observe is that we are moving from a step curve to a smoother curve; The development cycle has never been so fluid and focused on the outcomes than it is (Or should be) today.
> This essay is not a hot take. It is an autopsy.
This essay is AI slop with a fancy website design.
The interactivity seems to be a substitute for coherent global organization (and a rationalization by the human author for not reviewing the LLM's strange stylistic / wording choices). It's incredibly distracting, and fatally weakens the argument! The entire time I was thinking "ok, then we just do the same old scrum on specs instead of code, seems like the human management advantages are still as relevant as ever." Perhaps if this were written as an essay the author could have collected their own thoughts a little better and addressed this point. They only did, offhandedly at the end.
UGH I tried to copy-paste that part ("Start writing specs in a way..."), but I couldn't because of this obnoxious fucking interactivity! Why write an essay if people can't share the parts they find interesting???? Again this stuff is designed to impede critical long-distance thought by throwing up a bunch of short-range distractions. It even works on the humans and LLMs writing it. This essay really is incoherent.
Also as someone who used to work manual QA for fairly sensitive finance/pharmaceutical software, this part is darkly funny (I actually could put it on my clipboard, god I hate JS):
"AI suggests a fix" but who finds the bug? AI, I suppose. Good luck with that. Meta is desperately training AI to use a mouse correctly by snooping on its tens of thousands of its own workers. A very important part of my job was clicking on stuff. Maybe in a few years of mass surveillance AI will figure it out. Until then, it seems like Mantyx needed to hire a human who knows how to use a computer and review this website. It's incredibly hard to use because it's obviously vibe-coded. HIRE HUMANS TO AT LEAST LOOK AT YOUR SOFTWARE. Even if it's just a website.Speaking of, it's so depressing to see this written by an actual company trying to sell stuff:
Junior engineers: do not work at Mantyx! They have announced their intentions to mistreat you. It's LLM-boosted corporate hideousness.I've been hoping for a paradigm shift away from scrum for years! It was good for like 5 minutes after it replaced Waterfall and then it morphed into a freaking hellscape of grifters and non-techies invading the business space. It's never worked out, never! Some of the ceremonies are fine, but overall, it's crap. And people live it like a religion and become angry if you complain about it. It's a freaking work process, not a religion! All it did in large enterprises was become another way to bludgeon developers and take away their agency. Hmm, I recall it was supposed to be ABOUT the developers, not about JIRA and filling out all the idiotic fields in the JIRA tickets. Story points, t-shirt size estimates, RETROSPECTIVES--that never, ever, not even once, led to a positive change. All so a bunch of r/e/t/a/r/d/s who say things like "I'm not very technical, but here's what I think..." to which I always responded--"If you're not very technical, then what makes you think you can lead a technical process?" Idiots and scammers.