[roenxi]

The evidence is in the company choosing scrum then sticking with it. They believe it helped.

> I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.

It is too hard to argue from vague anecdotes, so I am resisting the urge to try. However, I will say that if that is a demonstrable thing and there was no upside then it would be surprising that scrum sticks as well as it does.

[carlmr]

>scrum then sticking with it. They believe it helped.

Not necessarily. It's well known that there are many psychological biases in favor of keeping the status quo. Whether it's the sunk cost fallacy, the escalation of commitment or the endowment effect.

Humans tend to stick with bad decisions way longer than rational.

https://en.wikipedia.org/wiki/Escalation_of_commitment#/sear...

I think the problem here is we've had a huge trend in switching to scrum, but then people stick with failed scrum because it's the new status quo. Switching back to waterfall can't be sold by consultants. Even if it would help.

[ath3nd]

> However, I will say that if that is a demonstrable thing

It's demonstratable: https://www.theregister.com/2024/06/05/agile_failure_rates/

> and there was no upside

I'd go on a sarcastic rant here, but it's hard to stop myself. Don't read further if exaggerations upset you.

Sure, there are upsides, but they are hardly benefitting software engineering speed, quality, stability and developer happiness. The biggest upsides are for management:

- keeping the engineers under tight control by one of their business types (PO)

- making sure long-term thinking (like "what am I doing in this company") is suppressed by having a horizon of only 2 weeks in which you are supposed to give all you have to hit an arbitrary deadline. And then you start again! /s

- scrum has the beautiful effect of making engineers feeling either like kindergartners:

1. what did you do yesterday, Timmy? (standup)

2. Let's play with some cards, kids (planning poker)

3. Let's review what we learned last two weeks, children, and let's see what progress you made on your bean drawings (retros and demos)

How can you want a salary increase or question big man POs decisions, when you've just been acting like a kid for the last two weeks? Don't get me wrong, I do see the benefit of retros, demos, and some kind of planning and sync, but the way scrum just dumps it on you and prescribes you how to do it is just humiliating. Adults can sync, plan, retrospect and demonstrate what they did on their own volition and don't need some framework to tell them when and how, and two parental figures (the PO and Scrum master) to tell them what to do and when.

> The evidence is in the company choosing scrum then sticking with it. They believe it helped.

Many people also believe the Earth is flat and are sticking with that belief.

[ramblerman]

> How can you want a salary increase or question big man POs decisions, when you've just been acting like a kid for the last two weeks?

I think you just provided me with a small epiphany...

[marcosdumay]

About that article.

We absolutely learned something since the 90s that was beneficial. Corporative software projects now have about a two times higher chance of success than they had back then.

Also, we almost certainly learned that thing from Agile. There is no other credible source.

But the article has a clear point that places where people say they are practicing Agile has an even lower success rate than the overall one from the 90s. So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.

[ath3nd]

> We absolutely learned something since the 90s that was beneficial.

Yes, software engineering has evolved, but to attribute its successes to the methodology used is like attributing higher cancer survival rates to better hospital management. In reality, it's due to the availability of better drugs, more understanding, and a lot of R&D, and it has 0 to do with management. Same with software engineering: we use better tooling, libraries, hardware is more commodified, and a lot of things we don't have to do ourselves. All things that have nothing to do with the methodology.

> So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.

No methodology/manifest and no amount of management can compete with smart, qualified adult people being invested in their craft, and having autonomy and ownership on what they are building. The projects that succeeded are projects having those people, regardless of the methodology. In a way, people succeeded despite Agile, not because of it.

[carlmr]

>two parental figures (the PO and Scrum master)

Another great point. The overhead is insane. 2 people that don't directly contribute work output per team.

[rerdavies]

Could it possible be that.... you're not doing it right. lol

It is another great point. But it is another great point about how the process in your organization could be improved. Nothing says you have to have two parental figures.

And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor. Just have one part-time scrum master in the entire company who periodically audits and coaches teams who aren't doing the process right. Or coaches teams through the initial learning curve, as required.

In scrum and non-scrum processes that I have worked with, the PO comes from the marketing/sales team. On the theory that, if anyone has the pulse of what customers in aggregate actually want, it's going to be them. Also a part time job. But essential for injecting some realistic sense of "value" into the development planning equation. The direct contribution of a good PO is to make sure that the team is contributing work output to features that customers actually want. A good PO contributes enormously to team productivity.

[lpapez]

> And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor.

At most places I worked, having a dedicated Scrum Master on the project was the norm.

Yet another case of "it's not Scrum's fault everyone is doing it wrong".