David Anderson has declared victory for Agile Development. Hopefully this is not the same declaration that our President made from the deck of the USS Lincoln. I'm sure it's not, since we've all learned from that to be a bit more cautious when announcing the solution to an intractable problem.
David's victory declaration is not without merit. The IT business is starting to talk about agile, employment ads for Program Managers and other "managers" are using agile terminology as a selection criteria. But as Yogi Berra is fond of saying
In theory there is no difference between theory and practice, in practice there is.
Not that there is a "theory" of agile development from which one can derive predictions. There are methods in practice though. These methods have some evidence of benefit. I have aerospace and non-aerospace clients that have made dramatic improvements in software quality and productivity using agile methods. I've even experienced these effects my self on occasion.
But declaring victory over what - an enemy of the state? David likely means victory over poor quality and budget / schedule. But if this is a victory it is a battle victory not the war victory. I use this analogy - possibly unlike David - from direct combat experience. Declaring victory is (was) a sporty business. In software development as well as South Vietnam, 1975 or Iraq.
What has been accomplished and what remains?
The principles of agile development and agile project management are now in practice in some domains, although the post mortem of these projects has yet to be performed, since the evidence is anecdotal. Customer engagement, fine grained feedback, testing in parallel or even before development, incremental and iterative requirements elicitation, followed by verification of the deliverables all have desireable outcomes.
Turns out of course that these principles were in place in "mature" organizations long before agile was mentioned. Probably long before David was out of short pants.
I was a FORTRAN programmer in the defense industry in the late 70's. I had learned to program as a physics graduate student and found a job doing signal processing for radar systems using the same FIR and Kalman filter code I used on particle accelerators. In that first job I had to pass through the layered security doors on the way to my desk. In the "good olde days," cubes where not used. We worked in bull pens, just like an XP shop does today.
There was a Big Visible Chart hanging in the hall way. It showed the master plan, the features of the radar system as a function of time, how many were in test and how many were installed on the flight article. This was before the web, so dashboards and online access was not available.
What's puzzling to me is how the concept of "being ahead of the curve," misses the previous generation or two's capabilities. The assumption that the processes of the past are "broken" and tossing out these processes and replacing them with a new paradigm is the way to salvation.
The implication that CMMI processes are somehow based on the absence of trust is one of the outcomes. As both a participant and manager of software development activities under CMMI processes, I'm wondering if those who rail against these processes have actually practiced them.
The Core Problem of Process Improvement
As a practitioner of business process improvement, I've learned the hard way that replacing one process with another is very sporty business. The suggestion that "we're doing this wrong and must start doing it in another way," usually meets with low success. Whether it is XP, New Product Introduction, Operational Excellence, or Proposal writing - each legacy process has its strengths and weaknesses. Replacing in total the previous process with a new one is simply bad management.
Declaring victory? Hardly since the problems of writing software for money are still there. All we've done is incrementally add some tools the arsenal of weapons in the war, maybe won a few local battles. The war continues.
