PPBE Reform: A Critical Blocker to Agile at Scale

If your Government program adopted SAFe and delivery still feels slow, look at your funding model and contract structure. They are likely pushing waterfall behavior, regardless of your framework choice.

The mismatch: software learns fast, PPBE moves slow

In March 2024, the Commission on Planning, Programming, Budgeting, and Execution (PPBE) Reform released its Final Report with 28 recommendations to change how the Department of Defense (DoD) resources modernization.¹ Congress's nonpartisan research arm made clear that some recommendations would replace DoD's "1960s-era" PPBE process.² Better late than never.

That matters because modern software needs to move fast. PPBE moves slow. If your program learns something important in month two, but the money can't move until next fiscal year, you don't have agility. You have 1960s-era speed.

Software is a discovery process. You ship a thin slice, watch what happens, adjust, and repeat. That learning loop is the point.

PPBE is built for a different world. It's a multi-year, plan-driven mechanism that pushes programs to define scope early, defend it repeatedly, and spend within narrow categories. That model breaks when the requirements are supposed to evolve as you learn.

Most Government contracts increase the traffic jam with process and formal rules. They mandate fixed requirements and plans that need to be "baselined". The whole concept of baselining and process-heavy maneuvers to change direction are the opposite of agility.

One way to explain it to non-technical stakeholders:

Trying to run iterative delivery with traditional contracts and PPBE is like plugging a Tesla into a 1970s gas pump. The car is fine. The station isn't set up for it.

"Color of money" is where the pain becomes real

In the federal environment, “color of money” determines what you can do this fiscal year.

Modern delivery teams do three things continuously:

• Build new capabilities
• Operate and secure what’s already in production
• Evolve based on user feedback and threat changes

PPBE tends to separate those activities into different funding “colors” and planning paths (for example, Research, Development, Test & Evaluation versus Operations & Maintenance). When you’re running delivery in tight increments, that separation becomes a constraint.

Here’s the pattern we see:

• You get user feedback that changes the highest-value feature.
• The team can implement it in weeks.
• The program can’t move money (or can’t accept the change without contract and budget gymnastics).
• The team keeps building what’s funded, even when everyone knows it’s no longer the best next step.

That’s not a team problem. It's not an agile framework problem. It’s a resourcing problem.

What this does to any framework: it promotes waterfall behavior

Scaling frameworks promise faster delivery. But locked budgets and fixed contracts turn any framework into agile delivery theater -- using the right terms and events, but providing limited value.

The funding system and contract incentives define what program behaviors get rewarded. Frameworks are neutral. The money determines whether teams can respond to learning or must follow a pre-approved plan.

Here's what we see across federal programs: they often slide into "Agile in name only" or "agile-scrum-fall," where ceremonies sit on top of a sequential plan-and-gate reality.³

The cost of this mismatch is quantifiable. A 2024 GAO review found that 13 out of 21 major DoD IT programs experienced cost increases (median +$163 million) and 7 had schedule slips of up to 3 years.⁵ Only 4 of the 21 met their performance targets.

When budgets and contracts are locked, Program Increment (PI) planning starts acting like a quarterly contract. The plan becomes the goal. The user outcome becomes secondary. The team gets measured on “did you do what you said?” instead of “did you deliver something useful?”

Two telltale signals you're watching delivery theater

You don't need a maturity model to spot these problems. Ask two questions:

1. When was the last time you changed priority based on real user feedback within a quarter and shipped that change within 30 days?

If the answer is "we can't change mid-PI" or "we need a reprogramming action first," you're watching the funding system steer delivery.

2. What happens when needs shift mid-year?

If the program's answer is "we absorb it as risk" or "we'll address it next FY," you are not operating an iterative model. You are operating a compliance model.

The methodology gets blamed because it's visible. But PPBE and contracts are the invisible layer defining what behaviors get rewarded.

Why now is different: the budget system is finally being named as the blocker

For years, many leaders treated PPBE like weather. Uncomfortable, but not changeable.

Now Congress is calling it what it is: a foundational blocker. The PPBE Reform Commission put a spotlight on the resourcing process itself and published concrete recommendations in March 2024.¹ Congress’s CRS summary (May 2024) describes the scope: recommendations range from replacing the “1960s-era” PPBE process to transforming the budget structure and addressing “colors of money.”²

Two practical implications for CIOs and PEOs:

• You now have a “top cover” reference for why your delivery approach needs funding flexibility.
• You can frame delivery modernization as resourcing and acquisition modernization, which is a different conversation than “we want to do Agile better.”

This matters in front of oversight. GAO has repeatedly documented that federal reporting practices and governance structures often don’t align with iterative delivery.^3,4 When you can point to formal reform work, you move the discussion from “process preference” to “institutional alignment.”

A 90-day playbook for CIOs and PEOs (before PPBE reform arrives)

PPBE reform will take time. Your programs are getting judged on delivery outcomes today.

Here are practical steps that work in real Government environments. None of them require you to wait for a new budget system.

Step 1: Treat funding as a delivery constraint you manage, not a backdrop

Write it down in plain language. For each major product line or capability area, capture:

• What funding “colors” you rely on today
• How do we implement simple changes to allow teams to work on both development and maintenance (i.e., DevOps)
• Where are handoffs creating delivery delays (especially for security, ATO work, and sustainment)

This becomes an executive artifact. It also helps you explain delivery risk in terms leaders recognize.

Step 2: Shift from “project funding” thinking to “team capacity” thinking

Even if you can’t fully restructure appropriations, you can start shifting how you describe the work:

• Stop talking about “delivering all requirements.”
• Start talking about funding a stable product team to deliver prioritized outcomes over time.

In SAFe language, this is the start of value stream funding. In mission language, it’s the difference between buying a plan and buying capacity. Buying team capacity allows your staff to tackle the most important issues, regardless of whether they are considered development or maintenance.

Common Pattern: Instead of funding "Project X," we have seen DHS components fund "Team Alpha" to clear a backlog of 50 distinct requests. They delivered the top 10 in the first quarter.

Step 3: Make “working software” your primary evidence for oversight

GAO’s Agile work emphasizes the need for strong monitoring and control, but in a way that matches iterative delivery.⁴

For leaders, that means building an evidence pack that answers the questions oversight bodies ask:

• What did you ship this quarter that is usable?
• Who used it, and what changed because of it?
• What did it cost, and what did you stop doing as a result?
• What risks did you retire (security, operational, schedule)?

This shifts the conversation away from “percent complete,” which doesn’t work when the backlog evolves.

Common Pattern: Replace the 10-page monthly status report with a 30-minute live demo and discussion of what got built this month. Oversight questions often drop by half.

Step 4: Align acquisition strategy with iterative reality

This is where your program probably gets stuck. They build in iterations, but the contract was written like a one-time delivery with fixed scope.

If you’re a CIO or Program Manager, you can ask one practical question that surfaces the mismatch fast:

Do our contract incentives reward shipping usable increments, or do they reward document milestones and scope completion?

If it’s the second, you will likely keep getting waterfall behaviors, no matter what your teams call their ceremonies.

Common Pattern: We see contracts that penalize the vendor for "incomplete planned scope" even when the government asked them to pivot. Allow substitutions to stay focused on the most important work.

Step 5: Build a “budget + product + delivery” triad for decisions

Most delivery slowdowns come from decision latency, not tool gaps. You can cut a lot of time by creating a standing weekly forum with:

• Product authority (what matters most now)
• Delivery authority (what can be shipped safely)

Keep it tight. Keep it focused on decisions, not updates.

The bottom line for Government leaders

If you're accountable for mission outcomes, the path forward is clear.

You need contract and resourcing models that encourage agility and move with speed.

The good news is that the conversation is changing. The 2024 PPBE Reform Commission and follow-on congressional analysis give federal leaders a credible way to say: “This isn’t about ceremonies. It’s about aligning money to outcomes.”

Steps you can take this week

• Pick one product line and map the contract and funding constraints that slow delivery.
• Define two outcome metrics that matter to mission users (not internal development activity).
• Require a quarterly demo of usable capability to real stakeholders.
• Review one major contract and check whether incentives match iterative delivery.

---

References

1. Commission on Planning, Programming, Budgeting, and Execution (PPBE) Reform, “Final Report” (news release and links), March 6, 2024. https://ppbereform.senate.gov/finalreport/
2. Congressional Research Service (Library of Congress), “PPBE Reform Commission Final Report Recommendations: Issues for Congress” (IN12372), May 31, 2024. https://www.congress.gov/crs-product/IN12372
3. U.S. Government Accountability Office (GAO), “Software Development: Effective Practices and Federal Challenges in Applying Agile Methods” (GAO-12-681), July 2012. https://www.gao.gov/products/gao-12-681
4. U.S. Government Accountability Office (GAO), “Agile Assessment Guide: Best Practices for Adoption and Implementation” (GAO-24-105506), reissued with revisions Dec. 15, 2023. https://www.gao.gov/assets/d24105506.pdf
5. U.S. Government Accountability Office (GAO), “IT Systems Annual Assessment: DOD Needs to Strengthen Software Metrics and Address Continued Cybersecurity and Reporting Gaps” (GAO-24-106912), Jan. 2024. https://www.gao.gov/products/gao-24-106912