The two hottest Department of Defense (DoD) acquisition buzzwords, Rapid and Agile, often are misconstrued and incorrectly interchanged by government, industry and academia.
Why is this a problem?
Individuals misusing the terms not only lose credibility with their stakeholders but create confusion during acquisition strategy development, request for proposal development, source-selection technical evaluation, and program execution. To help prevent loss of credibility and reduce confusion associated with these terms in the DoD acquisition ecosystem, I offer this clarification between Rapid and Agile, as well as DevOps and DevSecOps. Read on to learn how to avoid these common mistakes.
What Is Rapid in the Acquisition Environment?
Rapid is about tailoring, delegating and going fast. Rapid refers to critical thinking and scheduling associated with a program team navigating an acquisition pathway spectrum from strategy development through program execution in order to expedite delivering capability into the hands of the warfighter.
Specifically, Rapid focuses on leveraging statutory and regulatory authorities to tailor the program’s acquisition strategy—minimizing which artifacts and activities need to be generated, who needs to coordinate, and who needs to approve. Rapid looks to determine the “must do/can’t fail” statutory and regulatory activities and drive decision authorities down to the lowest reasonable levels while considering who in the acquisition coordination processes represents value added. Rapid acquisition acknowledges that there are a set of “known unknowns” and “unknown unknowns” early in the process, and thus strategies and contracting vehicles should be reasonably scalable and flexible to maintain pivot point opportunities as previous unknowns materialize.
The DoD has established a conservative, multi-tiered process to acquire capability. Congress, per the annual National Defense Authorization Acts (NDAAs) over the last few decades, added a vast number of statutory requirements. These are legal “must do” requirements, whereas policies outline the regulatory requirements which can be tailored or waived with appropriate DoD leadership approval. These policies are spread across the Federal Acquisition Regulation (FAR), DoD Instruction series, and Service-specific policies captured in instructions, manuals, etc. A program team must scour these sources to understand the scope of authorities and leverage this knowledge for program execution.
The goal of Rapid acquisition is to develop an acquisition strategy that focuses on getting capability into the hands of the warfighter as soon as possible. Key considerations to determine the most Rapid means to deliver capability:
- How to define the new program—is it a large, enduring Major Defense Acquisition Program? Is it a smaller program? Is it an urgent need? Or is it a portfolio of activities consisting of multiple programs in various stages and program frameworks?
- Who is reasonably the lowest level executive agent? Is it Office of the Secretary of Defense, (component acquisition executive, program executive officer), or the program manager? What would it take to delegate authority to the lowest competent level to expedite decisions/approvals?
- What is the minimum list of statutory and regulatory artifacts? How can each of these be tailored and sprinkled with “to-be-determined” placeholders at the beginning, and still receive Acquisition Strategy approval to initiate program execution activities?
- What is the minimum list of statutory and regulatory activities? How can these be tailored and scheduled to keep moving forward to deliver capability?
- How can the artifact development and associated activities be scheduled to define the minimal critical path to fielding capability, with considerations to remove activities off the critical path, minimize slack, target timely application of program resources (funding, people, contract vehicles, etc.)?
- What contracting vehicles are available to expedite delivery of capabilities?
- What is “legally sufficient”—aka, the floor to consider from the Judge Advocate perspective validating compliance with statutes and taking into consideration the likelihood of contract award protest(s)?
Some key terms you will hear from organizations using Rapid principles: tailoring, delegation of approvals/decisions, documentation sufficiency, “go fast,” accelerate, velocity, vector.
What Is Agile in the Acquisition Environment?
Agile is about using flexible design, development and fielding processes to make sure that the team gets the system right. Agile refers explicitly to
industry principles and methodologies of developing and fielding the program’s specific capability to the warfighter in small, short phases to enable timely feedback and drive down the program cost/schedule/ performance risks. Specific terminologies and activities are associated with Agile. I recommend reading The Agile Manifesto followed by The DevOps Handbook (2016, IT Revolution Press by Gene Kim and Jez Humble, et al.).
Regarding Agile, consider the cost, schedule, and performance risks associated with collecting a series of validated requirements and then spending 10 to 20 years to field the capability to the customer.
- What program risks have been realized during that time period?
- How has technology changed in 20 years? It is still relevant? What about Diminishing Manufacturing Sources?
- How has the mission/requirement changed in 20 years?
- How has the military organization/presentation of forces changed in 20 years?
- What are the sunk costs?
- Is/are the contract vehicle(s) sufficient to mitigate requirement changes?
Some key terms you will hear from organizations using Agile principles: DevOps, scrum, sprint cycle, automated testing, deployment, canary test, test-driven development, quality assurance, and scaled Agile framework. It is also worth mentioning two associated terms that fall under the umbrella of Agile: DevOps and DevSecOps. These terms also tend to be misconstrued, so I offer the following definitions from industry:
DevOps: According to Kim and Humble’s book, DevOps is “… the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. … The result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA [quality assurance] IT [information technology] Operations, and Infosec [information security].”
DevSecOps: According to Red Hat, a leading company in Agile software, DevSecOps, “ … is about built-in security, not security that functions as a perimeter around apps and data. If security remains at the end of the development pipeline, organizations adopting DevOps can find themselves back to the long development cycles they were trying to avoid in the first place.”
Why Do “Rapid” and “Agile” Get Misconstrued?
When introducing any new activity to a workforce, there always is a need for education, training and experience. Without that standardization, individuals are left to figure things out on their own and may come to divergent conclusions. Since there are some similarities in the cultures and processes for Rapid and Agile, individuals may correlate activities to the incorrect concept. Most likely, people are promulgating what they are hearing in the program offices and shaping the definitions from their respective perceptions.
Quickly Remembering Which to Use
In short, use the term Rapid in addressing the overarching acquisition strategy and its delivery methodology (rapid prototyping, rapid fielding, tailored documentation, tailored milestone activities, making decisions and the lowest reasonable levels, etc.). Use the term Agile in addressing the continual approach to requirements deconstruction, software development, testing (incremental, scrum, sprint cycles, Kanban, backlog, customer engagement, iterative testing, etc.).
When you find yourself on a new project, remember to start the discussion by explicitly defining and differentiating Rapid, Agile, DevOps—and DevSecOps will help you inculcate your workforce in the terminology, thereby reducing the likelihood that the terms will be misused. Don’t let your team become separated by unintentionally using the wrong terms at the wrong times. For more information on Agile fundamentals, consider MITRE’s Acquisition in the Digital Age website, AiDA.
Remember: Rapid is tailoring and going fast to deliver capability sooner, and Agile is getting the capability itself right for the user by delivering smaller increments and engaging the user during the development and deployment activities. Best wishes in your program portfolio endeavors!
Zides is a principal program manager and agile acquisition subject-matter expert at The Mitre Corporation. She is a retired U.S. Air Force (USAF) lieutenant colonel acquisition officer who served as deputy director of the USAF Lifecycle Management Center’s acquisition excellence directorate and oversaw efforts including the USAF portfolio of urgent need activities to counter small unmanned aircraft sytems and the NATO Airborne Warning and Control System. She received her bachelor’s degree in mechanical engineering from Rensselaer Polytechnic Institute and a master’s degree in organizational management from George Washington University, a master’s degree in gastronomy from Boston University, and a master’s degree in military operations from Air University. She has guest lectured at the Defense Acquisition University.
The author can be contacted at
[email protected].
To print a PDF copy of this article,
click here.
