Agree with that, mr_mischief. Totally. It is much better to break a project down into small pieces whose completion and roll-out can be meaningfully overlapped. That part of the Agile idea is very good. The breakdown occurs in actual practice when the team is “pantsing” its way along, in a way that results in great amount of rework and a significant amount of “churn” in the source-code base. Uncomfortably soon, no one really knows what’s in and what’s out, what’s done and what’s not. Agile trusts the idea of a “self-directed team” far too much. A programming team simply cannot opportunistically direct itself.
A team should be able to move quickly and to make meaningful progress in short installments. but, each time it does move, the move should “stick,” and go from one point of provable integrity and stability to the next one without “suh-prize” along the road. This takes real, dynamic, planning. Strategy, not just tactic.
Instead, what do we get? Weekend courses to teach you how to pour magic voodoo-sauce onto any project. The myth of the “abstract I-can-manage anything PM,” taken to a new level of absurdity ... for profit.
