The mix of program-scale Agile and technical baseline ownership drives cheaper, better, and faster deployment of software-intensive systems. Although these practices aren't new, the SEI has seen how their combination can have dramatic effects. The Air Force Distributed Common Ground System (AF DCGS)--the Air Force's primary weapon system for intelligence, surveillance, reconnaissance, planning, direction, collection, processing, exploitation, analysis, and dissemination--employs a global communications architecture that connects multiple intelligence platforms and sensors. The AF DCGS challenge is to bring new sensors and processing applications online quickly and efficiently. Other large government software-intensive systems face similar challenges. The SEI has found that Agile cultural transformation--along with strong technical baseline ownership--is critical for programs like DCGS to deliver new capability faster and with greater confidence. These strategies working together can help create incremental and iterative approaches to deliver more frequent and more manageable technical capability. In this blog, I present the SEI's experiences in helping large Department of Defense (DoD) programs, such as AF DCGS, use concepts like owning the technical baseline and Agile software development techniques to deliver new capability on a regular basis.

Owning the Technical Baseline

Controlling hardware and software that evolve over time requires program management and technologists to build and maintain a deep understanding of a system and its implementation from the outset. Given the rapidly evolving technology and environments faced by today's warfighter, the DoD has recently advocated that government programs "own the technical baseline" for important programs. As outlined in a recent Defense Acquisition University article, owning the technical baseline means that a "government program team, independent of the prime contractor, can make proper decisions to achieve successful acquisition outcomes." Examples cited in that article include "understanding system and sub-system designs and architectures, the ability to assess and mitigate a system's cyber vulnerabilities" and "establishment and maintenance of open interface standards with the ability of the government program office to make block upgrades to the system."

Key to understanding and controlling the architecture and design of the system are many technical methods discussed in previous SEI blog postings, including open systems architecture (OSA) concepts of technical reference frameworks, standards-based development, and architecture analysis, methods that help government programs maintain a technical understanding of the system being used.

Incremental, Iterative, or Agile

Although iterative and incremental approaches have been around since the early days of software development, Agile software development methods and concepts have been more visible in the commercial software development world for the last 15 years. As described in the 2011 SEI technical note, Agile Methods: Selected DoD Management and Acquisition Concerns, Agile software development methods comprise practices that compensate for each other. For example, as detailed in the technical note, practices like information radiators compensate for minimal documentation; pair programming compensates for no code reviews; and test-driven development compensates for minimal documented requirements. Chosen piecemeal, Agile practices can leave large gaps and introduce risks. Selecting an established method brings in a set of compensating practices and reduces risk. Interest in these methods within the DoD acquisition community has recently been increasing, as the remainder of this post will describe.

Large programs, such as AF DCGS are essential to the warfighter operating in today's global environment. They also require a near-constant stream of upgrades, updates with coordination of hardware, and network refreshes. New capabilities are always in demand by warfighters and their military support systems, all with different cadences of delivery. Agile software development principles and methods help create the processes to deliver multiple components into reliable systems on a frequent basis.

To make Agile approaches work with large government programs, our main focus has been to help acquisition staff understand what it means to acquire systems using Agile development principles. First, there is a need to train government personnel on basic Agile principles and methods. But, they quickly need to understand how their existing program's processes and culture need to change to enable the agility they are looking for. Commercial Agile software development training classes, conferences, and coaching are a good start, but government acquisitions processes don't enable easy adoption of common Agile methodologies. We have found that in large government programs like AF DCGS, starting small with just a few projects is a best practice. During this learning period, the team must be willing to change and adjust when the current processes are not working (i.e., inspect and adapt).

It is often hard for organizations to change approaches to software acquisition that have been entrenched in past acquisition methods. Our Agile-related work with large programs like AF DCGS usually focuses on several fronts

• Culture: For acquisition teams to apply Agile approaches, the decision-making culture needs to change and decision makers must accept that the system will be delivered in multiple upgrades.
• Policy: We have found that knowing Agile methods is not enough. We need to tie Agile methods to government policy in a way that encourages government programs to adapt to new ways of acquiring software-intensive systems. This process requires different education and training approaches, from formal classrooms to learn-on-the-go brown bag lunch events and then to in-execution coaching and mentoring.
• Governance Practices: Along with the decision to make culture changes, changes in governance practices--from how requirements are communicated to contractors to when and how requirements can be refined, and how system elements will be accepted and deployed--must be analyzed and adapted to enable the flow of incremental systems out to users.

Challenges and Successes

We have seen Agile help large government programs address concerns about incremental and iterative methods as it provides faster feedback. If a process is not working well, the program is made aware of the problem and can make a decision about how to change in a timeframe that can actually affect the outcome. We encourage programs to use iteration and increment retrospectives to enable improvements for the next iteration.

Another challenge we face is incorporating commercial Agile techniques into government settings. Learning how to scale at the same time as fitting into government acquisitions settings requires a major cultural shift. While there are multiple methods to scale Agile, we have found that aligning the program office's Agile adoption with the approaches in use by its contractors result in the selection of a popular methodology that brings the advantages of commercial training, access to learning and execution materials, and access to a large bench of coaches.

As mentioned above, the contractor is another factor that influences the decision of which approach to use. The acquisition strategy helps to determine whether the development contractor will be defining the agile processes. On the other side, when the government has the ability to really own and manage the technical baseline, then the execution strategy will be driven and managed by the government. In this case, finding contractors that have compatible Agile and developmental processes with the government acquisition strategy and technical approach is key for a successful project.

A deep understanding of system technology and operational usage is exactly what is needed to slice ACAT-I level programs into several releases of working software with a year. Owning the technical baseline helps achieve this kind of understanding, so that, DoD program managers can deliver new technologies with agility and adaptability. As the DAU article notes, "The underlying metric for such agility and adaptability is speed. When we can develop and field capabilities fast, we must do so. Furthermore, agility and adaptability can be enabled by designing systems with modularity, well-designed standards and open-system architectures and protocols." Use of Agile methods enables speed not by attempting delivering full capability in shorter timelines; rather, it delivers small chunks of capability sooner. Well-executed Agile processes rely on tempo and cadence but they need a system design that is flexible, modifiable and extensible to make incremental capability feasible.

More than development techniques are needed to succeed with Agile. To deliver frequent updates and new capability, the development test (DT) organization and operational test (OT) organization must adapt to the new acquisition cadence. Since the user, test community, and development teams are often deeply embedded in a cultural norm of manual testing, it can be challenging for them to learn and adapt their existing extensive and institutionalized test processes. Programs need to work out the way in which various levels of testing will be conducted so that opportunities to "shift-left" are identified early and consistently performed and take best advantage of Agile artifacts. How will testing be conducted by the developer at the contractor level? How will that testing migrate to an integration lab for frequent developmental and operational testing? Addressing these types of questions usually requires adding automation across all levels of testing to keep the pipeline of new capability flowing.

Wrapping Up and Looking Ahead

The SEI's work helping large programs like AF DCGS adopt Agile principles that are aware of systems acquisition realities aligns with the DoD's recent emphasis on Better Buying Power, owning the technical baseline, and open systems architecture initiatives. By placing greater emphasis on defining and controlling the architecture and design approaches, Agile helps programs make all kinds of decisions efficiently, thereby enabling working Agile teams to create value effectively on a daily basis. I believe that the combination of cultural shifts towards technical baseline ownership and use of Agile software development methodologies can help other agencies divide large software systems into smaller releases and, consequently, realize better acquisition outcomes.

Additional Resources

A story highlighting Harry's work helping the Air Force adapt to Agile methodology is available in the 2015 SEI Year in Review. Download a PDF of the publication, which highlights SEI work from our past fiscal year and showcases the support we provide to the DoD and other organizations in acquiring, developing, and deploying trustworthy, software-enabled capabilities.