Adopt Agile Practices

Agile is a set of software development principles that emerged in 2001 after 17 industry leaders created the Agile Manifesto to design and share better ways to develop software. Agile is the leading software development methodology in the commercial world with growing adoption across the government. Congress in the FY18 NDAA directed DoD to conduct a series of Agile pilots and expand on its Agile Acquisition curriculum at DAU. 

Four primary characteristics should guide Agile adoption in Government:

  1. Structuring programs and processes around small, frequent capability releases
  2. Valuing working software over comprehensive documentation
  3. Responding to changes in operations, technology, and budgets during development
  4. Active user involvement throughout development to ensure high operational value

The foundation of Agile is 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 openness to change. While Agile does impose rigor, the method does not consist of simply following a set of prescribed processes, but instead allows dynamic, tailored, and rapidly evolving approaches that suit each organization’s IT environment. 

MITRE has published a wealth of information on applying Agile practices to acquisition programs on its Acquisition in the Digital Age (AiDA) website. It includes guidance by functional area and a proactively tailored acquisition model to advise on adopting Agile within each phase of the acquisition lifecycle. 

FY18 NDAA Section 873 Pilot Program to Use Agile

SEC. 873. PILOT PROGRAM TO USE AGILE OR ITERATIVE DEVELOPMENT METHODS TO TAILOR MAJOR SOFTWARE-INTENSIVE WARFIGHTING SYSTEMS AND DEFENSE BUSINESS SYSTEMS.

(a) Pilot Program.—

(1) IN GENERAL.—Not later than 30 days after the date of the enactment of this Act, the Secretary of Defense, in consultation with the Secretaries of the military departments and the chiefs of the armed forces, shall establish a pilot program to tailor and simplify software development requirements and methods for major software-intensive warfighting systems and defense business systems.

(2) IMPLEMENTATION PLAN FOR PILOT PROGRAM.—Not later than 120 days after the date of the enactment of this Act, the Secretary of Defense, in consultation with the Secretaries of the military departments and the chiefs of the armed forces, shall develop a plan for implementing the pilot program required under this subsection, including guidance for implementing the program and for selecting systems for participation in the program.

(3) SELECTION OF SYSTEMS FOR PILOT PROGRAM.—

(A) The implementation plan shall require that systems be selected as follows:

(i) For major software-intensive warfighting systems, one system per armed force and one defense-wide system, including at least one major defense acquisition program or major automated information system.

(ii) For defense business systems, not fewer than two systems and not greater than eight systems.

(B) In selecting systems for participation, the Secretary shall prioritize systems as follows:

(i) For major software-intensive warfighting systems, systems that—

(I) have identified software development as a high risk;

(II) have experienced cost growth and schedule delay; and

(III) did not deliver any operational capability within the prior calendar year.

(ii) For defense business systems, systems that—

(I) have experienced cost growth and schedule delay;

(II) did not deliver any operational capability within the prior calendar year; and

(III) are underperforming other systems within a defense business system portfolio with similar user requirements.

(b) Realignment Plans.—

(1) IN GENERAL.—Not later than 60 days after selecting a system for the pilot program under subsection (a)(3), the Secretary shall develop a plan for realigning the system by breaking down the system into smaller increments using agile or iterative development methods. The realignment plan shall include a revised cost estimate that is lower than the cost estimate for the system that was current as of the date of the enactment of this Act.

(2) REALIGNMENT EXECUTION.—Each increment for a realigned system shall—

(A) be designed to deliver a meaningfully useful capability within the first 180 days following realignment;

(B) be designed to deliver subsequent meaningfully useful capabilities in time periods of less than 180 days;

(C) incorporate multidisciplinary teams focused on software production that prioritize user needs and control of total cost of ownership;

(D) be staffed with highly qualified technically trained staff and personnel with management and business process expertise in leadership positions to support requirements modification, acquisition strategy, and program decisionmaking;

(E) ensure that the acquisition strategy for the realigned system is broad enough to allow for proposals of a service, system, modified business practice, configuration of personnel, or combination thereof for implementing the strategy;

(F) include periodic engagement with the user community, as well as representation by the user community in program management and software production activity;

(G) ensure that the acquisition strategy for the realigned system favors outcomes-based requirements definition and capability as a service, including the establishment of technical evaluation criteria as outcomes to be used to negotiate service-level agreements with vendors; and

(H) consider options for termination of the relationship with any vendor unable or unwilling to offer terms that meet the requirements of this section.

(c) Removal Of Systems.—The Secretary may remove a system selected for the pilot program under subsection (a)(3) only after the Secretary submits to the Committees on Armed Services of the Senate and House of Representatives a written determination that indicates that the selected system has been unsuccessful in reducing cost or schedule growth, or is not meeting the overall needs of the pilot program.

(d) Education And Training In Agile Or Iterative Development Methods.—

(1) TRAINING REQUIREMENT.—The Secretary shall ensure that any personnel from the relevant organizations in each of the military departments and Defense Agencies participating in the pilot program, including organizations responsible for engineering, budgeting, contracting, test and evaluation, requirements validation, and certification and accreditation, receive targeted training in agile or iterative development methods, including the interim course required by section 891 of this Act.

(2) SUPPORT.—In carrying out the pilot program under subsection (a), the Secretary shall ensure that personnel participating in the program provide feedback to inform the development of education and training curricula as required by section 891.

(e) Sunset.—The pilot program required under subsection (a) shall terminate on September 30, 2023. Any system selected under subsection (a)(3) for the pilot program shall continue after that date through the execution of its realignment plan.

(f) Agile Or Iterative Development Defined.—In this section, the term “agile or iterative development”, with respect to software—

(1) means acquisition pursuant to a method for delivering multiple, rapid, incremental capabilities to the user for operational use, evaluation, and feedback not exclusively linked to any single, proprietary method or process; and

(2) involves—

(A) the incremental development and fielding of capabilities, commonly called “spirals”, “spins”, or “sprints”, which can be measured in a few weeks or months; and

(B) continuous participation and collaboration by users, testers, and requirements authorities.

FY18 NDAA Section 874 Software Development Pilot Program Using Agile

(a) In General.—Not later than 30 days after the date of the enactment of this Act, the Secretary of Defense shall identify no fewer than four and up to eight software development activities within the Department of Defense or military departments to be developed in a pilot program using agile acquisition methods.

(b) Streamlined Processes.—Software development activities identified under subsection (a) shall be selected for the pilot program and developed without incorporation of the following contract or transaction requirements:

(1) Earned value management (EVM) or EVM-like reporting.

(2) Development of integrated master schedule.

(3) Development of integrated master plan.

(4) Development of technical requirement document.

(5) Development of systems requirement documents.

(6) Use of information technology infrastructure library agreements.

(7) Use of software development life cycle (methodology).

(c) Roles And Responsibilities.—

(1) IN GENERAL.—Selected activities shall include the following roles and responsibilities:

(A) A program manager that is authorized to make all programmatic decisions within the overarching activity objectives, including resources, funding, personnel, and contract or transaction termination recommendations.

(B) A product owner that reports directly to the program manager and is responsible for the overall design of the product, prioritization of roadmap elements and interpretation of their acceptance criteria, and prioritization of the list of all features desired in the product.

(C) An engineering lead that reports directly to the program manager and is responsible for the implementation and operation of the software.

(D) A design lead that reports directly to the program manager and is responsible for identifying, communicating, and visualizing user needs through a human-centered design process.

(2) QUALIFICATIONS.—The Secretary shall establish qualifications for personnel filling the positions described in paragraph (1) prior to their selection. The qualifications may not include a positive education requirement and must be based on technical expertise or experience in delivery of software products, including agile concepts.

(3) COORDINATION PLAN FOR TESTING AND CERTIFICATION ORGANIZATIONS.—The program manager shall ensure the availability of resources for test and certification organizations support of iterative development processes.

(d) Plan.—The Secretary of Defense shall develop a plan for each selected activity under the pilot program. The plan shall include the following elements:

(1) Definition of a product vision, identifying a succinct, clearly defined need the software will address.

(2) Definition of a product road map, outlining a noncontractual plan that identifies short-term and long-term product goals and specific technology solutions to help meet those goals and adjusts to mission and user needs at the product owner’s discretion.

(3) The use of a broad agency announcement, other transaction authority, or other rapid merit-based solicitation procedure.

(4) Identification of, and continuous engagement with, end users.

(5) Frequent and iterative end user validation of features and usability consistent with the principles outlined in the Digital Services Playbook of the U.S. Digital Service.

(6) Use of commercial best practices for advanced computing systems, including, where applicable—

(A) Automated testing, integration, and deployment;

(B) compliance with applicable commercial accessibility standards;

(C) capability to support modern versions of multiple, common web browsers;

(D) capability to be viewable across commonly used end user devices, including mobile devices; and

(E) built-in application monitoring.

(e) Program Schedule.—The Secretary shall ensure that each selected activity includes—

(1) award processes that take no longer than three months after a requirement is identified;

(2) planned frequent and iterative end user validation of implemented features and their usability;

(3) delivery of a functional prototype or minimally viable product in three months or less from award; and

(4) follow-on delivery of iterative development cycles no longer than four weeks apart, including security testing and configuration management as applicable.

(f) Oversight Metrics.—The Secretary shall ensure that the selected activities—

(1) use a modern tracking tool to execute requirements backlog tracking; and

(2) use agile development metrics that, at a minimum, track—

(A) pace of work accomplishment;

(B) completeness of scope of testing activities (such as code coverage, fault tolerance, and boundary testing);

(C) product quality attributes (such as major and minor defects and measures of key performance attributes and quality attributes);

(D) delivery progress relative to the current product roadmap; and

(E) goals for each iteration.

(g) Restrictions.—

(1) USE OF FUNDS.—No funds made available for the selected activities may be expended on estimation or evaluation using source lines of code methodologies.

(2) CONTRACT TYPES.—The Secretary of Defense may not use lowest price technically acceptable contracting methods or cost plus contracts to carry out selected activities under this section, and shall encourage the use of existing streamlined and flexible contracting arrangements.

(h) Reports.—

(1) SOFTWARE DEVELOPMENT ACTIVITY COMMENCEMENT.—

(A) IN GENERAL.—Not later than 30 days before the commencement of a software development activity under the pilot program under subsection (a), the Secretary shall submit to the congressional defense committees a report on the activity (in this subsection referred to as a “pilot activity”).

(B) ELEMENTS.—The report on a pilot activity under this paragraph shall set forth a description of the pilot activity, including the following information:

(i) The purpose of the pilot activity.

(ii) The duration of the pilot activity.

(iii) The efficiencies and benefits anticipated to accrue to the Government under the pilot program.

(2) SOFTWARE DEVELOPMENT ACTIVITY COMPLETION.—

(A) IN GENERAL.—Not later than 60 days after the completion of a pilot activity, the Secretary shall submit to the congressional defense committees a report on the pilot activity.

(B) ELEMENTS.—The report on a pilot activity under this paragraph shall include the following elements:

(i) A description of results of the pilot activity.

(ii) Such recommendations for legislative or administrative action as the Secretary considers appropriate in light of the pilot activity.

(i) Definitions.—In this section:

(1) AGILE ACQUISITION.—The term “agile acquisition” means acquisition using agile or iterative development.

(2) AGILE OR ITERATIVE DEVELOPMENT.—The term “agile or iterative development”, with respect to software—

(A) means acquisition pursuant to a method for delivering multiple, rapid, incremental capabilities to the user for operational use, evaluation, and feedback not exclusively linked to any single, proprietary method or process; and

(B) involves—

(i) the incremental development and fielding of capabilities, commonly called “spirals”, “spins”, or “sprints”, which can be measured in a few weeks or months; and

(ii) continuous participation and collaboration by users, testers, and requirements authorities.

FY18 NDAA Section 891 Training on Agile or Iterative Development Methods

(a) In General.—Not later than 180 days after the date of the enactment of this Act, the Secretary of Defense, in consultation with the President of the Defense Acquisition University, shall establish a training course at the Defense Acquisition University on agile or iterative development methods to provide training for personnel implementing and supporting the pilot programs required by sections 873 and 874 of this Act.

(b) Course Elements.—

(1) IN GENERAL.—The course shall be taught in residence at the Defense Acquisition University and shall include the following elements:

(A) Training designed to instill a common understanding of all functional roles and dependencies involved in developing and producing a capability using agile or iterative development methods.

(B) An exercise involving teams composed of personnel from pertinent functions and functional organizations engaged in developing an integrated agile or iterative development method for a specific program.

(C) Instructors and content from non-governmental entities, as appropriate, to highlight commercial best practices in using an agile or iterative development method.

(2) COURSE UPDATES.—The Secretary shall ensure that the course is updated as needed, including through incorporating lessons learned from the implementation of the pilot programs required by sections 873 and 874 of this Act in subsequent versions of the course.

(c) Course Attendance.—The course shall be—

(1) available for certified acquisition personnel working on programs or projects using agile or iterative development methods; and

(2) mandatory for personnel participating in the pilot programs required by sections 873 and 874 of this Act from the relevant organizations in each of the military departments and Defense Agencies, including organizations responsible for engineering, budgeting, contracting, test and evaluation, requirements validation, and certification and accreditation.

(d) Agile Acquisition Support.—The Secretary and the senior acquisition executives in each of the military departments and Defense Agencies, in coordination with the Director of the Defense Digital Service, shall assign to offices supporting systems selected for participation in the pilot programs required by sections 873 and 874 of this Act a subject matter expert with knowledge of commercial agile acquisition methods and Department of Defense acquisition processes to provide assistance and to advise appropriate acquisition authorities of the expert’s observations.

(e) Agile Research Program.—The President of the Defense Acquisition University shall establish a research program to conduct research on and development of agile acquisition practices and tools best tailored to meet the mission needs of the Department of Defense.

(f) Agile Or Iterative Development Defined.—The term “agile or iterative development”, with respect to software—

(1) means acquisition pursuant to a method for delivering multiple, rapid, incremental capabilities to the user for operational use, evaluation, and feedback not exclusively linked to any single, proprietary method or process; and

(2) involves—

(A) the incremental development and fielding of capabilities, commonly called “spirals”, “spins”, or “sprints”, which can be measured in a few weeks or months; and

(B) continuous participation and collaboration by users, testers, and requirements authorities.

Share This