The Defense Innovation Board wants to help the military recognize ‘agile BS’

A new guide aims to help leadership distinguish between substance and hype.
Defense Innovation Board Meets in Washington, D.C.
The chair of the Defense Innovation Board, Eric Schmidt, technical advisor at Alphabet, Inc., opens the public meeting of the board, at the Johns Hopkins School of Advanced International Studies, Washington, D.C., Oct. 10, 2018. (DOD / Lisa Ferdinando)

At its quarterly public meeting Wednesday, the Defense Innovation Board gifted the Pentagon with a new system to expose agile malarkey.

Specifically, the board wants to help military executives and software procurement officials recognize when a software development project is truly using the recommended agile development process and when it is simply a traditional project dressed up in hip language.

Enter the DIB’s draft guide, “Detecting Agile BS.”

“Agile is a buzzword of software development, and so all DoD software development projects are, almost by default, now declared to be ‘agile,'” the guide begins. “The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing.”


The document includes some key signs to look for in determining whether a project is truly following agile development practices as well as, conversely, flags that a project isn’t agile. Among the latter: “Meeting requirements is treated as more important than getting something useful into the field as quickly as possible.”

It also includes an overview of some of the popular tools currently used in agile development and a number of questions leaders can ask programming teams and management that may reveal what is (or isn’t) really going on.

For example, leaders could ask program management “what have you learned in your past three sprint cycles and what did you do about it?” If the management answers “What’s a sprint cycle?” that’s probably not a good sign.

The document also includes a kind of graphical flow chart for separating agile from agile BS. “Are teams delivering working software to real users every iteration (incl. the first) and gathering feedback?” one square in the chart asks? If yes — congratulations, you’ve got agile! If not, well, you could be dealing with some BS.

Agile vs. agile BS. (Screenshot)


The goal of the draft document, board member Richard Murray explained, is really to democratize a hype-laden word. “If you’re an acquisition professional or you’re a decision maker or you’re a program manager — how do you know whether someone’s using agile?” he said Wednesday. “They say they’re using agile, there are a bunch of words there I don’t recognize, maybe they’re really using agile and maybe not.”

“We hope that this will be useful as people who maybe aren’t familiar with that kind of say well what should I be asking to make sure that the people who are working on the software for me, whether those are contractors or people within the government or servicemen and women — are we really doing agile or not,” Murray added.

Latest Podcasts