Agile Acquisition Strategy

Definition: Agile acquisition is the strategy, structure, and process to effectively adopt and apply agile software development methodologies. Agile acquisition integrates planning, design, development, and testing into an iterative life cycle to deliver small, frequent, incremental capabilities to an end user. Agile acquisition in government programs requires integrated government and contractor processes and partnerships. It embraces the agile development principles of self-organizing cross-functional teams, frequent capability deliveries, continuous user participation and feedback, and evolving requirements.

Keywords: acquisition strategy, agile, agile acquisition, agile development, incremental, uncertainty, rapid

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the fundamentals of agile acquisition, identify when it is appropriate to adopt an agile strategy, and understand how to successfully adopt and implement agile practices for a program. They should understand how systems engineering processes may change within an agile environment and how to tailor them to program constraints and objectives. SEs must understand that the challenges of dynamic development, requirements, and related processes require significant rigor, coordination, and integration.  


Agile development is built around a culture of small, dynamic, empowered teams actively collaborating with stakeholders throughout product development. Agile development requires team members to follow disciplined processes that require training, guidance, and culture change. The agile method does not follow a set of standard "waterfall"-based prescribed formal processes. Agile methods demand processes specifically tailored for a rapid, iterative, dynamic development approach, especially in the areas of requirements, test, and systems engineering.

Agile acquisition can be distilled into four core elements:

  1. Structuring the program via small, frequent capability releases
  2. Valuing working software over comprehensive documentation
  3. Being responsive to changes in operations, technology, and budgets
  4. Actively involving users throughout development to ensure high operational value

The foundational structure of an agile program, as depicted in Figure 1, is:

  • Release: Capability delivered to users, composed of multiple sprints
  • Sprint: Priority capabilities developed, integrated, tested, and demonstrated (aka iteration)
  • Daily scrum: Team synchronization meeting to plan activities and assess progress and impediments
Figure 1. Basic Agile Structure

Enabling an agile acquisition strategy demands some degree of upfront planning and design, but it places importance on beginning development quickly. The fundamental assumption is that requirements, designs, and capabilities will evolve as team members gain information during the development process [1].

When to Use Agile

In determining whether an agile acquisition strategy is appropriate for the program, it is critical to evaluate the operational, acquisition, and developer conditions. Agile acquisition strategies should be considered when:

  • The full set of requirements cannot be defined up front, but an initial set can be determined, at least for a first release.
  • Requirements can be decomposed into small tasks to support iterative development.
  • Users want smaller, more frequent, iterative deliveries.
  • Users are able to actively engage throughout development.
  • User feedback is used to shape the requirements for future releases.
  • Acquisition processes can be tailored to support smaller, frequent releases.
  • Leadership and stakeholders support an agile acquisition strategy and processes.
  • The government program office has agile trained or experienced individuals, tailored processes, and access to coaches, and developers have agile experience.
  • Users, program office staff, and developers can establish a collaborative environment and are able to collocate or establish an effective virtual working environment.
  • The program can leverage enterprise platforms, processes, and documents for contracting, development, and test to enable rapid execution.

Agile acquisition works best with smaller scoped developments, such as a self-contained application or incremental upgrade to an operational system. Agile can scale to apply to larger development efforts, but this requires additional rigor in technical architecture, coordination across development teams, and integration. It is difficult to develop a large infrastructure system from the start using agile development. The more agile development can leverage an established infrastructure platform, the more autonomy the team will have for their iterative development. A program can initially use a traditional approach to build an initial increment that meets the baseline architecture requirements. Once the program has established a baseline and framed the overall conceptual design, program managers can consider shifting to an agile approach for subsequent releases that build additional functionality into the operational baseline.

Best Practices and Lessons Learned

Setting up an agile environment. An agile acquisition strategy represents a change in the way the government traditionally conducts business. Programs must rethink how they are staffed, organized, and managed, and they must structure the business processes, governance reviews, and funding models to support agile methods. Agile requires dedicated government involvement throughout the entire process in order to plan and integrate multiple releases, oversee development cycles, manage evolving requirements, facilitate collaboration, and obtain committed, active, and consistent user engagement. The optimal structure to foster a collaborative environment features physical collocation of the acquisition support team, which consists of the program staff, contractor, and supporting functional areas. Constant communication across the team is essential. Most agile methodologies require daily meetings for status, direction, feedback, and assignments. A culture of trust that spans the decision authority, developers, testing organization, acquirers, program management, and users is critical to successful agile delivery.

Structuring an agile program. The way a program is structured into releases and sprints from the start can play a key role in its success over the life cycle. Government program managers in consultation with operators and developers must determine the optimal timelines for releases and sprints on the basis of various constraints, risks, and factors. The primary drivers include how frequently the operational community wants and can integrate new releases and the ability of the development environment to regularly build, integrate, test, quality assess, and deploy capabilities. Traditional acquisition, contracting, budget, test, and related processes constrain development, but the program should tailor these processes to support smaller, more frequent releases. Active stakeholder engagement and contributions can aid the program in designing the acquisition and development processes to fit the planned structure.

Requirements management. The agile methodology embraces requirements change throughout development. Because it is often difficult to define the full set of requirements for systems up front, they can be iteratively identified and shaped along the way. Given the rapid pace of changes in technologies and operational environments, requirements can evolve over time. Active user involvement is needed to inform the development process and provide feedback based on early releases. This gives users the opportunity to add, edit, and delete requirements with sufficient management controls. Requirements are managed via a prioritized product backlog that is typically in a database format, instead of a single document. A product owner from the user community traditionally controls the requirements backlog. The highest priority requirements that can be developed within the set timeframe define the scope of the next release. Release requirements can be changed during development. Sprint requirements are an agreed-to subset of a release between the users and developers and are locked, preventing changes for this short interim build. See Figure 2.

Figure 2. Program, Release, and Sprint Backlogs

Systems engineering. In an agile environment, systems engineering requires tailored methods and processes to incrementally deliver capabilities. SEs play a critical role in technical and programmatic integration via disciplined engineering processes. To enable faster, smaller deliveries, enterprise architectures are required to guide system design. Agile systems engineering practices, such as design reviews, are not one-time events for the entire system, but rather an iterative process with smaller, more frequent reviews built into each release. Given the rapid and dynamic nature of the agile environment, it is critical to keep all key stakeholders informed on a regular basis. Conducting a demonstration of capabilities at the end of each sprint and release is an opportunity to bring users, developers, and other stakeholders together to drive collaboration and decision making. It is important to put in place a clear architecture that is refined over time as sprints and releases are developed. The architecture should be government managed, with active collaboration with the contractors developing capabilities governed by it. SEs should periodically hold technical reviews for large elements of the system (broader than any release) to assess designs, performance, and alternatives. SEs should actively partner with testers to ensure active and early involvement in the process and to establish a common set of expectations for outcomes.

Architecture. The architecture of the system should have enough flexibility so that capabilities can be designed, added, or modified with functional independence. In other words, the system is architected and designed so that capabilities scheduled for delivery can interoperate with the components that have been delivered and do not have critical operational dependencies on capabilities that have not yet been delivered. Layered architectures lend themselves to this application. Components may be developed for different layers; concentrating on the most commonly used/reused components first. An initial capability for delivery could be a component that crosses layers and provides utility to the user ("user-facing").

Lessons Learned:

  • Apply agile acquisition practices where they work best: on smaller programs and ones that can be sub-divided into smaller elements. Attempting to develop very large systems via agile methods will be a challenge and requires a higher level of expertise to scale effectively.
  • Ensure that stakeholders in the operational and acquisition community agree on the size/frequency of releases and sprints (or related terms). Releasing capabilities to the users every 6–12 months and the developers demonstrating interim capabilities monthly is an approach used by many government agile programs today.
  • Arrange for close, physical proximity of the program, developers, and users to enable frequent communication that is characteristic of agile developments.
  • Use small, empowered cross-functional teams to enable program agility and meet aggressive program schedules.
  • Use a portfolio-based approach to allow programs to take advantage of efficiencies gained across several agile development efforts (e.g., portfolio-level agile development contract, portfolio-level testing and certification processes).
  • Establish team criteria to define when a user story is considered "done."
  • Use a Change Control Board for larger programs to manage product backlog grooming decisions.
  • Obtain agreement from the operational user community to provide users that can participate in the development, testing, and feedback process.
  • Hold user forums to enhance collaboration and ensure that all stakeholders understand and agree on the program's priorities and objectives.
  • Provide systems engineering information to all key stakeholders on a consistent, regularly scheduled basis, either through design reviews or program reviews.
  • Use the release planning and sprint demonstrations as opportunities to bring users, developers, and stakeholders together in face-to-face sessions to drive collaboration and strengthen teaming arrangements.
  • Ensure that once a clear architecture is in place, SEs continue to refine it as they learn more from the development sprints and releases.
  • Independent of releases, hold periodic technical reviews for larger epics, strategic planning, grooming the program backlog, managing resources, and shaping the program's direction.
  • Capture systems engineering processes and related content in portfolio-level systems engineering plans for broad use. Individual releases can capture the scope details in small appendices approved at a low level.
  • Per the recommendation of experts in agile methods, use common (ideally open sourced) platforms, standards, interfaces, and application program interfaces (APIs) over costly point-to-point interfaces.
  • Institute rapid prototyping that allows developers and government organizations to quickly demonstrate potential solutions that meet urgent requirements, mature and integrate technologies for the particular solution space, and highlight advantages over alternative options.
  • Establish an environment that includes processes and properly configured test platforms to rapidly prototype capabilities that extend beyond the next increment or project. This opens up opportunities for innovative and dynamic solutions.
  • Use automated tools to enable continuous integration, reduce delays in integration and testing, and provide configuration management functionality.

References and Resources

  1. Modigliani, P., and S. Chang, March 2014, Defense Agile Acquisition Guide: Tailoring DoD IT Acquisition Program Structures and Processes to Rapidly Deliver Capabilities, The MITRE Corporation, accessed October 25, 2017.

Additional References and Resources

Balter, B., 2011, Towards a More Agile Gov't: The Case for Rebooting Federal IT Procurement, Public Contract Law Journal, Vol. 41, No. 1, accessed October 25, 2017.

Government Accountability Office, July 27, 2012, Effective Practices and Federal Challenges in Applying Agile Methods, GAO Report 12-681, accessed October 25, 2017.

Lapham, M. A., S. Garcia-Miller, L. Adams, N. Brown, B. Hackemack, C. Hammons, L. Levine, and A. Schenker, October 2011, Agile Methods: Selected DoD Management and Acquisition Concerns. Software Engineering Institute, accessed October 25, 2017.

Lapham, M. A., R. Williams, C.  Hammons, D. Burton, and A. Schenker, April 2010, Considerations for Using Agile in DoD Acquisitions, Software Engineering Institute, accessed October 25, 2017.

Manifesto for Agile Software Development (i.e., The Agile Manifesto), accessed October 25, 2017, accessed October 25, 2017.

Northern, C. et al., December 15, 2010, Handbook for Implementing Agile in Department of Defense Information Technology Acquisition, MITRE Technical Report MTR 100489, accessed October 25, 2017.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team