The DoD can move faster. Here's how.

The agile framework and DevSecOps are two of the most commonly referenced software development methodologies, so it’s no surprise that these development practices have caught on like wildfire in software development across a variety of industries. Although many organizations claim that they are agile or practice DevSecOps, oftentimes these processes are misimplemented in organizations. The government is no different.

“Agile is a buzzword of software development, and so all DoD software development projects are, almost by default, now declared to be “agile.” -DoD, Detecting Agile B.S.

In late 2018, the DoD released a document entitled Detecting Agile B.S. The document details how ‘agile’ has become a buzzword in software development programs across the DoD and provides guidance to determine whether projects are really using agile development practices. This took the defense industry by storm, and this document became a cornerstone for reference in the digital transformation space.

Emerging from the endless cycles of waterfall development practices, the turnaround time of requirement working packages, and delivery times that span three to ten years, with the adoption of agile and DevSecOps, everything seemed like it was finally heading in the right direction.

Then, in 2020, the Government Accountability Office released its annual survey and we discovered a different truth.

Of the 42 weapons systems programs that were surveyed, 22 claimed to be using agile development methods, 16 reported delivery times longer than typical in the commercial industry, and 7 reported delivery times longer than 7 months.

How can we ensure that we are truly developing in an agile way with DevSecOps at the helm to deliver impactful software that our users love?

We should be delivering working software to real users every iteration. Benefits to delivering working software to users frequently:

1. We close the loop in the software development process.
2. Can solicit feedback from our users quickly.
3. Are empowered to improve the product iteratively.
4. Can change requirements based on changing needs instead of waiting around for a new requirements working package that may take years to develop.
5. Reduce risk by getting features and bug fixes into production in a quick and sustainable way.

Because software and technology changes so rapidly, there is a risk associated with operating on outdated software. By continuously delivering, we can make this a thing of the past and reduce risk by delivering the latest and most secure software to our users in real time.

Two practices that can help you continuously deliver:

TDD/CDD

Test-Driven Development (TDD) and Compliance-Driven Development (CDD) are two techniques used in software development that can help in delivering software. TDD is a technique that starts with writing tests that guide developers to the implementation of functional code. This leads to an entire baseline that is tested from the get-go.

By developing in this manner, we reduce risk and any unnecessary code that may pollute our baseline. By adding in security tools and test procedures on top of that, we drive out security compliant applications that are ready to be pushed from inception (CDD).

CI/CD Pipelines

Continuous Integration (CI) and Continuous Delivery (CD) are software development practices that enable developers to merge code changes to a branch and automate the software release process.

By implementing CI/CD pipelines, we leverage automation to execute full test suites of applications, scan baselines for any security vulnerabilities, and deploy software to staging /production environments with the push of a button or commit. Part of continuous delivery includes making sure that our application is tested, secure, and actually works. Setting up CI/CD pipelines and provisioning our environments appropriately ensures that our applications fulfill all these criteria.

We can develop even more secure tools that control our release process by scanning results from a CI/CD pipeline prior to releasing. This is precisely what my fellow Risers Jeff Wills and David Lamberson did at Kessel Run with the development of the Release and Deployment Dashboard (RADD).

By continuously delivering software that our operators love, we can take one step closer to truly being agile, adopting DevSecOps, cut down development time tenfold, and achieve continuous RMF.