Agile is DOD’s only path to innovation

The Pentagon's mission to ensure the military can protect the security of the nation was described in the 2018 National Defense Strategy: “A more lethal, resilient, and rapidly innovating Joint Force, combined with a robust constellation of allies and partners, will sustain American influence and ensure favorable balances of power that safeguard the free and national order." 

Unfortunately, resiliency and the ability to innovate remain works in progress.

The challenge is that government's work on massive, complex IT projects requires numerous teams and detailed coordination, making it tough to abruptly shift these projects as needs change. Thus, some agencies may still prefer the same traditional waterfall development practices they’ve used in the past.

Meanwhile, other countries are taking iterative, natural and agile approaches to large-scale projects. For example, China accelerated the delivery of its J-20 stealth fighter from prototype to deployment in just a few years compared to up to the usual decade.

To compete with other world powers, the U.S. government must adopt agile methods paired with a DevOps culture.

The agile philosophy 

Agile emphasizes the ability to react and make adjustments quickly while maintaining a constant pace of development. With agile, innovation becomes an ongoing, sustainable and ultimately rewarding process.

Initiating an agile transformation is no small feat, however. Although the 12 principles of agile development are clearly laid out in the Agile Manifesto, adopting all of them, full stop, may seem daunting to the uninitiated.

As with all transformations, it’s best to begin incrementally. The principles offer good starting points, such as delivering working software frequently (No. 3), building sustainable development models (No. 8) and continuous attention to technical excellence (No. 9). 

But the second principle provides a key insight: the need to understand, welcome and react to change quickly. This should be done while keeping the focus on delivering quality, working software -- without teams killing themselves in the process.

However, it’s important to remember that agile, like DevOps, cannot be purchased. It must be taught -- by seasoned practitioners -- to be adopted by organizations effectively. And people must be willing to learn and adjust to the new process, which can be daunting for tenured agency IT personnel.

Agile can also be somewhat unpredictable. The federal government likes to know exactly what to expect before embarking on a project: how much it will cost, what it will take to produce, when it will be produced. Waterfall development made these estimates a bit easier, whereas agile is about fluidity.

But that fluidity makes agile ideal for big and bold projects routinely being developed at DOD. Agile involves incremental successes as teams work together and break down projects into manageable sprints. These teams set frequent checkpoints and receive and provide constant feedback, including whether or not capabilities are still valid. The result: projects delivered faster, as expected, and with few surprises upon completion.

Making the initial jump to agile can be understandably filled with trepidation, but the payoff can be significant. Agile defense agencies can develop more resilient applications and build cultures centered around innovation and continuous deployment. 

Coupling agile with DevOps 

A DevOps culture extends and complements agile development practices, and many defense agencies are employing the concepts. Some are taking things even further by implementing DevSecOps, which brings security requirements front and center -- an obvious priority for DOD.

Both DevOps and DevSecOps pose the same challenge in that they can be just as tricky to adopt as agile. That’s because there’s no standard way of adopting a DevOps culture. It can, and should, be implemented differently based on agencies’ unique needs.

Still, DevOps is essential for agility and innovation. The first principle of the Agile Manifesto refers to “customer satisfaction through early and continuous software delivery,” and DevOps heartily supports that statement. DevOps is based on continuous integration and continuous deployment. As such, it can provide DOD with a virtual conveyor belt of software development and innovation.

Much like agile, however, DevOps involves adopting processes that might be somewhat foreign to agencies. Beyond changing the ways that developers and operations professionals work together, DevOps necessitates a change in the type of solutions that teams create and deploy. Instead of working on monolithic applications, they can build software with microservices, which enable them to focus on smaller pieces of software that can be delivered more quickly.

However, there are certain misconceptions that have arisen around DevOps practices over the years that must be dispelled so agencies do not overestimate or misunderstand DevOps. 

First, Linux containers do not bring development and operations teams together. Instead, they clearly delineate the roles of these two groups and enable developers to deliver applications quickly on an infrastructure that is optimized for stability.

Second, application platforms aren’t enough. While they can abstract the complexities of containers and orchestration platforms like Kubernetes away from development and operations teams -- enabling them to focus on what they do best -- they do not modernize application development processes. For that, agencies need both DevOps and agile methodologies. 

Indeed, DevOps and agile are interdependent. One cannot successfully exist without the other. And both are critically important if DOD intends to meet its goals for innovation. 

The shift to a DevOps model can seem overwhelming, but the important thing to remember is it’s an evolution -something that creates, rather than destroys, and does so continuously. Evolution is progressive and embracing it can help the U.S. solidify and maintain its preeminent defensive posture in the eyes of the world, today and tomorrow.