I found a critique of Agile by Donald Patti at The Project Management Hut . I thought his comments were measured and thought out. It’s nothing I haven’t seen before, for examply by Boehm and Turner.
I was surprised at how personal some of the comments were. I have some opinions that I will share as I find the time to write them up coherently. By and large, I think Donald is right. On the other hand, agile can be adapted. I cannot agree with much if any of the responses however.
Let’s start with architecture.
The alternative to architecting isn’t not architecting, it’s poor architecting. Every component of the system will depend upon the architecture. Often, there are some non-functional properties of the system that must be satisfied. Find out what they are and support them early. If it isn’t mostly right before major development begins, you will have a lot of rework. That is hardly minimizing the work not done.
My colleagues in the architecture program are spending a lot of time working on architectural solutions and how to integrate them with agile construction techniques. If there were no problem, they would be wasting their time. On a non-trivial system, my experience indicates that spending about 10% of your budget and maybe 5% upfront schedule architecting will reduce program size, cost, schedule, and rework. I hope we will have a case study complete sometime next year.
On the issue of waterfall, that is a red herring, please don’t bother to compare non-agile to “waterfall”. Most of us born before the 1980s know that “waterfall” was almost never actually used. It was a straw man example Royce used to compare and contrast other workable incremental variations. Boehm published spiral in 1976 and it wasn’t new at that time. I’ve never used waterfall, I’d bet Donald never used it either. The world is bigger than “Agile” and “waterfall”. Name calling is not productive argument.
On the issue of scaling, Capers Jones has a lot of data that indicates Agile is not associated with very large projects. It works very well in small to medium (roughly defined as <10000 function points. (that is between a quarter and half million LOC in C++ or C code) Hybrid approaches take over. If you want to challenge this, please bring data. Donald articulates the reasons that are commonly provided to explain this. Agile might still be used, but along with other heavier weight techniques.