There is a very concrete advantage over conventional pre-Agile project management as applied to software development projects: If you do a critical path analysi

There is a very concrete advantage over conventional pre-Agile project management as applied to software development projects: If you do a critical path analysis, you need to at least guess at who will do which task in order to do "resource leveling" to make sure people are not over-scheduled. This is tedious, even if you have software that partly automates resource leveling. Then, a few weeks later, the project has encountered some previously unknown issues and you have to do it all again, or, worse, you stop updating the schedule. Iterative planning and on-demand task assignment foregos the precise estimation of pre-Agile approaches, but those estimates were wrong anyway because software implementation tasks are too often unique and hard to predict. Agile "boot camp" courses do not teach this, and the consequences of this and related differences from previous approaches. The downside there is that Agile practitioners can't defend Agile from skeptics, and they try to take Agile where it should not go. "Planning poker" and "Agile metrics," which sounds to me like "diet snacks," are the result of not knowing why pre-Agile project management sucked for software. The SAFe elaboration of Agile is the sum of all these horrors. There is enough to warn people about to fill at least a slim trade paperback.