I see what you're saying, although I'm not sure it's really moving in a direction I'd call agile. He clearly paints the fully "radical" end as unthinkable lunacy, when it's entirely doable in practice. And looking at figure 5.4, it's very much a document-oriented process. When compared with a modern, short-cycle Agile approach (continuous delivery, unit-of-work size in the 1-3 day range) all of the documentation he describes ends up being pure waste.
This part strikes me as especially absurd:
"How does a project manager decide whether to adopt a radical or conservative approach? Basically, there is no right answer; the decision is usually based on the following factors:
* How fickle is the user?
* What pressure is the project team under to produce immediate, tangible results?
* What pressure is the project manager under to produce an accurate schedule, budget, and estimate of people and other resources?
* What are the dangers of making a major technical blunder?"
The contempt for users wrapped up in "fickle" is ridiculous, and ditto making business needs about "pressure". Most importantly, he hasn't even begun to recognize that a shorter cycle yields significant business benefits, even though that was being written about at least a half-dozen years before this book.
So I read this more as typical waterfall thinking with some concessions to practical reality (which is how waterfall has always been done) than anything relating to a modern approach. He doesn't say, "You must stop the world for 100% of your project!" But the fastest he's willing to describe is, "Stop the world for 50% of your project!" The notion that you could stop the world for 1% or less of your project (which is what happens with weekly cycles for a project of 2 years or more) is to him beyond ultra-radical. (Let alone a good kanban approach, where the cycle time drops into the hours-to-days range.) When instead I'd submit it's in reality the most conservative approach, in that it minimizes all sorts of risks.
This part strikes me as especially absurd:
"How does a project manager decide whether to adopt a radical or conservative approach? Basically, there is no right answer; the decision is usually based on the following factors:
* How fickle is the user?
* What pressure is the project team under to produce immediate, tangible results?
* What pressure is the project manager under to produce an accurate schedule, budget, and estimate of people and other resources?
* What are the dangers of making a major technical blunder?"
The contempt for users wrapped up in "fickle" is ridiculous, and ditto making business needs about "pressure". Most importantly, he hasn't even begun to recognize that a shorter cycle yields significant business benefits, even though that was being written about at least a half-dozen years before this book.
So I read this more as typical waterfall thinking with some concessions to practical reality (which is how waterfall has always been done) than anything relating to a modern approach. He doesn't say, "You must stop the world for 100% of your project!" But the fastest he's willing to describe is, "Stop the world for 50% of your project!" The notion that you could stop the world for 1% or less of your project (which is what happens with weekly cycles for a project of 2 years or more) is to him beyond ultra-radical. (Let alone a good kanban approach, where the cycle time drops into the hours-to-days range.) When instead I'd submit it's in reality the most conservative approach, in that it minimizes all sorts of risks.