How the DoD Does Agile Contracts
My first software job was writing satellite ground station software for Department of Defense contractor in the mid-1990s. It was the dark depths of waterfall. Fortunately, the DoD is catching up with the modern era of software development by using Agile methods and implementing Agile contracts.
I just listened to a fascinating webinar by Air Force Chief Software Officer (CSO), Mr. Nicolas M. Chaillan, about their DevSecOps initiative and the mega-scale microservices architecture that is enabling agile development in the Air Force. (Go here for a recording of the webinar.) Mr. Chaillan described the high-level approach to DoD agile contracting as hiring a certain capacity of skill sets, not a specific scope of work. They specify a Definition of Done - quality standards that contractors must meet, such as using the DevSecOps architecture and deployment pipeline, every Sprint.
The DoD has provided extensive guidance on writing agile contracts in the Contracting Considerations for Agile Solutions. The document describes how to write an RFP without a complete set of requirements by ‘identifying a product vision and coupling it with an explanation of how the Agile process will be used to achieve the product vision. Rather than provide a set of “how to” specifications (or a Requirements Traceability Matrix), the product vision focuses on a desired outcome; this is similar to performance-based contracting, which the FAR has permitted for many years.’
The DoD uses a variety of different contract structures and pricing models depending on the situation: fixed price, time & materials, cost reimbursement, and hybrid models. The Contracting Considerations document provides guidance for each one. It even provides recommendations on specific language to include in the contract, for example:
“The contractor will work in a team-based Agile environment. The Product Owner will specify high-level requirements/capabilities to the Agile team. As in typical Scrum-based Agile processes, the Agency Product Owner will work together with the team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria will specify expected functionality for a user story, as well as any non-functional requirements that must be met in the development of the story. The Agency Product Owner, supported by subject matter experts and business analysts, will determine whether or not acceptance criteria have been satisfied.”
Regarding ‘scaling’ approaches, CSO Chaillan writes this in a memo to his Program officers: Programs are highly discouraged from using rigid, prescriptive frameworks such as the Scaled Agile Framework (SAFe). But that’s a topic for a different post.
If you like to geek out on software, check out how the Air Force has designed a secure microservices architecture or browse their other public documents on DevSecOps and Agile.
Image from Diana Robinson by Creative Commons license.