Agile in DoD acquisitions

Nowadays everybody is talking about “Agile Methodologies” (AM) as a way to improve software project under many points of view. Even if AM can be reduced in something like “less bureaucracy and more working software” I don’t agree completely on that over-simplification.

Reading the CMU-SEI paper “Considerations for using Agile in DoD Acquisition” we can see how big programs - consisting generally by a different pieces of systems, developed over time by different (sub)contractors, and then integrated together - can or cannot fit well with AM.

First, I’d like to cite a quote from the above mentioned document that I agree completely on:

"Agile is not a silver bullet but rather another "lead bullet" for
 the Program Management Office's an contractor's arsenal"

AM are not considered a one-size-fits-all thing but a useful tools like everything else.

In the papers two main benefits are early evidenced:

• frequency of usable releases favors AM because users get more value soon and so feedback too can come soon
• executable and testable products are released soon and so internal integration testing can come soon, evidencing potential issues

Leaving all details contained in the paper (based on a wide set of interviews) I’d like to notice what matters more in my opinion: DoD programs are really wide, large, and long - and despite that:

"...a review of DoD 5000 series showed there are minimal barriers and
 non of the challenges are show stoppers"

(DoD 5000 relates to military acquistion)

Finally, a nice thing at the end of the paper: the ”FIST Manifesto” (more detailed info here).

I find FIST a nice summa on Agile principles applied in a general form on a software acquisition.