Agile software development has revolutionized the way private sector organizations build software. The primary tenets are that all companies are software companies, software is never done, and requirements always change. What does that mean for the federal space?
For those who are unfamiliar with US federal government purchasing, FARs are federal acquisition regulations that are designed to make procurement of goods and services fair. The idea is that the best plumber will submit the best proposal, and FARs exist to make sure that plumber wins the work. The implementation of FARs is done by requiring certain clauses be included when issuing an RFP (request for proposal) and end up in the resulting contract. Further items are set out in the DFARs which are related to procurement in the defense sector.
Software procurement, for products that already exist, can make good use of FARs. The existing rules in the contract can allow small businesses or protected classes to benefit from what might have just been another line item to one of the big federal contractors.
Software development procurement, for buying the expertise to design and create custom software, has many fundamental issues, which are made systemic through the existing FAR clauses.
How Agile changed the SDLC
Back in the 20th century, the government procured software to run systems that were deployed to space or on boats or aircraft. Agility doesn’t have much of a place in that sort of atmosphere, and hadn’t been invented yet, so as the federal acquisitions process evolved, it did so with this very rigorous software design and development in mind. Thank Reagan for making this a procurement process at all… but that’s a side topic.
In the 21st century, most software development organizations realized that the software they expected to build and deploy and operate actually turned into software that they build and deploy and build more and deploy more and build more and deploy more. It turns out things change, users change, laws change, and products change. Any software that interacts with any of those things will need to also change, or be replaced.
The private sector solved this problem by using open source software as building blocks to prototype new features insanely quickly, get them validated by users as “the right thing to build” and then solidifying and debugging that prototype. The fact that the requirements gathering process is roughly a hundred times longer and more resource intensive than making a prototype lead folks to the agile methodologies. You can make the software dozens of times and still have it deployed and users benefitting before the requirements phase of a waterfall project is over. The software is better, the users are happier faster, and then continuing that approach to enhance the software is the obvious path forward. This works great as long as you have employees building everything, requirements are notional and refined through iteration, and security/compliance rules are flexible and reasonable.
Under the software procurement process, they do not have employees, the requirements are contractually enforced, and security/compliance are a 6-month delay for Authorization to Operate.
What would Agile Federal Procurement look like?
If I were in a position to fix the FARs, these would be the new procurement guidelines.
- Any software procurement needs to justify why they wouldn’t hire and grow the expertise as government employees
- Software development must be done on the government supplied SDLC management system for visibility (of course, as a GitLab guy, I see how GitLab can enable this)
- IV&V should be automated and included in the SDLC management system
- Application security feedback in an informational capacity should be supplied to the software team in the SDLC management system
- Security compliance feedback should be an aspect of the release process, after the code is deployed to a staging and validation environment.
- IV&V needs to keep up with software development and if they fall behind, they are replaced.
- The contract would focus on user satisfaction rather than “system shall” requirements since the system shall do whatever the users expect
- Changes to the software, requirements, and governance should all be suggested in the SDLC management system as issues and approved or adapted by CO (contracting officer) or COR (contracting officer representative) or COTR (contracting officer technical representatives) quickly, as part of a collaborative environment
These rules would create an environment where velocity and quality are rewarded. IV&V is not allowed to be an interminable roadblock. CO, COR, and/or COTR are not allowed to disappear or abdicate their responsibility in helping refine the product. This should create alignment of interests so the procurement shop acts as product owners for the software being designed and built.
If the procurement team cannot support this, then they should not be procuring software. Even in the old way, they wouldn’t have had the right requirements or be capable of evaluating the resulting software.
How to take steps in this direction?
The DOD is taking steps in this direction through their Enterprise DevSecOps Reference and the DOE is trying to incentivize requirements changes to be addressed early in their Exascale Computing Project rather than building the wrong thing. These are good steps.
Government organizations can create procurement groups in GitLab to include creating of the RFP, a ratified contract, and requirements as high level Epics. Then subgroups for the software development and IV&V activities which include the breakdown of user stories into issues and execution of development in merge requests. The permissions model can be used to let the contractors run their projects as needed while tying issues and tasks back to Epics that are under the producrement team’s control.
Procurement officers and representatives can use this structure to oversee changing requirements that come from users and development lessons learned. Changes with schedule and budget impacts will can go through reviews and approvals. Significant changes can be coordinated with security and operations folks during the conceptualization phase rather than surprising them at deployment time.
All work is visible and poor performance can be rooted out quickly and effectively. No need for waterfall design review gates since they’ll happen continuously (or as needed).
Finally, the breakdown of requirements can lead directly to architectural decisions that benefit the larger organization, by reusing dependencies and pipeline jobs that tie into enterprise systems or deploy to the same infrastructure.