Would have loved to see the author include a section on Extreme Programming.

Probably the biggest disservice done by Scrum was changing our thinking and language around methodology. It made it so that if something was going to displace it, it had to start with a capital letter, be a "real" version of something, and have a lot of institutional momentum behind it. It acted like some kind of social exploit--one we had no immunity to.

So, we ended up stuck with it, suffering untold millions of hours wasted in useless meetings and untold creativity crushed since it didn't fit into the process. We should've just tossed the notion that there's some kind of planning structure that makes sense across all possible projects, then done whatever made sense for our specific environments, not put a name on it, or even talked about "methodology" much at all.

All these frameworks and still Common Sense reigns supreme yet rarely applied.

I like how kanban and agile are "alternatives" as if they're not very similar to how scrum it's defined.

This is a weird and unbalanced selection... I expected to see waterfall or some variation on here, but nothing like it, even though it is very common. Lots of mentions of evolving & fully-autonomous engineering structures without even mentioning how this interfaces with all the other parts of every company larger than a few people. Valve's approach is not really a methodology vs. a perk from generating ridiculous per head revenues for a pretty small company. Shape up can only work as described when your company is small and run by a benevolent dictator will complete control.

The subtext of the article seems basically to be that the author does not want to estimate tasks. Which is nice when someone else pays. It is less nice when you have to pay however.

This reads like someone which had bad management using effort estimates as hours and bugged the team about it. I'm saying that having seen plenty of environments where they do Scrum wrong.

> Because there are no sprints, you don’t have to worry about whether something fits into a sprint

I like fitting things into sprints. It forces tasks to be broken down into manageable items. If it's too big to fit, it's also probably ill-defined. Sometimes it goes over the sprint; it's alright; discuss during retro and learn from it.

> If an emergency arises, everyone pauses their work

You can still do that with Scrum. Scrum is a framework to estimate the effort and measure at fixed points in time. That's not an excuse to dismiss issues. Unless all of your work is unplanned, you can handle surprises AND estimate your leftover velocity.

I thought they debunked the "Spotify model" as something being promoted by a few consultants but also being phased out at the same time as being exposed to the public (nearly 10 years ago in 2014).

There are dozens of articles about the problems with matrix management that it introduced.

"When you finish a task, you simply pull the next one from the top of the backlog”

Please, no. When you've finished a task see if you can help with a blocked or in-flight task.

Teams win points for finishing work, not starting new work.

> Can you feel the energy of a software industry eager to break free from the low-trust environments we’ve grown used to?

I beg your pardon, but Scrum did not fail because "it does not work", it fails because low-trust environment won't make room for an agile mindset. An I really hate the term "agile mindset", because it is overused. But if you give people responsibility and accountability, you can get a powerful, creative environment. Which, in turn, means that you need less management. Interestingly enough, middle management is usually not happy about that - so Scrum fails.

I'm no fan of Scrum, but some of these alternatives are completely inaccurate/outdated.

Spotify stopped following the "Spotify model" barely a year or two after the famous video released. The Valve handbook is from over a decade ago and (from what I've read online) is no longer relevant (if it ever even realistically was).

All of these screeds ultimately come down to one thing: "I don't like being managed".

It's the height of arrogance to say these frameworks like scrum are popular purely because managers are morons hell bent on destroying productivity.

If you don't like it, you've options. You can try get promoted to management and do a better job, but of course you don't like that - you'd rather burn countless hours playing with the next hottest framework. Or you can start your little LLC and go it alone, but of course you'll quickly find out what that's like as a programmer. Or you can spend all day programming unmanaged, on your own projects or open source - and find out the monetary value of that.