Welcome, everyone. I’m going to keep this to the point—very tactical, practical, and experience-based—focusing on helping a couple of government agencies in the United States improve their agile contracts.
I will cover a quick introduction to set the stage, discuss the challenges with current government contracts, and outline three key tweaks that can be made to improve them. Many of you may not know this statistic, but a staggering 41% of government contracts fail to deliver the full scope. The financial cost of this issue exceeds $7 billion.
Challenges with Traditional Government Contracts
The primary reason for this failure is that traditional government contracts focus heavily on defining requirements upfront. Significant time is spent detailing expectations, with success measured solely based on whether the contract was delivered on time and within budget. This outdated approach follows a waterfall process, creating numerous inefficiencies:
- Extensive upfront requirements gathering.
- Rigid financial structures that fail to adapt to changing needs.
- Top-down, bureaucratic governance with heavy gated procedures.
- Document-centric deliverables, often with little mention of software as an actual deliverable.
As a result, government agencies rely on lengthy, highly prescriptive statements of work (SOWs), often exceeding 100 pages, leaving little room for adaptability. The most common contract types include:
- Fixed-price contracts.
- Cost-reimbursement and cost-plus contracts.
- Time-and-materials contracts.
- Indefinite Delivery, Indefinite Quantity (IDIQ) contracts.
None of these contract types adequately address adaptability or focus on delivering actual value at a predictable pace.
The Solution: Three Key Tweaks for Agile Contracts
Based on our experience, we have identified three effective tweaks that significantly improve government contracts:
- Use a Statement of Outcomes instead of a Statement of Work.
- Provide a high-level product backlog and a clear definition of done.
- Structure contracts around buying a team for a fixed number of sprints or releases.
Additionally, two more tweaks can further improve these contracts:
- Explicitly designate an empowered product owner.
- Adopt a lightweight governance model.
1. Statement of Outcomes
Government contracts should shift from a Statement of Work (SOW), which focuses on deliverables (outputs), to a Statement of Outcomes, which focuses on expected value.
The U.S. government’s TechFAR document defines a Statement of Outcomes as including:
- Purpose.
- Scope.
- Period and place of performance.
- Background on the nature of the work.
- Clearly defined performance objectives.
- Operating constraints.
The benefits of a Statement of Outcomes include:
- Aligning scope and mission with product vision or Minimum Viable Product (MVP).
- Reflecting performance objectives in a healthy product backlog.
- Mapping operating constraints to non-functional requirements or a clear definition of done.
2. High-Level Product Backlog and Definition of Done
The government customer must define a desired product roadmap outlining high-level features and functionality. The backlog should be ranked by value, ensuring that stakeholders prioritize the most valuable features for end users. The contract should also include a definition of done that clearly specifies:
- What constitutes a potentially shippable product.
- Non-functional requirements.
- Acceptance criteria.
3. Fixed Team for a Fixed Number of Sprints
Instead of asking, “How much will it cost?” stakeholders should ask, “How much should we invest to achieve value?” This shift ensures that budgeting is driven by value delivery rather than arbitrary cost estimates.
The best approach is to define a fixed number of sprints within a set budget. By determining:
- The number of sprints required.
- The size of the Scrum team (typically 3 to 9 members).
- The budget needed to realize the highest-priority backlog items.
This method provides explicit upfront clarity on project duration and cost.
4. Empowered Product Owner
One of the biggest gaps in government contracts is the lack of an explicitly designated and empowered product owner. The product owner should:
- Represent the agency or customer.
- Work closely with Scrum teams and stakeholders.
- Ensure value is being delivered.
- Prioritize the backlog and determine release content.
5. Lightweight Governance
Many government agencies rely on heavy, bureaucratic gate reviews, which create friction and slow down agile delivery. Instead, agencies should adopt lightweight governance that:
- Inspects work incrementally rather than through rigid milestones.
- Eliminates unnecessary documentation requirements upfront.
- Focuses on delivering working software over producing extensive design documents.
Summary: Five Key Tweaks for Agile Government Contracts
To summarize, government agencies can improve agile contracts by:
- Replacing the Statement of Work with a Statement of Outcomes.
- Providing a high-level product backlog and a definition of done.
- Structuring contracts around buying a team for a fixed number of sprints.
- Explicitly designating an empowered product owner.
- Adopting lightweight governance.
By formalizing these elements in contracts, both government agencies and vendors can work within the same framework, ensuring that agile methods deliver maximum value as quickly as possible.
Thank you!