Hegseth just killed Waterfall and mandated Agile + DevSecOps for the world's largest bureaucracy

By Andrew Park | 2025-11-11

On November 7, 2025, Secretary of Defense Pete Hegseth eliminated the institutional machinery that enforced Waterfall development in defense acquisition and mandated Agile + DevSecOps for all software. For software engineers studying the history of their profession, this is the day the last major Waterfall stronghold finally fell.

What Just Happened: A Historic Moment

On November 7, 2025, the Department of Defense (DoD) released two documents that fundamentally transformed defense acquisition: the Acquisition Transformation Strategy and Secretary Hegseth's memorandum Transforming the Defense Acquisition System into the Warfighting Acquisition System.[1][2]

Secretary Hegseth just killed Waterfall.

Not reformed it. Not improved it. Eliminated the institutional structures that kept it alive.

For software engineers studying the history of their profession, November 7, 2025 will mark the day the last major Waterfall stronghold finally fell, almost 25 years after the Agile Manifesto came on the scene [3].

Better late than never.

Why This Matters

The DoD is the world's largest bureaucracy, with an annual budget exceeding $850 billion. It develops some of the most complex software systems ever built: systems that must work across decades, integrate with legacy platforms, operate in contested environments, and literally be ready for war.

If Waterfall could work anywhere, it would be here.

For 50 years, the DoD seemed to be Waterfall's natural habitat: massive budgets, multi-year programs, detailed requirements defined by Congress, strict compliance regimes, and an institutional culture that valued predictability over speed.

That environment no longer exists. And Hegseth just made sure it can't come back.

How Hegseth Killed Waterfall: The Evidence

The proof isn't in aspirational statements about "being more agile." Hegseth systematically dismantled every institutional structure that supported Waterfall.

1. Requirements-First Development Is Dead

The old approach: Spend years defining every specification upfront in exhaustive requirements documents, then build exactly to that specification.

The new approach: The DoD will present operational problems and to industry performers and allow these companies to propose and demonstrate solutions through modeling or prototyping. [2]

This is the complete inversion of the Waterfall model. Instead of "here are the detailed requirements, now build it," the new model is "here's the problem, show us what's possible."

Waterfall depended on having complete, detailed requirements before development started. But in defense software development, this created a pervasive challenge: the buyer-user disconnect meant requirements were often defined by people who wouldn't actually use the systems.[4] Pentagon acquisition officials used to define what they believed warfighters needed, but by the time operators received the delivered solution, it often failed to address the real problems or required messy workarounds to be usable.

Solutions-based acquisition seeks to invert this entirely: show working prototypes to actual users, get feedback, iterate. Requirements emerge from demonstrated capabilities rather than preceding them.

2. Analysis of Alternatives Is Dead

The old system: "The analysis of alternatives (AoAs) process requires long periods of study and analysis time prior to initiating a program of record."[2]

Analysis of Alternatives was a formal DoD process requiring exhaustive studies, typically 12 to 24 months, comparing every possible technical approach before choosing one to develop.

The new system: "Successfully demonstrated solutions will be eligible for contract awards."[2]

Waterfall thrived in an environment of extreme risk aversion, where multi-year paper studies were used to analyze every possible option before making a decision. This mindset is the opposite of what’s needed for rapid innovation. The new approach flips that model by prioritizing working prototypes over analysis documents, allowing teams to learn and adapt quickly.

Instead of spending years analyzing whether Approach A or Approach B is better, the smarter move is to build both and see what actually works. That is exactly what the Air Force CCA competition between Anduril and General Atomics is doing... testing real systems to find out which delivers the most effective results.

3. Sequential Phase Gates Are Dead

The strategy empowers DoD Program Managers (e.g., Captains & Colonels responsible for executing individual defense programs) "to make requirements trade-offs without navigating multiple approval chains."[2]

Configuration Steering Boards (the compliance-checking committees that enforced Waterfall's sequential phases) are being replaced by Capability Trade Councils focused on operational needs rather than process compliance.[2]

What this means in practice: DoD Program Managers can adjust priorities, make technical decisions, and respond to what they learn, all without the formal change control processes that defined Waterfall.

You can't run two-week sprints if every change requires a Configuration Steering Board review and approval.

4. All Software Development Must Now Use Agile + DevSecOps

This is the mandate that makes Waterfall's death irreversible.

From Secretary Hegseth's March 6, 2025 memorandum: "I am directing all DoD Components to adopt the Software Acquisition Pathway (SWP) as the preferred pathway for all software development components of business and weapon system programs in the Department."[1]

Not "encouraged to consider." Not "pilot programs to explore." Directed. All components. All software development.

The Software Acquisition Pathway is the DoD's policy framework for developing software-intensive systems using modern commercial practices rather than traditional defense processes.

What does it actually require?

"While commercial industry has rapidly adjusted to a software-defined product reality, DoD has struggled to reframe our acquisition process from a hardware-centric to a software-centric approach."[1]

The Software Acquisition Pathway mandates iterative development with continuous delivery, DevSecOps pipelines with automated testing and security integration, and modern contracting approaches including Other Transactions (flexible contract vehicles that bypass traditional procurement regulations) and Commercial Solutions Openings (streamlined competitions for commercial products). It requires commercial practices rather than traditional defense-specific processes, prioritizing speed and flexibility to "keep pace with commercial technology advancements."[1]

In plain terms: every software project in the Department of Defense (whether it's a standalone application or software embedded in a weapons system) must now be developed using Agile methodologies and DevSecOps practices.

You cannot do two-week sprints, continuous integration, and continuous delivery in a Waterfall model. You cannot have sequential phase gates and iterative development. The Software Acquisition Pathway and Waterfall are fundamentally incompatible.

By making the Software Acquisition Pathway mandatory for all software, Hegseth made Waterfall structurally impossible.

5. The Requirements Engine Is Being Eliminated

The strategy explicitly calls for "eliminating the Joint Capabilities Integration and Development System (JCIDS)."[2]

JCIDS (pronounced "jay-kids") was the massive DoD bureaucracy that produced detailed, upfront requirements documents for every major defense program. It operated as a multi-year process involving multiple military services, combatant commands, and Pentagon offices, all working to define complete requirements before any development could begin.

Think of it as a massive requirements factory that had to finish its entire production run before developers could write a single line of code.

Without JCIDS, requirements-driven sequential development cannot survive in its traditional form.

Why This Is Permanent

Here's what makes this transformation irreversible: Hegseth didn't just issue new guidance encouraging modern practices alongside existing processes. He eliminated the institutional machinery that enforced Waterfall:

✗ No more JCIDS producing massive requirements documents before development starts

✗ No more multi-year Analysis of Alternatives studies

✗ No more compliance-focused Configuration Steering Boards blocking changes

✗ No more centralized change control preventing adaptation

✓ Mandatory Agile + DevSecOps for all software development

Without these structures, Waterfall cannot survive. Even if a future administration wanted to return to the old model, the scaffolding that made it work is gone.

You can't run Waterfall without a requirements engine. You can't run Waterfall without sequential phase gates. You can't run Waterfall without change control boards that review and approve every modification.

All of these are now either eliminated or transformed into something that serves iteration rather than preventing it.

What Replaces Waterfall: The Mandated Alternative

With Waterfall dead, what replaces it?

The strategy is explicit: "Speed to capability delivery is now our organizing principle: the decisive factor in maintaining deterrence and warfighting advantage."[2]

The execution model mandated to achieve this centers on Agile development with iterative delivery and continuous feedback, DevSecOps pipelines with automated testing and security integration, commercial practices that maximize purchase from the commercial marketplace, and rapid contracting through Other Transactions and Commercial Solutions Openings.

The document also makes clear why this shift is happening now:

"Today's unacceptably slow acquisition delivery and fielding times stem from three systemic challenges: (1) fragmented accountability where no single leader has the necessary authorities to lead our programs and urgently deliver results; (2) broken incentives that reward completely satisfying every requirement and specification at significant cost to on-time delivery; and (3) government procurement behaviors that disincentivize industry investment, efficient production, and growth."[2]

In other words, Waterfall’s biggest failure was that its incentive structure made it more rational to focus on meeting every requirement than on delivering quickly or achieving real mission outcomes.

Hegseth's transformation doesn't just change the process. It changes the incentives.

What This Means for the Industry

For software engineers and tech companies, Hegseth’s transformation creates immediate and profound changes.

The Defense Industrial Base is being forced open. The strategy explicitly calls for expanding the number of companies building military systems, making it easier for nontraditional defense contractors to participate. It encourages the use of Commercial Solutions Openings and Other Transaction Agreements, which are flexible contract vehicles that bypass traditional procurement regulations, and allows acceptance of solutions that meet operational needs even if they do not meet every specification.

Commercial practices are now preferred, not discouraged. The old system required defense-specific processes, while the new one explicitly favors commercial approaches wherever possible.

Speed is now a requirement. The strategy rewards early delivery and penalizes delay. Companies that can demonstrate working solutions quickly have a structural advantage over those that promise perfect solutions eventually.

We are about to see the most vibrant environment for new defense startups in our lifetimes. These reforms make it easier and more favorable than ever to launch a defense startup, creating an era of rapid innovation and opportunity. Existing defense primes will bear the consequences and will be forced to evolve very quickly to stay relevant.

This is the largest shift in defense acquisition since the Cold War, and it is now irreversible by policy mandate.

November 7, 2025: The Day Waterfall Finally Died

For 50 years, the Department of Defense was Waterfall's fortress: the one place where sequential development, detailed upfront requirements, and compliance-driven processes made institutional sense.

On November 7, 2025, Secretary of Defense Pete Hegseth demolished that fortress.

He didn't reform Waterfall. He didn't create a "hybrid model." He systematically eliminated every institutional structure that made Waterfall work: the requirements engine (JCIDS), the analysis process (AoA), the compliance gatekeepers (Configuration Steering Boards), the change control regime, and the preference for paper studies over working prototypes.

And he mandated Agile + DevSecOps (iterative development, automated testing and security, continuous delivery) for all software, across the entire Department of Defense.

This is permanent. The institutional machinery that enforced Waterfall no longer exists.

For software engineers studying the history of their profession, November 7, 2025 marks the end of an era: the day the last major Waterfall stronghold fell, approximately 24 years after the Agile Manifesto showed there was an alternative.

Waterfall is dead. Not just discouraged: structurally impossible in the world's largest bureaucracy.

But here's the question nobody's asking yet: Will Agile + DevSecOps (proven effective for small teams building discrete capabilities) actually work at the scale the DoD operates? Can two-week sprints and continuous delivery handle programs like Joint All-Domain Command and Control (connecting sensors to shooters across all services, all domains, all classification levels) or next-generation air dominance platforms (integrating stealth, AI autonomy, directed energy weapons, and networked operations across dozens of contractors)?

I don't think so. And in my next article, I'll explain why, and what the DoD actually needs to make this transformation work.

References

[1] Hegseth, P. (2025, March 6). Directing Modern Software Acquisition to Maximize Lethality. Secretary of Defense Memorandum. U.S. Department of Defense.

[2] U.S. Department of Defense. (2025, November 7). Acquisition Transformation Strategy: Transforming the Defense Acquisition System into the Warfighting Acquisition System to Accelerate Fielding of Urgently Needed Capabilities to Our Warriors. Office of the Under Secretary of Defense for Acquisition & Sustainment.

[3] Beck, K., et al. (2001). Manifesto for Agile Software Development. 

[4] Park, A. (2024). Why the DoD's Biggest Software Programs Keep Failing (and Why Operators Don't Use Them). LinkedIn. https://www.linkedin.com/pulse/why-dods-biggest-software-programs-keep-failing-operators-andrew-park-ghgme