DIB Calls BS On Buzzwords: Defense Innovation Board « Breaking Defense

WASHINGTON: A Pentagon advisory board of luminaries including Google ex-chairman Eric Schmidt and rockstar astrophysicist Neil deGrasse Tyson just unleashed a strikingly snarky swipe at the bureaucracy. Bluntly entitled “DIB Guide: Detecting Agile BS,” the five-page pamphlet suggests some pointed questions that policymakers can ask Pentagon managers who claim to have reformed.

Certainly it’s long past time someone took a buzzsaw to the buzzwords. The Defense Department is notoriously prone to jargon and cant, for multiple reasons: to communicate in time-saving code to fellow insiders, to obfuscate what’s actually happening to outsiders, and to proclaim compliance with superiors. Defense Secretary Jim Mattis‘s mantra, for example, is increasing “lethality,” a term his subordinates have slapped on all sorts of things. For his predecessor Ashton Carter, who created the Defense Innovation Advisory Board (confusingly acronymed as DIB, not DIAB), the Sesame Street words of the day were “innovation” and “offset.” For Donald Rumsfeld, it was “transformation.”

The specific topic in this case is software development, something Schmidt & co. know a lot about but which the federal government consistently screws up. The endless debate over the F-35 Joint Strike Fighter, for example, is as much about its millions of lines of code as its physical aerodynamics. It’s a highly technical topic with a frankly depressing history, but the DIB manages to address it in plain English with both clarity and snark.

“Agile is a buzzword of software development, and so all DoD software development projects are, almost by default, now declared to be ‘agile,’” the board begins. “Key flags that a project is not really agile: Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code….. The Program Executive Office (PEO) does not count as an actual user, nor does the commanding officer, unless she uses the code.” In other words, don’t let the boss tell you “sure, it’s fine” — ask the actual people who have to work with the software every day.

The document continues with a quiver-full of such barbs. Some even include suggested answers not to give, answers that, if you hear them, indicate something is going wrong. The section headed “Questions For Program Management” includes “How many programmers are part of the organizations that owns the budget and milestones for the program? Wrong answers: ‘we don’t know,’ ‘zero,’ ‘it depends on how you define a programmer.’” In other words: The people who run software programs ought to know how software runs.

“Questions to Ask Programming Teams” begins with “How do you test your code?… Wrong answers: ‘we have a testing organization’, ‘OT&E is responsible for testing.’” To generalize this principle: If the answer to your question is “oh, somebody else does that,” the program’s probably in trouble.

Besides digging out ineptitude with a sharp spade, the DIB guide also offers constructive suggestions, even including 16 specific software programs to use for specific purposes, from version control to bug reports. It’s a minor miracle that the board’s lawyers let it make these recommendations without an elaborate market survey process beforehand.

Brief as it is, the five-page guide could have an outsize impact on Pentagon software programs, especially if key members of Congress use its questions and checklists in oversight hearings. Now the Defense Innovation Advisory Board just has to put together guides for every other kind of program in the vast and intermittently functional acquisition system.

You can read the guide below or on the official website:

Dib Detecting Agile Bs 2018… by on Scribd