Waterfall planning + critical path analysis was too brittle for software projects. The choices were:
1. Frequent replanning, every 2-6 weeks
2. Stop replanning and try to meet an unrealistic schedule
Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway.
If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood.
Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal.
Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.
Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway.
If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood.
Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal.
Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.