The federal government continues to search for better ways to leverage the latest technology trends and increase efficiency of developing and acquiring new products or obtaining services under constrained budgets. DevOps is gaining more traction in many federal organizations, such as U.S. Citizenship and Immigration Services (USCIS), the Environmental Protection Agency (EPA), and the General Services Administration (GSA). These and other government agencies face challenges, however, when implementing DevOps with Agile methods and employing DevOps practices in every phase of the project lifecycle, including acquisition, development, testing, and deployment. A common mistake when implementing DevOps is trying to buy a finished product or an automated toolset, rather than considering its methods and the critical elements required for successful adoption within the organization. As described in previous posts on this blog, DevOps is an extension of Agile methods that requires all the knowledge and skills necessary to take a project from inception through sustainment and also contain project stakeholders within a dedicated team.

Successful implementation of DevOps in the federal government is possible thorough collaborative involvement of all stakeholders, the development of governance in regards to infrastructure, and equipping operational staff with DevOps skills. As the DevOps process gets used more and more in software development by industry firms, the common DevOps culture, automation, measurement, and sharing (CAMS) theme is used. In this post, we will begin to address some of the barriers and identify ways to enable the implementation of DevOps philosophy in the federal government space. So, where do we start?

First Step: Acquisition Process

The first and most important step of DevOps implementation starts in the acquisition process. The traditional government approach to any system acquisition is the waterfall model. Unfortunately, this model often starts with the development of rigid requirement specifications and sets the project on a path for failure on schedule, technical objectives, and overall project cost. In addition, acquiring the entire system at once can result in design, testing, and integration problems. In some cases, the expected product may be outdated by the time it reaches production use. In the waterfall model, there is no easy way to address requirements changes during the development or deployment stages unless the teams re-do previous tasks, which is expensive and time-consuming. Complex and software-intensive systems require a shift away from traditional waterfall models to more Agile methods. Agile methods are more effective for focusing development cycles, iterative delivery, and managing costs for actual business needs. Government organizations must remove any barriers during the acquisition process. Some barriers that prevent acquisition staff from operating more rapidly are

• rigid requirements and timelines
• delivery methods
• lack of formalized integration testing plan

On the other hand, following Agile methods can enable organizations to see smaller, but successful incremental results, and receive early feedback on delivered capabilities, which allows early problem resolution if there are any misinterpretations of tasks. Additional information on adopting Agile methods during the acquisition process is available in previous blog posts and ongoing work by SEI researchers to help acquisition professionals in the federal government.

While adapting Agile methods into the acquisition process, there are also requirements for cultural involvement, and preparation to support DevOps principles, such us continuous delivery, integration, automation, and measurement. During the contracting phase, all project team stakeholders should provide input on the contract, as well as functional requirements. As we mentioned earlier, the main principles of DevOps aim to bring the operational team together with developers, so effective communication is the cornerstone of this union. More specifically, communication between everybody is necessary: the program management team, operational team (including IT, maintenance, support, and operational testing), federal agency security experts, system architects, and legal staff among others. While it may take more upfront work to secure everyone's input early in the contractual process, mistakes can be found and addressed before fingers hit keys for development. The input the acquisition department must have includes, but is not limited to, the following:

• system framework
• security policy/technical implementation guidelines (access control, required OS, etc.)
• operational testing requirements and automation testing scripts/tools
• identification of development platform and needs
• iteration cycles and delivery methods
• module/system integration requirements and platform/tool definition
• communication methods and establishing visibility across all project teams

Also, automating the delivery of each capability and how the continuous integration with other systems will occur should be addressed during the acquisition process. Automation will enable the federal government to see status and capability as early as possible and allow stakeholders to gain a better understanding of the system regardless of functional state and pivot quickly should it require adjustment. After delivering a successful module, end-users will be able to begin working with new capabilities and become familiar with the system while the rest of the features are still being developed, tested, and deployed.

Future posts on DevOps in government will explore cultural changes, governance structure, and automation and measurement as part of this topic in our bi-weekly DevOps blog series.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits, please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.