Agile Acquisition Strategy


Definition: Agile acquisition is a strategy for providing multiple, rapid deliveries of incremental capabilities to the user for operational use and evaluation. The incremental deliveries, sometimes called spirals, spins, or sprints can be a few weeks or months to develop, and are built with continuous user participation and feedback. Note that this strategy assumes a predominately software-based development. (Agile acquisition should not to be confused with agile development, which "refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams."[1])

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

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to understand the conditions under which an agile acquisition strategy will minimize program risk and provide useful capability to customers compared to other strategies. They are expected to recommend agile acquisition for the appropriate situation, and develop and recommend technical requirements, strategies, and processes that facilitate its implementation. MITRE systems engineers are expected to monitor and evaluate program agile acquisition efforts and recommend changes when warranted.

Background

MITRE systems engineers often are involved in the planning stages of a new program or major modifications to existing programs. As members of the planning team, they must be well acquainted with various acquisition strategies and factors that should be considered when choosing a strategy.

The two fundamental reasons for moving toward "agile" processes are:

  • To respond quickly to an immediate and pressing need.
  • To engage with users throughout the development process and ensure that what is developed meets their needs.

Regardless of whether the final system requirements are clear, Agile Acquisition Strategy is focused on getting capabilities to the user quickly rather than waiting for the final system [2].

Agile acquisition is generally appropriate for two types of system development: 1) enterprise systems with a high degree of functional requirements uncertainty, even if the purpose and intent of the system is known; and 2) small, tactical systems that may have a short life, but an immediate and pressing need. These are cases where the fielding of blocks of an entire system is not feasible because total system requirements cannot be defined at the beginning, but immediate user needs can be partially satisfied with rapidly deployed incremental capabilities. The keys to success of this strategy are close alignment with stakeholders on expectations, and agreement with a limited set of users for providing continuous, rapid user feedback in response to each capability increment.

Advantages of this strategy demonstrate that: 1) development can begin immediately, without the time and expense needed for development, refinement, and approval of functional requirements; and 2) significant user involvement during development guarantees that the capabilities delivered will meet the user's needs and will be used effectively.

Disadvantages are that agile methodologies: 1) usually require stable infrastructure; 2) require significant management and technical oversight to ensure compatibility of ensuing releases; and 3) usually sacrifice documentation and logistics concerns in favor of rapid releases for fielding.

Best Practices and Lessons Learned

When to Use Agile: The use of agile methods should not be considered for all development efforts. MITRE SEs need to determine if agile methodology is appropriate for the program. It is critical to create evaluation criteria and processes by which any proposed effort can be vetted, to determine if the agile approach is warranted. The minimum criteria are:

  • Need for quick initial capability
  • High degree of uncertainty in final set of functional requirements
  • Fluctuation and complexity due to frequent changes in enterprise business model, data, interfaces, or technology
  • Initial architecture or infrastructure that allows for small incremental developments (60-90 day cycles)
  • Close cooperation and collaboration with users; identified set of users for continuous interaction with development team.

When a Contractor Bids Agile Development Methodology: If an agile development methodology is proposed by a bidding contractor, determine if the proposed effort is appropriate and has adequate resources in both the Contractor and Program Office organizations. For smaller programs, eXtreme Programming techniques may work; for larger efforts requiring scalability, another methodology such as Scrum may work better. In addition, the developing contractor's (and subcontractor's) organization needs to be set up and resourced with the relevant development tools, collaborative processes, and experienced personnel for whichever methodology is to be applied. Government oversight and management of a program using agile methods require staff who are experienced in the methodology and its highly interactive, collaborative management style. In-plant participation by MITRE engineers on a continuous basis should be strongly considered.

Architecture Implications: There are differing opinions on the level of effort required to define the overall architecture of an agile activity [2]. Some of this difference is due to the particular development methodology applied. In general, the larger and more complex the system, the greater the effort placed on architecture up front.

Rather than detailing an architecture before development, consider using the first few spirals/sprints to evolve the architecture as more about the system becomes known. This allows the architecture to evolve, based on the needs of the developing system.

The architecture of the system should be designed with enough flexibility so that capabilities can be designed, added, or modified with functional independence. That is, 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:

  • For larger projects, recognize the need to define business (organization, people, and process) and technical architectures.
  • Be aware of agile developers that do not have the skills for designing the architecture, and bring in systems engineers and architects to help.
  • Architecturally partition the system into layers and components for clean interfaces and cleanly divided work among teams.
    • Agile iterations need separable design pieces.
  • Identify non-functional requirements to build a scalable infrastructure. Large projects will have multiple iterations being worked in parallel. Parallel implementations imply:
    • Discrete implementation units
    • Dependencies between implementation units must be recognized and considered.
  • Features delivered for fielding must aggregate into a workable baseline.
    • Dependencies between Configuration Items must be recognized and planned to achieve stable upgrades [3,4,5].
  • The first few months of an agile development is the most critical time for involvement by MITRE systems engineers:
    • Lots of collaboration—requires senior people with right skills to provide guidance to developers on priorities and requirements ("stories" or "threads") and to involve the users
    • Skills and levels of expertise may change as different applications and components are being developed. Revisit, as needed.

Infrastructure Implications: When agile methodologies are used for developing software systems, a stable infrastructure must be available to the development team and users. A traditionally developed infrastructure provides a stable interface for developers, and allows the agile development team freedom to focus on their section of functionality and respond quickly to changing requirements. If the infrastructure changes often, developers waste time reworking their code to adapt to the new architecture without adding new functionality. Examples include stable operating system interfaces for agile desktop application development and a stable Java Web container architecture for "plug and play" filter implementations [2].

Teaming Is Key: The need for constant collaboration between the users and the developers, and among the Program Office, developing organization, and stakeholders cannot be understated. Agile methods do not work without this. It is essential that the Program Manager secure user agreement to provide evaluation feedback. It is also necessary that stakeholders are educated on the strategy and benefits of agile methods, since agile strategies can be new to government procurement organizations.

Constant communication across the team is essential. Most agile methodologies require daily meetings for status, direction, feedback, and assignments. Meetings are at different levels of the organization—from program management to user feedback sessions. Meetings need to be forums for open communication; problems and limitations need to be identified and addressed openly. Transparency is necessary in planning and development decisions. Keep user evaluation and feedback sessions small, thereby allowing for focused and open communication.

"Quality Is Job One:" Because agile methodologies are about flexibility and change, there can be a fear that quality will suffer in the race to deliver. However, there is an inherent quality driver in agile development if conducted properly. The operational user, who should be constantly evaluating and providing feedback on the product, is an important bellwether of quality. Adherence to development standards, defining segregable capabilities that enable successfully delivered functional increments, constant iterative testing, and constant user feedback all bring quality forward as a critical measurement for agile success.

"Agile" does not mean less disciplined. The various agile development methodologies are quite disciplined. The development teams need to work in parallel within the same development environment without interfering with each other. This requires a disciplined process enforced with constant open communication, good configuration management practices, and quality code to ensure interoperability of the deliveries on the developing baseline. Critical to success is experience of the development team with the agile process and methods. Ensure there are processes in place to enable the communications and tools to support collaboration and parallel development and testing. Quality measurements should be captured and monitored, to include testing successes/failures, defect rates, user comments, and feedback (negative/positive).

References & Resources

  1. Wikipedia contributors, "Agile Software Development," January 13, 2010.
  2. Dobbins, J. H., S. Luke, A. Epps, R. Case, J. Wheeler, September 1, 2007, "Agile Acquisition Strategies for NSA Programs."
  3. Doughty, J., September 4, 2007, "Introduction to Agile Development."
  4. Hagan, P., September 4, 2007, "Agile Methods Overview and Implications for Architecture."
  5. Morgan, N., September 4, 2007, "Sponsor Perspective."

Additional References & Resources

"Agile Acquisition," MITRE Project Leadership Handbook, accessed January 15, 2010.

Coldewey, J., January 19, 2009, "The 31 Square-Foot Architecture," Cutter Consortium.

MITRE Agile Resources, accessed January 13, 2010.

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team