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.
It's the reddest of the red flags to have such CTO. Modern incompetent CTOs are measuring performance by token spend. They are in the same bucket though - coming up with some dogmatic ways with extremely thin foundation.
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.
The careless tossing around of grandiose claims. Like within the span of a 15 min standup, 2 good pull requests and a _refactor_ (refactoring its previous PRs??) and updated docs happen on average, on a single terminal btw. In a given day for a 3 person team how many prs (and refactors) is that?
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.
The article gave me the impression we are all using AI and agentic AI to do all work now and agile doesn’t fit that model… but that’s far from where our team sits. It correctly calls out that our ceremonies have gotten so mundane they are worthless. Our standups consist of all engineers simply saying “no blockers” otherwise our product manager who isn’t technical will try to get involved to “help” and double/triple the work. Our refinement is our product manager rearranging our backlog while engineers just say “looks good!”. Our sprint end/start never correlates to any actual start or finish of work. We haven’t demoed anything since before the pandemic. But the ceremonies are all SUPER quick (5 min standup <30 min for all else) and serve as a general check in to get the temperature of the room, and maybe learn of some priorities from our manager (top down) we didn’t have awareness of.
But what we actually do is deliver micro changes often, engage directly with our users to tell them of updates (usually a slack blast) and provide them tons of opportunities to share ideas and feedback. That’s far from the old big quarterly release days. I probably incorrectly call that agile. So what is it?
“Quickest ceremonies to appease managers where we learn of new hot priorities from top down and say ‘no blockers’ then after that we get back to work delivering what’s needed for our regular user base.” Has a certain ring to it I think.
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.
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.
Flexible sprint durations defeats the purpose of sprints. One of the main selling points of sprints is having a fixed time period of work, allowing teams to better understand the amount of story points they can complete in a sprint. This way, a big piece of work that takes 500 story points can predictably be completed in 2½ sprints if it takes a team 200 story points per sprint.
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.
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.
See? Nobody agrees with me here, even. The whole software dev business is a joke, really. You know, I believed harder than anyone for years and years. But the lack of true intellect on here and in the working world is an eye-opener. You all live in the Matrix, I can't help you. Am logging off and never logging back in.
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.
It's the reddest of the red flags to have such CTO. Modern incompetent CTOs are measuring performance by token spend. They are in the same bucket though - coming up with some dogmatic ways with extremely thin foundation.
She didn’t last long.
I had a CTO like that.
Didn’t last long either.
Sadly, neither did the company.
> 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'm not actually sure who you are mad at here.
The careless tossing around of grandiose claims. Like within the span of a 15 min standup, 2 good pull requests and a _refactor_ (refactoring its previous PRs??) and updated docs happen on average, on a single terminal btw. In a given day for a 3 person team how many prs (and refactors) is that?
lines of code != productivity
Especially today where LLMs have been reinforced and trained to spew tokens
A gentle reminder that the task of Engineering is to (1) reduce costs and/or (2) increase revenue
If you aren't doing either. You are faffing around. No matter the jargon jiu-jitsu you do on your quarterly performance self-review :)
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.
The article gave me the impression we are all using AI and agentic AI to do all work now and agile doesn’t fit that model… but that’s far from where our team sits. It correctly calls out that our ceremonies have gotten so mundane they are worthless. Our standups consist of all engineers simply saying “no blockers” otherwise our product manager who isn’t technical will try to get involved to “help” and double/triple the work. Our refinement is our product manager rearranging our backlog while engineers just say “looks good!”. Our sprint end/start never correlates to any actual start or finish of work. We haven’t demoed anything since before the pandemic. But the ceremonies are all SUPER quick (5 min standup <30 min for all else) and serve as a general check in to get the temperature of the room, and maybe learn of some priorities from our manager (top down) we didn’t have awareness of.
But what we actually do is deliver micro changes often, engage directly with our users to tell them of updates (usually a slack blast) and provide them tons of opportunities to share ideas and feedback. That’s far from the old big quarterly release days. I probably incorrectly call that agile. So what is it?
“Quickest ceremonies to appease managers where we learn of new hot priorities from top down and say ‘no blockers’ then after that we get back to work delivering what’s needed for our regular user base.” Has a certain ring to it I think.
(Edited for typos and clarity)
> I probably incorrectly call that agile. So what is it?
It’s so agile it doesn’t have a name!
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.
Is there, in Scrum, a meeting "to plan the meetings about the meetings", as the critique suggests?
My understanding is there are 3 meetings in core scrum:
- planning (which is not about planning meetings, but about breaking down work)
- review
- retrospective
None of those are 2nd or 3rd order "meeting planning" meetings.
If people throw in backlog grooming or other sessions, that's up to them.
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.
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.
Flexible sprint durations defeats the purpose of sprints. One of the main selling points of sprints is having a fixed time period of work, allowing teams to better understand the amount of story points they can complete in a sprint. This way, a big piece of work that takes 500 story points can predictably be completed in 2½ sprints if it takes a team 200 story points per sprint.
“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 :)
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!
It does! Thanks so much!
> 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.
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.
Mobile safari reader view fails too with this layout / style.
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.
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.
> This essay is not a hot take. It is an autopsy.
This essay is AI slop with a fancy website design.
Another article that passionately devalues testing. It should be called “shrug and ship.”
But at least it dares to throw out stuff that doesn’t make sense.
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.
See? Nobody agrees with me here, even. The whole software dev business is a joke, really. You know, I believed harder than anyone for years and years. But the lack of true intellect on here and in the working world is an eye-opener. You all live in the Matrix, I can't help you. Am logging off and never logging back in.