Agile Contracting Models for Government Software
The federal government spends roughly $95 billion on IT annually, and by the government's own accounting, the largest share of that goes toward keeping legacy systems alive rather than building anything new. The GAO has flagged federal IT as a high-risk area for decades. Cost overruns are routine. Schedules slip. Missions go unserved. And the estimated losses from unsuccessful federal IT projects run into the tens of billions of dollars. None of this is primarily a vendor competence problem or a budget problem. It is a contract structure problem. Fixing scope, price, and timeline simultaneously at contract award assumes knowledge no one actually has at that moment, and that assumption is what keeps producing the same failures at scale. Think of it like pouring a concrete foundation before the architect has finished the blueprints — except in federal IT, you also pay to jackhammer it up when the design changes.
What the performance data actually shows about agile vs. waterfall delivery
The Standish Group's 2024 Chaos Report puts agile project success rates at 64 percent versus 49 percent for waterfall. That gap widens considerably for large projects, where waterfall fails at roughly twice the rate of comparable agile efforts. The top causes of software project failure in that same data include unclear requirements, scope creep, inadequate planning, and communication breakdowns. All four are structural features of fixed-scope contracts. They are execution failures only in the surface sense. They are predictable outcomes of a model that demands precise answers before the questions are fully formed.
The cost data makes this worse. Median cost overruns for large IT projects run approximately 45 percent over original estimates, and for projects exceeding $15 million, average overruns exceed 66 percent. The "safe" fixed-price contract routinely ends up being the more expensive option, once change orders and re-scoping work their way through the system.
A 2024 study reported by The Register claimed agile had dramatically higher failure rates than waterfall. That finding deserves a direct response. Agile, when practiced correctly, is specifically designed to surface failing work earlier and terminate it at lower cost. A raw comparison of failure rates between methodologies is methodologically suspect when one approach treats early termination as a feature rather than a failure. Stopping a project in sprint three because it is not delivering value is not the same kind of failure as a three-year waterfall program that collapses at deployment. One is a fire drill; the other is the building burning down.
The honest read on agile is this: it does not guarantee success. What it does is change when and how failures are discovered. That shift is precisely what contract structure needs to accommodate.
Where FAR compliance and agile principles pull in opposite directions
The Federal Acquisition Regulation was built around a core assumption: requirements are knowable upfront, vendors compete on a fixed scope, and the government can evaluate at the end whether it received what it paid for. Agile assumes the opposite. The final design emerges through iteration and collaboration, not specification. These two frameworks are not naturally compatible.
Contracting officers gravitating toward fixed-price vehicles are making a defensible risk calculation given their institutional context, but the risk they are managing is often illusory. Change orders routinely drive final costs above the original fixed price. The rigidity that looks safe on paper absorbs all the uncertainty that was never actually designed out of the project. The GAO has documented the friction points explicitly: procurement practices that do not support iterative delivery, compliance reviews incompatible with sprint timeframes, federal reporting norms that do not map to incremental releases, agency customers who distrust partially completed systems, and program staff who cannot commit to the frequent input cycles agile requires.
Federal CIOs consistently identify acquisition processes as the primary obstacle to agile adoption, not technology, not contractor capability. The TechFAR Hub frames it well: a substantial majority of traditional projects surface significant problems late, and the government often ends up sharing overrun costs because the original specifications were wrong. The "safe" contract model transfers risk to the taxpayer anyway. It just delays the reckoning.
The goal here is not to circumvent the FAR. It is to use the flexibilities already encoded in it that most contracting officers have never applied.
Using Statements of Objectives instead of Statements of Work to open scope for iteration
A Statement of Work tells a vendor how to do something. A Statement of Objectives describes what outcome the agency needs. The distinction sounds semantic. It is not. It determines whether a vendor can adapt their methods as they learn, or whether they are locked into a prescribed approach that was designed before anyone understood the problem.
18F put this plainly: writing a SOW before you have diagnosed the problem is like telling a doctor what surgery you want before she has examined you. It forecloses the investigation that would actually produce the right answer.
The agile alternative is a high-level product vision that establishes scope boundaries, expected outcomes, and budgetary parameters. Requirements emerge from that vision through iteration rather than being enumerated at the start. This approach also accommodates design pivots based on user research and feedback, which a traditional SOW structurally cannot do. Once the scope is locked in the contract, learning has nowhere to go.
FAR Part 37.602, which governs performance-based service acquisitions, explicitly supports this shift. It describes agencies outlining overarching objectives, vendors proposing how to meet them, and quality being measured on outcomes rather than process compliance. This is not a workaround. It is the approach the regulation envisions for services where methods should not be prescribed.
The main contract types used for agile government software delivery and how each works
There is no single correct vehicle for agile government software. There are several, each suited to a different stage of program maturity and a different level of trust between agency and vendor.
Firm-fixed-price per sprint
This model structures contract line items by iteration rather than deliverable. The unit of purchase is the sprint cycle. Capacity is fixed; scope within that capacity remains flexible. Optional CLINs can accommodate work outside the baseline iteration. The risk here is that the FFP label creates institutional comfort that may not reflect actual flexibility. If the team treats sprint scope as immutable, you have recreated waterfall in two-week increments.
Time-and-materials and labor-hour contracts
18F defaults to T&M for early-stage agile programs. The government is buying developer time, not a defined product. That is more honest about what is actually being procured at contract award. It requires a spending ceiling and continuous measurement of software quality to work. Without those guardrails, T&M becomes an open-ended cost accumulation mechanism. With them, it is the most transparent vehicle for work whose shape is still emerging.
Points-based pricing
Deloitte has documented this approach: the agency and vendor agree on a fixed fee for a specified number of story points without prescribing what functionality those points must produce. Business stakeholders and the agile team prioritize work based on value, not the contract's deliverable list. This model separates budget commitment from scope commitment, which is exactly the separation agile needs. It requires an established relationship and shared velocity data to function. It is not a starting model.
Incentive and award-term contracts
FAR 16 provides several applicable mechanisms. Award-term extensions allow vendors to earn continued work through demonstrated performance. Sprint-level incentives can be tied to acceptance rates or release milestones. These structures create aligned incentives without requiring the government to define everything upfront.
Modular and IDIQ contracts
Breaking a large procurement into several shorter, lower-dollar contracts isolates failure. If one module underperforms, it does not contaminate the entire program. Each smaller contract is easier to oversee, easier to re-compete, and easier to terminate without catastrophic programmatic consequence. The architecture of the contract can and should mirror the architecture of the software.
Multiple-award contracts and Other Transaction Agreements have seen increased adoption as agencies seek faster on-ramps to iterative delivery. The sequencing logic Deloitte recommends tracks program maturity: start with T&M to build measurement capability, move to FFP per sprint as the team develops discipline, then progress to points-based pricing once velocity data and mutual trust are established.
The contract mechanisms that make iterative delivery governable: acceptance criteria, QASPs, and backlog ownership
The structure of the contract only produces agile outcomes if the governance mechanisms inside it are designed for iterative delivery. Three of these matter most.
The definition of done should be established at sprint start, not contract award. Working software that is packaged, tested, documented, independently verified, and deployable. The government evaluates delivery through software demonstration, not documentation. That shift alone changes the accountability relationship between agency and vendor.
The Quality Assurance Surveillance Plan should function as a continuous quality gate rather than a single end-of-contract acceptance event. 18F's standard is that at the end of each sprint, all code must be complete, tested, accessible, deployed, documented, and secure. Those criteria are aspirational only in name. They are the terms under which work is accepted or rejected.
The product backlog must be owned by the government. This is non-negotiable. The agency controls prioritization; the vendor executes against it. Government backlog ownership is the primary structural safeguard against contractor-driven scope creep and gold-plating. Ceding that control, even informally, is how programs drift from mission need toward vendor convenience.
The trap that consistently undermines agile governance is overlaying traditional project management reporting on sprint-based delivery. Gantt charts, milestone documentation, and phase-gate reviews satisfy compliance requirements while actively degrading the delivery model. It is governance theater, and it is widespread.
The FAR provisions that already permit agile acquisition without special waivers
FAR 39.1 explicitly calls for modular approaches and accepting responsible risk when acquiring information technology. This is not an interpretive stretch. It is stated policy. FAR Part 37.602 provides the regulatory foundation for outcome-focused procurement. Neither provision requires a waiver, a deviation, or special authorization.
The 2017 memo from USDS and OFPP established agile development as a standard commercial service acquirable under FAR 13.5 simplified procedures for contracts at or below $7 million. That memo was written specifically to open the door to innovative vendors that cannot compete on traditional contracts, which tend to favor incumbents with proposal-writing infrastructure over teams with actual delivery capability.
The practical consequence is significant. A substantial portion of agency software development projects fall at or below that threshold. They could be procured with dramatically less process overhead than most agencies currently apply. The barrier is not regulatory. It is the institutional habits GAO has documented repeatedly, combined with the risk aversion of contracting officers who have simply never seen these provisions applied.
What agencies that have moved to agile contracting have actually learned
18F's experience with modular contracting on complex systems has demonstrated one structural principle consistently: isolating failure in one module prevents cascade failure across the program. When the contract architecture mirrors the software architecture, a broken component can be removed and replaced without taking down everything adjacent to it. That is not a philosophical point. It is a practical safeguard that traditional monolithic contracts cannot provide.
CGI's analysis of failed FFP agile implementations points to the same root cause across cases: a mismatch between contract language and agile operating norms. Teams deliver iteratively while being held to waterfall acceptance standards. Disputes accumulate over what "done" means. The delivery model and the governance model are speaking different languages, and the project pays for the translation.
Customer trust is a recurring obstacle. Agency stakeholders who have been conditioned to expect a finished system at contract end are often resistant to incremental demonstrations. They interpret partial completion as inadequate delivery. Managing this expectation is as much a contracting challenge as a cultural one; the contract itself should establish what incremental delivery means and why it is the mechanism of accountability, not a hedge against it.
Staff availability is consistently underestimated. Agile requires frequent, substantive input from agency product owners. Agencies that cannot commit those staff hours to sprint reviews effectively convert the model back to waterfall, because the feedback loops that make agile adaptive stop functioning.
The agencies producing the best outcomes share one structural feature: a named, empowered government product owner with actual authority over backlog prioritization. Not a committee. Not a contracting officer serving as a surrogate. One person, accountable, available, and authorized to make decisions.
How to evaluate which contract model fits a specific agency program
The first question is program maturity. Has the agency done any agile delivery before? If not, T&M with a spending ceiling is lower-risk than FFP per sprint. It builds the measurement capability the agency needs before it starts fixing prices on iterations it has never managed before.
The second question is about size and modularity. Programs above a certain complexity threshold should be evaluated for modular breakup before any single contract vehicle is selected. The contract structure should reflect whether the software can actually be built in independent increments. If it cannot, that is a technical architecture problem that no contract type will solve.
The third question concerns the vendor relationship. Points-based pricing requires an established track record and shared velocity data. It is a mature-stage model. Using it at program inception is setting up both parties for a dispute over what the numbers mean.
The fourth question is about oversight capacity. If the agency cannot staff a government product owner with real availability and real authority, no contract type will produce agile outcomes. The contract model only works if the governance model supports it.
For programs under $7 million, the 2017 USDS memo created a specific path through FAR 13.5 simplified procedures. Most agencies have left it unused. They should pursue it.
The overarching test for any contract under consideration is this: does it allow the agency to act on what it learns during delivery, or does it lock in decisions that were made before delivery began? That question, more than any specific vehicle or mechanism, determines whether the procurement will actually serve the mission it was designed for.
