In a recent report, called Design and Acquisition of Software for Defense Systems, the Defense Science Board (DSB) has raised its influential voice on behalf of a move by the Department of Defense towards greater use of agile development approaches for software being developed for weapons systems.
DSB is a prestigious advisory body established more than 70 years ago to give DOD advice and recommendation on scientific, technical, manufacturing and acquisition issues. Its members are senior military, government and industry
The new report was commissioned by Frank Kendall when he was the Obama-era DOD undersecretary for acquisition. It begins by discussing the importance of the issue.
“While recognized as central to enterprise business systems and related information technology services,” the report states, “the role software plays in enabling and enhancing weapons systems often goes underappreciated.”
In fact, the report continues, “many of the capabilities provided by our weapons systems are derived from the software of the system, not the hardware. This shift from hardware-enabled capabilities to software-enabled capabilities is increasing quickly. As a 2017 paper published by the Institute for Defense Analyses notes, ‘The Department of Defense is experiencing an explosive increase in its demand for software-implemented features in weapon systems.’”
The new report has a fairly conventional discussion of the advantages of agile, which I suspect will provide few surprises to people who have followed the general debate on agile vs. waterfall: “The main benefit of iterative development the ability to catch errors quickly and continuously, integrate new code with ease, and obtain user feedback throughout the development of the application — will help the DOD to operate in today’s dynamic security environment, where threats are changing faster than Waterfall development can handle.”
There is an interesting discussion, which was new to me at least, of the advantages of agile for
Perhaps the most interesting thing about the DSB report is its publication right now. The report may be coming at just the right time. Stan Soloway — an old friend, former senior DOD acquisition innovation official from my government days in the nineties, and currently head of the consulting firm
Congress recently directed the Defense Innovation Board to study the use of agile software development for DOD. At the end of March, the DOD inspector general — not exactly an organization that is usually on the cutting edge of support for innovation — published a report entitled Contracting Strategy for F-22 Modernization. That report, which came out after the DSB report, criticized DOD for not developing a new contracting strategy to support a move to agile for software for the next generation of the F-22 fighter.
Even more recently, Defense Undersecretary for Acquisition and Sustainment Ellen Lord stated, “I believe we are at an inflection point in terms of doing things differently. We are pivoting from the traditional waterfall software development methodology to agile and
Soloway told me that, though there is uncertainty about how exactly agile will be implemented, “the debate is over. Agile is the way forward. I don’t think there is much debate anymore over its efficacy.”
At the end of the nineties, after a period when innovation was very much promoted in the procurement system, I noted a change in the delay between when a management innovation was developed in the private sector and when it came to government. When I entered the government in 1993, agencies were still buying off-the-shelf software in individual shrink-wrapped packages, though the private sector had moved to site licenses perhaps a decade earlier. (The government moved to site licenses later that decade.) By the late nineties, the gap between the introduction of reverse auctions in buying commercial items in the private sector and the government was down to a little more than a year. I was proud of that change.
Fast forward to agile software development. The “Agile Manifesto,” calling for a new way to do software development, was published in 2001, and over the next several years, agile started to spread in commercial software development — eventually becoming the standard way to do business. The idea didn’t really hit the federal government until about 2012 or
So we seem to be back to a 10-year gap between innovations coming to the private sector and
If agile starts becoming the common way to do business,
More broadly, the government needs to adapt its contract management processes to an agile world. The limited experience so far suggests that agile requires more, or at least different, contract management resources to allow frequent communication between customers and developers. (I am starting some research work on post-award contract management in DHS, and the people helping me out have told me this is their experience with agile orders.) Perhaps the TechFAR team at USDS and the Office of Federal Procurement Policy needs to be reconstituted to address such questions.
Republished from fcw.com with permission of the author.
Image Courtesy of Shutterstock
#All Government Levels