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.