"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.
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.
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.
Would have loved to see the author include a section on Extreme Programming.
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.
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.
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.
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.