Live data from Hacker News

The Death of Scrum – Built for a slower world, performed by those who left

death-of-scrum.net

41–50 of 51 posts

Re: The Death of Scrum – Built for a slower world, performed by those who left

#41
post #10

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…

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.

Re: The Death of Scrum – Built for a slower world, performed by those who left

#42
post #37
post #36

Earlier quoted context omitted.

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.

Re: The Death of Scrum – Built for a slower world, performed by those who left

#43
post #32

“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!

Re: The Death of Scrum – Built for a slower world, performed by those who left

#44

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 t…

> I probably incorrectly call that agile. So what is it?

It’s so agile it doesn’t have a name!

Re: The Death of Scrum – Built for a slower world, performed by those who left

#45
post #35

> 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?

Re: The Death of Scrum – Built for a slower world, performed by those who left

#47

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 me…

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 ass…

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.

Re: The Death of Scrum – Built for a slower world, performed by those who left

#48

Earlier quoted context omitted.

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 ass…

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.

True, but that's the theory, and there's the practical reality that is messy. Where things like almost the entire team being on vacation for Christmas happens. Or where Bob, coming back from vacation 2 days into a new sprint would find out that everyone made a plan without him being involved.

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.

Post reply on HN