Barry Boehm sort of summarised this fairly well in Balancing Agile and Discipline, although I'm sure he would disagree with my characterisation of it:

- If you have unpredictably changing requirements, and a small-ish non-life-critical product to build, and a large fraction of good people on the team, you should use an agile process.

- If you have unchanging or predictably changing requirements, and a large fraction of not-so good people on the team, you should use a plan-driven process.

But what if you have unpredictably changing requirements and a large fraction of not-so good people on the team? No process can save you now.

Yeah, but scrum can overcome yes-yes by taking a bunch of skilled and motivated people and forcing them into an ineffective process. That is exactly what happened in my last team.

So those skilled and motivated people are estimating piecemeal tickets, too micromanaged to be able to fix actual issues they clearly see around them. It is forced helplessness You can't overcome bad process and scrum is a bad process.

Scrum advocates always end up blaming the people on team. Even if that exact same team was performant and scrum literally killed 70% of what was good in it.

But people are a ceiling, not a floor.

Of course process can't make bad programmers good.

But good process can dramatically improve the value delivered by a team of good programmers. People don't spontaneously self-organize in optimal patterns of internal communication and accountability and external communication, no matter how self-motivated and high-performance they are.