Contracting for Agile Delivery: Modular Buys, SOOs and the TechFAR

Many agile transformations stall in the contracting office rather than the development team. A team may be ready to deliver every two weeks, but if its contract defines hundreds of fixed requirements, pays for documents at milestones and treats every change as a costly modification, the contract wins.

This guide is for leaders who buy software development, especially in government, where the Federal Acquisition Regulation (FAR) applies. It draws on the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506), the FAR itself and the TechFAR Hub. It explains the main tools available and what leaders should ask of their acquisition teams. It is not legal advice; your contracting officer and counsel make the final calls.

Why traditional contracts clash with agile delivery

GAO identifies ensuring that acquisition strategies and contract structures truly support agile programs as a challenge for federal agencies. It describes contracts with heavily structured tasks and performance checks that do not match a program's agile cadence, long timelines to award, costly change requests, and contracts that lack the flexibility to add staff or adapt from one release to the next.

GAO also notes that the FAR does not specifically discuss agile development, but does discuss contracting approaches that can benefit it. GAO quotes the FAR's guiding principle that the "absence of direction should be interpreted as permitting the Team to innovate and use sound business judgment" within the law and the limits of the team's authority.

For practical help, GAO points to the TechFAR Handbook, which highlights flexibilities in the FAR. According to the TechFAR Hub, the handbook launched in August 2014 alongside the Digital Services Playbook to help agencies apply the playbook's fifth play, "Structure budgets and contracts to support delivery." The Hub was designed to go further, with proven strategies, case studies, interactive tools and expert advice.

Modular contracting: buy in increments

The FAR defines modular contracting as the "use of one or more contracts to acquire information technology systems in successive, interoperable increments." The current FAR text says it is intended "to reduce program risk and to incentivize contractor performance while meeting the Government's need for timely access to rapidly changing technology," and that agencies should, to the maximum extent practicable, use it to acquire major IT systems.

The same section says a modular contract for IT should, to the maximum extent practicable, be awarded within 180 days after the solicitation is issued, with deliveries scheduled within 18 months after the solicitation. GAO adds that each increment should be able to perform its principal functions without depending on later increments, and that programs should avoid vendor lock-in by making sure deliverables are properly tested and documented so a new vendor could continue the work.

A note on timing: the FAR is being rewritten under the Revolutionary FAR Overhaul, which Acquisition.gov describes as the first-ever comprehensive overhaul of the FAR. Overhauled parts are being applied through agency deviations while formal rulemaking proceeds, so section numbers and wording are changing. In the overhauled Part 39 text, modular contracting appears as section 39.102 rather than 39.103 and says agencies should use it "to the maximum extent possible" for major IT systems. The overhauled Part 1 restates the innovation principle GAO quotes, in different words, in section 1.102. Check which version your agency is applying before citing a section.

Describe outcomes, not tasks

Because detailed requirements are not known at the start of an agile effort, GAO explains that a performance work statement or a statement of objectives can be used instead of a detailed statement of work. In GAO's comparison, a statement of work suits situations where the government has high confidence in the end state and expects minimal change; a statement of objectives suits situations where the end state is expected to evolve and change may be significant.

GAO says a statement of objectives "focuses on measuring outcomes, rather than on specific tasks." It recommends that solicitation documents include the product vision, strategic themes, an initial road map and an initial backlog, so offerors understand what is to be achieved rather than how it must be performed.

Choosing a contract type

A common misconception is that agile work must be firm-fixed-price, or must not be. The TechFAR Hub says agile development contracts "are not limited to FFP arrangements," and that selecting a pricing structure works the same way as for any other contract, citing the FAR's requirement that contract type selection result in reasonable contractor risk and the greatest incentive for efficient and economical performance.

The Hub describes options leaders should understand:

• Firm-fixed-price focused on a fixed process and objectives, with short option periods such as three to six months.
• Time-and-materials or labor-hour when requirements cannot be defined well enough for a fixed price.
• Hybrid contracts, for example fixed-price milestone releases with labor-hour line items for sustainment, moving toward fixed price once pricing history is established.

GAO adds a critical early decision: whether the government is buying end items, such as completed features, or services, such as the work of a specified number of developers. Contract type, vehicle and oversight data all flow from that choice.

Evaluating how vendors actually work

The TechFAR Hub suggests evaluating agile capability directly. Its ideas include oral presentations, technical factors that ask offerors for a performance work statement responding to the statement of objectives, a product development roadmap and a notional quality control plan, and past-experience criteria that may include a sample of code. It also flags a warning sign: a contractor that does not identify a clear plan for testing and feedback.

On scope, the Hub explains that refining requirements after award does not by itself make work out of scope, as long as releases fall within the scope of the product vision described in the statement of work and offerors were given reasonable notice that agile techniques would be used.

Oversight that matches the cadence

GAO recommends tailoring contract data requirements to agile metrics, since the primary deliverable is working code rather than milestone documents, and aligning oversight reviews with the program's cadence, for example by replacing traditional design review gates with incremental reviews. It also recommends training program office, acquisition and contracting staff, and identifying clear roles for contract oversight.

GAO offers sample retrospective questions for oversight, including:

• When was the last time the program delivered working software to the customer?
• Does the program build a minimum viable product?
• What impediments can the sponsor help remove?
• Is the customer satisfied with the results?

It also warns about self-reported metrics: velocity is not comparable from team to team and can be raised by inflating story point estimates.

GAO's guide describes lessons from GSA's 18F office, which in 2015 tested an Agile blanket purchase agreement. Based on that experience, 18F warned against pre-establishing vendor pools of long duration without the ability to add or remove vendors, which could stagnate competition.

Although these sources are written for federal buyers, the same questions are worth asking in any organization that contracts for software: are we buying increments we can stop after, describing outcomes rather than tasks, and reviewing working software rather than paperwork?

Key takeaways

• Contract structure can block agile delivery even when teams are ready; involve acquisition staff early.
• Modular contracting buys IT in successive, interoperable increments; the FAR is being overhauled, so confirm current section numbers.
• Statements of objectives describe outcomes and leave room for requirements to evolve within the product vision.
• Agile work is not limited to one contract type; fixed-price, labor-hour and hybrid structures all appear in TechFAR guidance.
• Align oversight with the delivery cadence, and judge vendors on working software, not self-reported velocity.

Sources

• U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (reissued with revisions December 15, 2023)
• Acquisition.gov, Federal Acquisition Regulation Part 39, Acquisition of Information Technology
• Acquisition.gov, FAR Overhaul, Part 39
• Acquisition.gov, FAR Overhaul, Part 1
• Acquisition.gov, Revolutionary FAR Overhaul
• U.S. DOGE Service, TechFAR Hub: Contract Design
• U.S. DOGE Service, TechFAR Hub: Technical Evaluation
• U.S. DOGE Service, TechFAR Hub: History of the TechFAR Hub