Need Advice on Agile? The Pentagon Has You Covered.

The Department of Defense (DoD) wants to save you from poor Agile development practices.

“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 (‘agile-scrum-fall’),” reads the document issued by the department, helpfully titled: “DIB Guide: Detecting Agile BS” (PDF).

(For those who don’t work in the depths of the Pentagon, the DIB is the Defense Innovation Board, an organization set up to improve the DoD’s technological innovation. Advisors on the board include Eric Schmidt, the former CEO of Google, who knows a thing or two about managing software-development teams.)

The document breaks down core Agile values, which include:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

The DIB uses those values as a starting point for its own Agile-centric “maxims”:

  • “Competence trumps process.”
  • “Minimize time from program launch to deployment of simplest useful functionality.”
  • “Adopt a DevSecOps culture for software systems.”
  • “Software programs should start small, be iterative, and build on success ‒ or be terminated quickly.”

The document also provides some “key flags that a project is not really agile,” including a lack of feedback from users to the development team, and too much autonomy among stakeholders. A team that treats meeting requirements “as more important than getting something useful into the field as quickly as possible” should also fix its priorities as soon as possible.

The whole thing is well worth your time if you participate in software development; there’s a handy list of common tools used by idealized Agile teams (including GitHub, Docker, JIRA, and more) and an even handier set of questions for various team members (“How automated are your development, testing, security, and deployment pipelines?” is a key one to ask programming teams, for example.).

For those who want to run effective Agile meetings, keep some key tips in mind. Meetings should be fast-paced and succinct, even if that means getting rid of chairs; in addition, someone should take notes so that everyone can keep track of updates and decisions. Every meeting should have a clear purpose, with a bias toward detailing current progress and next steps.

And if you’re totally new to Agile as a concept, start with the Manifesto for Agile Software Development, then work on your skillset. You’ll quickly see why the methodology’s flexibility has made it a favorite among software-development teams—including those within the Pentagon.

2 Responses to “Need Advice on Agile? The Pentagon Has You Covered.”

  1. “A team that treats meeting requirements ‘as more important than getting something useful into the field as quickly as possible’ should also fix its priorities as soon as possible.” Huh? I think I understand what is intended here, but a potential better way of stressing this point is “A team should be able to slice scope based on delivering iteratively and incrementally. Slicing allows teams to solicit early feedback from real customers based on deliverables of value.” Requirements should always be met or directly raised when they cannot be met. The concern you seem to be addressing is decomposition / scoping.

    I also agree with Zebedee, Scrum and Agile are related, but not synonymous.