Agile Contracts in Government: TechFAR and Beyond

The Contracting Problem

Government contracts have historically been structured around detailed requirements documents, fixed deliverables, and milestone-based payments. This model assumes you can define what you need upfront, build it, and deliver it. For complex IT systems, this assumption has proven catastrophically wrong time and again.

Agile development, by contrast, embraces uncertainty. Requirements emerge through iteration. Priorities shift based on user feedback. The final product may look quite different from the initial vision, and that is a feature, not a bug.

The tension between these two models has been one of the biggest barriers to Agile adoption in government. But the landscape is changing.

The TechFAR Handbook: A Foundation

The Digital Services Playbook and the TechFAR Handbook, published by the U.S. Digital Service and the Office of Federal Procurement Policy, provide explicit guidance for structuring Agile-friendly procurements within existing FAR regulations.

Key principles from TechFAR include the following.

Use statements of objectives (SOO) instead of statements of work (SOW). A SOO defines desired outcomes without prescribing how to achieve them. This gives Agile teams the flexibility to determine the best technical approach while still giving the government clear accountability for results.

Structure contracts around sprints and releases. Instead of traditional milestone payments tied to document deliverables, TechFAR recommends tying payments to working software delivered in sprint increments. This aligns contractor incentives with actual delivery.

Evaluate based on demonstrated capability. TechFAR encourages evaluation criteria that assess a vendor's ability to deliver working software, not just their ability to write proposals. Technical demonstrations, coding challenges, and past performance on Agile contracts carry more weight than volume of written response.

Contract Types That Support Agile

Time and Materials (T&M)

T&M contracts are the most natural fit for Agile work. The government pays for labor hours at negotiated rates, and the team delivers working software each sprint. The government maintains flexibility to reprioritize the backlog without formal contract modifications.

The downside: T&M contracts require active government oversight. Without an engaged product owner and contracting officer's representative (COR), there is no built-in mechanism to ensure value delivery.

Labor Hour

Similar to T&M but without materials. Common for staff augmentation contracts where the contractor provides Agile team members who work under government direction. This model works well when the government has strong internal Agile leadership.

Firm Fixed Price (FFP) per Sprint or Release

Some agencies structure FFP contracts around sprint deliverables. The contractor commits to delivering a defined number of sprints at a fixed price per sprint, with the government controlling the backlog and sprint goals. This provides cost certainty while preserving Agile flexibility.

The challenge: defining what constitutes a "completed sprint" in a way that is fair to both parties. Clear definitions of done and acceptance criteria are essential.

Hybrid Approaches

Many successful Agile contracts use hybrid structures. For example, a base period of T&M for initial development with FFP option periods for defined feature sets. Or a cost-plus contract with award fee tied to Agile delivery metrics (velocity trends, defect rates, user satisfaction).

Structuring the Backlog as a Contract Artifact

One of the most important adaptations for Agile contracts is treating the product backlog as a living contract artifact. This requires several elements.

A baseline backlog at award. The initial backlog, typically at the epic or feature level, serves as the basis for the contract's scope. This does not mean every story is defined upfront; it means the major capability areas are identified.

A change management process for the backlog. As the backlog evolves, changes above a defined threshold (new epics, significant reprioritization) should be documented and, if they affect cost or schedule, processed as contract modifications.

Velocity as a performance metric. The team's demonstrated velocity, measured in story points or throughput, becomes a key performance indicator. Sustained velocity declines may indicate problems that warrant government attention.

Quality Assurance and Acceptance

Traditional government contracts define acceptance through formal test events: System Integration Testing, User Acceptance Testing, and so forth. Agile contracts need a different approach.

Continuous acceptance. Working software demonstrated at each sprint review constitutes incremental acceptance. The government product owner accepts or rejects stories based on the definition of done.

Automated testing as a deliverable. Require contractors to deliver automated test suites alongside production code. This provides the government with ongoing verification capability and reduces reliance on manual testing events.

Definition of Done as a contract term. Include the team's Definition of Done in the contract or quality assurance surveillance plan (QASP). This creates an objective, shared standard for what "done" means.

Lessons from the Field

Start with a short base period. A 6 to 12 month base period with option years gives the government an early off-ramp if the team is not delivering. This reduces risk compared to multi-year firm commitments.

Invest in government product ownership. The single biggest predictor of Agile contract success is the quality of government product ownership. A skilled, empowered product owner who can make priority decisions and accept work is essential.

Do not over-specify in the RFP. The more prescriptive the requirements, the less room for Agile adaptation. Define outcomes and constraints, not implementation details.

Build in flexibility for team composition. Agile teams need the ability to adjust skill mix over time. Contract structures that lock in specific labor categories for the entire period of performance create friction.

EaseOrigin helps both government agencies and contractors structure and execute Agile-friendly contracts. We understand both the acquisition regulations and the delivery methodology, a combination that is essential for making Agile contracts work in practice.