Striking a blow for agile with DOD weapons systems

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 experts, often retired.

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 ongoing development of cyber defense capabilities. “Checking a software system’s code base daily keeps manageable the number of changes required to comply with a large base of cyber rules," the report states. "When a new vulnerability is discovered, additional rules are formulated to detect similar errors in code.”

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 Celero -- notes that the Defense Digital Service and Ash Carter’s DIUx, are turning out to be more influential than many predicted. This ties in to my conclusion in a blog a while ago that the U.S. Digital Service and 18F were becoming part of the federal IT ecosystem.

“To some extent it is the result of the uniform military leadership (think ‘customer’) pushing back against a traditional system that doesn't deliver,” Soloway said.

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 devops. So we are coding every day, testing every night.”

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, and has been spreading only gradually, though it has been spreading.

So we seem to be back to a 10-year gap between innovations coming to the private sector and their being adopted in government. That delay is far too long. If DOD gets serious about moving towards agile, this will be a tipping point for the use of agile in government. That’s a long time coming, but better late than never.

If agile starts becoming the common way to do business, government will need to grapple with how to do it right. The IG report on the F-22 modernization highlights a very concrete problem with contracting strategy, which is that traditional incentive fee methods to incentivize contractor performance do not apply so well when deliverables are not specified in advance, which will happen as agile spreads.

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.