Professional project management (PMI) embraces critical path, iron triangle, risk management. Iteration was always The Correct Answer™.

Kids today conflate "throw it over the wall" with waterfall.

Agile rejects planning, foresight, vision, end goals. Agile was explicitly concocted to manage upwards, in those organizations unable or unwilling to do proper planning. Unfortunately, the originators wrote down their survival tips, which were then misunderstood by noobs and embraced by profiteers. Just like every other religious text.

Agile is not the victory of iteration over some imagined dark ages of project chaos. The Agile Methodology is to argue about the Agile Methodology. The cult(ural) spread of Agile is no different than any other vacuous self-help omni-fix content-free dogma.

Agile does not reject those things. That’s just a nonsensical statement at best and a straw man at worst.

Nothing in this discussion seems to even mention the most important part of agile: talking to customers often

Absolutely!

That's the genius of the Agile Methodology. Per the Zeroth Law of True Agility [0], we're both utterly correct. With no contradiction.

[0] The Agile Methodology is to argue about the Agile Methodology.

The obvious response is that PMI is a cargo cult. I mean if we're straw-manning everything.

The more interesting question is: Why did Agile beat PMI?

Because project management is not a critical success factor.

Most projects are late, buggy, or outright failures.

One response was to improve project management. That worked okay. But like with most knowledge work, requires some effort.

Another response was to accept the failure rate and simply throw more resources at the problem.

aka Worse is better.

Worse is Better is something else altogether.

But wasn't waterfall always a description of what not to do?

https://en.wikipedia.org/wiki/Waterfall_model#History

It was supposed to be. Then some brilliant folks at the US DOD wrote it into some documents on how to manage large scale software projects.

Any decent project manager know their people,so if Mark says it will take 2 days but in reality takes 5, the PM should see these patterns and either help the person to improve estimations,or adjust project deliverables based on this knowledge.

That's true if the project manager's personal and organizational incentives are to make estimates that are as accurate as possible.

For some people and organizations, the purpose of estimates is not primarily informational.

It's one of the many tools in the efficient tyrannical manager's toolbox, with a motto of "my goal is not to have you do effective work, my aim is to advance my goals and keep everyone below as a non-threat to those goals". Keep em busy and insecure.

Sure nice it doesn't work on competent developers, not with the current job market.

> One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.

We've only replaced the tyranny of deadline crunch with the tyranny of daily micromanagement. You can't even wipe your own ass without so much as a Jira ticket and half a dozen people signing off on it.

And despite all of the rigmarole and rituals, you still have deadlines. Doesn't matter what the Jira board says. If some upper management dickweasel wants their feature, they will get it. Forget the story points and estimates.

You should look up "Conjoined Triangles of Success". It might do something to heal that PTSD.