I’ve been reading some folders of "old" articles this week and ran across “The Profession of IT - Evolutionary System Development” by Peter Denning, Chris Gunderson and Rick Hayes-Roth. It appeared in Communications of the ACM in December of 2008 on pages 29-31. The specific link to the article’s index page on the ACM’s Digital Library website is:
Unfortunately, you need an ACM Digital Library subscription to access the whole article. There are References from the article listed on the index page which, in themselves, might be interesting reading, assuming you have the books listed and an IEEE Digital Library subscription. A couple of the references are available as PDF files describing U.S. government acquisition issues related to evolutionary and traditional development approaches.
What I’d like to do in this post is quote/summarize what seem to me to be the key things in the article.
To start with, here is the authors' last paragraph:
“All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work.”
In the last sentence the “process that does not work” is the traditional phased, sequential acquisition and development approach. For many, it may be assumed that this is required for government contracting. However, the authors say “that practices for adaptability are allowed under government acquisition rules.”
More surprising, perhaps, is the following:
“The U.S. Government Accounting Office (GAO) has scolded the government on several occasions for its uncommitted lip service to agile processes.4 The GAO believes agile processes could significantly shorten time to delivery, reduce failure rate, and lower costs. Many people resist the GAO advice because they assume careful preplanning minimizes risk and maximizes dependability and usability. However, more leaders are pushing for agile acquisition because the track record of the normal process in dynamic environments is so dismal.”
The “4” at the end of the first sentence of the quote refers to one of the references for two of the available PDFs:
“GAO. Defense Acquisitions: Assessments of Selected Weapons Programs. Report GAO -06-391 (Mar. 2006); http://www.gao.gov/new.items/d06391.pdf, and Information Technology: DOD Needs to Ensure That Navy Marine Corps Intranet Program Is Meeting Goals and Satisfying Customers. Report GAO -07- 51. (Dec. 2006); http://www.gao.gov/new.items/d0751.pdf. (Dec. 2006); http://www.gao.gov/new.items/d0751.pdf.”
Regarding the “sweet-spots” (my use of the term, not the authors) for both traditional and Agile approaches, the authors say traditional software engineering seems to have agreed that:
“preplanning is best for large systems where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.”
This idea has appeared in various places over the past 4-5 years. However, the authors “challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. Moreover, many small systems aim to be ultra-reliable.”
However, the authors admit that there are challenges to using agile methods on government projects apart from beliefs about their appropriateness. In particular, the authors say that there are “organizational impediments to information sharing” in government projects and reference Cao, L. and Balascubramaniam, R. Agile software development: Ad hoc practice or sound principles? IEEE Pro (Mar.–Apr. 2007), 41–47. [Note: The second author’s last name is Balasubramaniam, no “c” but the final “m” is correct; and IEEE Pro refers to IEEE IT Professional.]
There are some other details and some examples of projects and results, including a parallel implementation trial by the World Wide Consortium for the Grid (W2COG). This summary, I believe, and the references available, should help you start to pursue this topic further if you are interested.
As always, I would be glad to hear comments from folks with government contracting experience using agile methods especially discussing impediments overcome and how that was accomplished.