DHS Instruction 102-01-004: Agile Development and Delivery for IT

The content featured under this section of ACQUIRE is the exact language that can be found in the Department of Homeland Security (DHS) Instruction 102-01-004, Agile Development and Delivery for Information Technology, Issue Date: 4/11/2016. ACQUIRE provides the acquisition community with a digitized and interactive version to facilitate easier and faster navigation of this policy.
For information technology (IT) programs and projects, the Department of Homeland Security (DHS) is establishing agile development as the preferred developmental approach. DHS agile development policy is shaped by the Federal Chief Information Officer (CIO) and Office of Management and Budget (OMB) guidance1 on modular development.

This instruction provides the scope, definitions, roles and responsibilities, and procedures to establish an agile framework for the development of IT acquisitions within DHS.

Programs/projects implementing agile development are still subject to the requirements of the Acquisition Lifecycle Framework and the Systems Engineering Life Cycle established under Management Directive 102-01.

The DHS agile framework does not mandate a specific agile method.

1: 25 Point Implementation Plan to Reform Federal Information Technology Management (U.S. Chief Information Officer, December 9, 2010); Contracting Guidance to Support Modular Development (Office of Management and Budget, June 14, 2012)

This instruction applies throughout DHS to all IT acquisitions (e.g., programs, projects, or activities) whose purpose is to deliver an IT, or embedded-IT, capability. This instruction also provides additional guidance through guidebooks to support the implementation of agile methodologies.2

2 The DHS Agile Guidebook provides specific examples of implementing agile methodologies under the Acquisition Lifecycle Framework (ALF).

A. Agile Development: An iterative and incremental approach to developing IT capabilities where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. Agile development promotes continuous adaptive planning, development, testing, and delivery/integration, and encourages rapid and flexible response to change. Agile is not one specific methodology, but is a conceptual framework implemented through various agile methods that promote delivering working, tested, deployable IT solutions on an incremental basis to increase value, visibility, and adaptability, and to reduce program/project risk. Agile development approaches support the Federal CIO’s goal to reform IT management and preference for modular acquisition approaches to release working functionality in “release cycles no longer than 12 months, and ideally, less than six months, with initial deployment to end users no later than 18 months…”3 These timelines encompass the entire process – from the point at which an agile methodology is selected and approved through requirements analysis, design, development, test, and delivery.4

B. Agile Methodologies: The specific principles, practices, and tools used to develop and deliver IT capabilities that adhere to the fundamental principles of agile development. Various agile methodologies share much of the same philosophy, particularly the iterative nature of development, as well as many of the same characteristics and practices. However, from an implementation standpoint, each agile method has its own set of practices, terminology, and tactics.

C. Modular Contracting: Contracting techniques that enable successive acquisitions of interoperable increments when acquiring major or non-major IT systems. Each increment needs to comply with common or commercially accepted standards applicable to information technology so that the increments are compatible with other increments of information technology comprising the system.5

D. Modular Development: An approach that focuses on the delivery of specific investments, projects, or activities of an overall  capability by progressively expanding upon delivered capabilities until the full capability is realized. Investments may be decomposed into discrete projects, increments, or useful segments, each of which is undertaken to develop and implement products and capabilities that the larger investment delivers.6

3: 25 Point Implementation Plan to Reform Federal Information Technology Management (U.S. Chief Information Officer, December 9, 2010)
4: For this instruction, the timeline for the first increment is set during Solution Engineering (i.e., between ADE-1 and ADE-2A).
5 See FAR Part 39.103 Modular Contracting for full definition.
6 See Contracting Guidance to Support Modular Development (OMB, June 14, 2012)

A. Chief Information Officer (CIO):

  1. Manages the IT portfolio of the Department, and as such, sets the policies and procedures to ensure agile development best practices are leveraged to meet the Department’s goals and are within acquisition policy established by Directive 102-01;
  2. Reviews IT investments to ensure appropriate tailoring and execution of agile methodologies in consideration of the context of the specific programs and domains;
  3. With the Chief Procurement Officer (CPO); Component Acquisition Executives (CAE); Science & Technology Directorate’s Director, Test and Evaluation (DOT&E); and Component CIOs, sets agile outcomes and target measures, monitors the progress of DHS in achieving agile outcomes, and reports (as required) to OMB and the Government Accountability Office (GAO) on DHS attainment of outcome metrics and associated benefits; and
  4. Supported by CPO; CAEs; DOT&E; and the Office of Program Accountability and Risk Management (PARM), provides guidance,
    training, and mentoring for the adoption and execution of agile development.

B. Chief Procurement Officer:

  1. Supports DHS contracting organizations in implementing OMB guidance on modular contracting.
  2. Supported by the CIO, CAEs, and PARM, provides guidance, training, and mentoring for the adoption and execution of modular contracting in support of modular development programs/projects.
  3. Supported by the CIO, sets modular contracting implementation metrics and reporting requirements.
  4. Supported by the CIO, CAEs, and PARM, assesses training opportunities and identifies appropriate agile methodology training for acquisition professionals, including PMs, test and evaluation personnel, system engineers, contracting officers, and logisticians.

C. Chief Financial Officer tailors, as necessary, OMB guidance with regard to flexible budget and funding7 models that support agile development of IT acquisitions and distributes it to applicable parties within DHS.

D. Director, Office of Test and Evaluation, Science & Technology Directorate: 

  1. Provides independent test and evaluation (T&E) oversight for Level 1, non-delegated Level 2, and special acquisition programs, procurements, or capital investments using approved development methodologies based on authority and responsibility as directed in DHS Directive 026-06 and Delegation 10003.
  2. Works with acquisition programs using agile methodologies to develop integrated T&E strategies tailored to support agile development in accordance with DHS T&E policy.
  3. Provides T&E consultation to non-oversight acquisition programs dependent upon available DOT&E staff resources.

E. The Executive Director, Office of Program Accountability and Risk Management supports the Chief Acquisition Officer in managing DHS-wide acquisition program policy, governance, and oversight in accordance with Directive 102-01.

F. Component Chief Information Officers:

  1. Maintain oversight of their Component’s agile development approach for IT by appointing the responsible personnel, identifying investments for adoption, and reviewing artifacts.
  2. With CAEs, evaluate and approve the application of agile development for IT programs consistent with the Component’s agile development approach.
  3. Set modular outcomes and target measures to monitor the progress in achieving agile implementation for IT programs/projects within their Component.

G. Component Chief Financial Officers:

  1. Present program and budget requests that clearly describe the capability of the requested program and that justify its modular aspect and effectiveness to the Department’s mission.
  2. Certify, throughout the program and budget review process, that the program is fully resourced. If the program is not fully resourced, the Component needs to identify the trade-offs necessary to fund the acquisition within existing resources, or reduce performance/scope and/or schedule to make the acquisition affordable.

H. Component Acquisition Executives:

  1. Supported by Component CIOs and Heads of Contracting Authority (HCA), oversee Component programs (or delegated programs) to ensure compliance with this instruction.
  2. With Component CIOs, encourage PMs and other stakeholders to apply agile methodologies for IT acquisitions, where appropriate.
  3. With Component CIOs and HCAs, measure progress in achieving agile outcomes and help to identify benefits.
  4. Work with the DOT&E, to ensure programs using agile methodologies develop integrated T&E strategies tailored to support agile development in accordance with DHS T&E policy.

I. Lead Business Authorities (LBA) identify and prioritize usable functionality8 for implementation in six, twelve, or eighteen month cycles, as appropriate.

J. Lead Technical Authorities (LTA) identify technological opportunities, critical technologies, maturity of technologies, commercial off the shelf (COTS) potential, and approaches for incorporating best technologies into systems.

K. Program and Project Managers (PM) implement agile methodologies where applicable to gain agility, accelerate delivery of capabilities to users, match technology cycles, and reduce risk with the assistance and support of LBAs and LTAs.

3: 25 Point Implementation Plan to Reform Federal Information Technology Management (U.S. Chief Information Officer, December 9, 2010)
4: For this instruction, the timeline for the first increment is set during Solution Engineering (i.e., between ADE-1 and ADE-2A).
5 See FAR Part 39.103 Modular Contracting for full definition.
6 See Contracting Guidance to Support Modular Development (OMB, June 14, 2012)
7 This includes Planning, Programming, Budgeting, and Execution (PPBE) models.
8 Usable functionality is defined in most situations as a new or enhanced IT capability used by one or more customers in production.

A. Agile Development Procedures and Considerations for Major Programs:

Major program acquisition is governed by Management Directive 102-01, the Acquisition Lifecycle Framework (ALF) and Systems Engineering Life Cycle (SELC) framework. Major programs are required to have acquisition and SELC review processes, events and artifacts, governance and oversight, and decision authorities as described in paragraphs A.1-A.4:

1. An early decision that any program team makes is the selection and employment of the developmental methodologies to execute the program’s systems engineering effort. The development methodologies are linked to the acquisition strategy a program follows. All development methodologies can be tailored under the SELC framework. Development methodologies are not mutually exclusive and can be used in conjunction with one another in an overall program to achieve the greatest efficiency. Additional details are provided in the DHS Agile Guidebook.

2. New programs that intend to use agile development need to document the rationale for selecting agile in their SELC tailoring plan. The SELC tailoring plan is initiated in the Analyze/Select Phase of the ALF and approved no later than Acquisition Decision Event (ADE)-2B, or the equivalent component level acquisition decision milestone, in the Obtain Phase. The SELC tailoring plan also identifies the specific activities, reviews, and artifacts modified or tailored out in support of the selected agile methodology. As part of the planning effort leading to the ADE-2B decision milestone, stakeholders are to ensure that sufficient time remains to allow the first delivery of capability to occur no longer than 12 months, and ideally, less than six months following the ADE-2B decision unless a sound justification is made to extend this timeframe (up to 18 months maximum).

3. Prior to ADE-2B, the program determines if the capability approved at ADE-2A is divided into discrete and separate projects or if the entire capability is managed as one project. If the program is divided into discrete and separate projects, each project requires an ADE-2B and the Acquisition Program Baseline (APB) reflects that completion of all projects result in delivery of the capability/scope of work approved at ADE-2A. Further, at ADE-2B the planning for each project, through the final project release, demonstrates the appropriate integration/hardening of the capability into the overall system and architecture. For each project, the PM and appropriate stakeholders negotiate a release roadmap that identifies the proposed scope of each release with the first delivery occurring 12 months or less following the ADE-2B and subsequent releases at 6 to 12 month intervals, or less, after the first. Under this release roadmap, the approval authority for each subsequent release may be delegated to the CAE (in writing). The Program Management Plan, Systems Engineering Plan, Test and Evaluation Master Plan, or equivalent artifacts identify specific metrics to be used to evaluate performance and progress against the release roadmap, processes for revising the release roadmap, and periodic reviews with the senior executive. The Acquisition Decision Authority (ADA) may require a program review on an annual basis until the program has delivered full operational capability (FOC) if FOC is not planned to be reached within 18 months of ADE-2B approval. The ADA may conduct a program review at any time if programmatic and/or technical risks or issues are identified during any release cycles.

4. For IT Programs that have reached the Obtain Phase, or are partly in the Produce/Deploy/Support/Dispose Phase of the ALF, and desire to transition to an agile methodology, the PM needs to prepare/update all applicable key acquisition planning documents. For example: a new SELC tailoring plan that documents and justifies the change in development methodology and identifies the specific activities, reviews, and artifacts to be modified or tailored in support of the selected development methodology from the point at which the program transitions. If this program re-baseline necessitates a new ADE-2A/2B, then the requirements of paragraphs VI.A.2 and VI.A.3 apply.

5. For IT Programs in the Produce/Deploy/Support/Dispose Phase of the ALF with no development, if an operational analysis determines that major enhancements are required, then the program needs to seek and obtain approval/concurrence for a new development effort to start. Once approved, if it is determined that an agile development approach is appropriate, then the guidance in paragraphs VI.A.2 and VI.A.3 applies. If the program has transitioned part of the planned capability into O&M, but continues as a developmental program, then enhancements, fixes, or business process impacts are to be planned and programmed for as necessary and included in future releases so long as these changes are within the scope of the specific project’s release roadmap.

B. Agile Development Procedures and Considerations for Component, Non-major, and Delegated IT Programs:

In order to effectively implement the adoption of agile development across the DHS enterprise, IT non-major and delegated programs are also required to follow Directive 102-01 or demonstrate that they have equivalent events and artifacts, governance and oversight, and decision authorities as described for major programs in paragraphs VI.A.1 through VI.A.5 or appropriate tailoring that aligns to them.

C. DHS SELC and Agile Guidebooks and Additional Resources: 

The DHS SELC Guidebook provides a highly tailorable and complete life-cycle framework for both IT and non-IT programs and projects. Using critical thinking and the SELC Tailoring Guidance Section, the PM and stakeholders can develop a sound agile approach and detailed set of activities, artifacts, and reviews that match the specific situation of the program or project. The SELC Guidebook describes agile methodologies at a high level in the Tailoring Guidance Section. Agile methodologies are described in more detail in the DHS Agile Guidebook. The Agile Guidebook also describes the types of IT programs that are candidates for effectively implementing agile development. Other considerations, such as strategic planning, Enterprise Architecture, etc., are contained in the DHS Agile Guidebook.

D. Component Compliance:

  1. Annually, beginning 6 months from the date of issuance of this instruction, the Component CIO apprises the CAE and OCIO of:
    • The number and percent of their IT programs that have applied an agile methodology or plan to do so (with timeframes)
    • Component plans to increase the use of agile development
    • Justification for any major IT programs that are not intending to use agile development.
  2. Components clearly identify on OMB business case submissions whether, for each project, functionality is delivered within the time frames indicated in this instruction, and requires justification for programs/projects that do not plan to do so.
Address questions or concerns regarding this Instruction to the Office of the Chief Information Officer (OCIO), or OCIOExecSec@hq.dhs.gov.


Share This