The Death of Scrum – Built for a slower world, performed by those who left
death-of-scrum.net
death-of-scrum.net
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.
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.
Didn’t last long either.
Sadly, neither did the company.
Screw you
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 :)
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?
And also fuck scrum and purist agile too.
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.
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)
It’s so agile it doesn’t have a name!
I dropped scrum last year.
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.
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.
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.
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.
The work moves - the ceremony doesn't follow it. Focused on shipping.
Works both in extremely high phase with AI, and for teams without it.
It is actually less SAD than SAFe
I ain't reading all this AI crap. Just do a "buy me" website.
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.
In such situations something's got to give. My choice is that the something is the rigid process. Because I think it's much preferable to make a plan with the whole team present.
It's not that big of a deal really. Flexibility doesn't mean we're always picking random sprint lengths, it means we make occasional concessions for real world constraints, which is kind of the point of Agile anyway.
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 :)
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.
im really curious how you think this is worse than the other way around
Here is a more static one: https://death-of-scrum.net/static/
I hope that helps!
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.But at least it dares to throw out stuff that doesn’t make sense.
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.
This essay is AI slop with a fancy website design.