Agile Software Development in Federal Contracts: What Contractors Need to Know

The federal government's adoption of agile software development has transformed how IT contracts are structured, procured, and evaluated. After years of costly waterfall development projects that delivered late, over budget, and with obsolete capabilities, OMB, DoD, and civilian agencies have mandated agile delivery for most new software development programs.

For software development contractors, understanding how the government structures and evaluates agile delivery is essential to winning and performing federal IT contracts.

---

Why the Government Shifted to Agile

The HealthCare.gov failure in 2013 was the catalyst that accelerated the federal agile movement. The multi-billion dollar waterfall development project launched poorly and required emergency remediation. The failure made headlines and prompted deep examination of how the government buys software.

The U.S. Digital Service (USDS) and 18F were established in 2014–2015 to bring modern software practices (agile, open source, user research, continuous deployment) into federal agencies. Their playbooks and guides now influence how most federal agencies write IT solicitations.

Key policy drivers for agile:

• OMB Memo M-16-21: Federal Source Code Policy (encourages open source, iterative development)
• USDS Digital Services Playbook: 13 plays for building effective digital services
• DoD Instruction 5000.87: Software Acquisition Pathway — the DoD's official agile software acquisition framework
• OMB DCOI (Data Center Optimization Initiative): Drives cloud migration and modern software practices

---

How Agile Is Implemented in Federal Contracts

Time and Materials (T&M) Contracts

The most common contract type for agile development. T&M contracts pay contractors for hours worked at defined labor category rates, rather than for specific deliverables. This aligns with agile's iterative nature — the exact features to be built in Sprint 37 cannot be specified at contract award.

T&M contracts under FAR 16.601 require:

• Defined labor categories with ceiling rates
• Not-to-exceed (NTE) ceiling on total contract value
• Government oversight of hours and labor mix

The government's concern with T&M: without deliverable-based accountability, cost control depends on government program management. Many agencies now combine T&M with sprint-based performance metrics.

Agile Task Orders on IDIQ Vehicles

The most common structure for larger agile programs. The agency holds an IDIQ vehicle (OASIS+, CIO-SP4, agency-specific MACC) and issues task orders for specific agile development efforts. Task orders can be T&M, FFP, or hybrids.

Firm-Fixed-Price Agile (Sprint-Based FFP)

Some agencies structure agile contracts as FFP with deliverables defined as approved sprint outcomes — functioning software delivered at the end of each sprint. The government accepts (or rejects) each sprint's output, and payment is tied to sprint acceptance.

This is complex to execute because sprint scope cannot be fully defined at contract award. Well-designed FFP agile contracts define outcome-based acceptance criteria rather than feature-specific requirements.

---

Agile Terminology in Federal Solicitations

Federal solicitations for agile programs use specific terminology you need to understand to write credible proposals:

Product Owner: Government role (usually a program manager) who defines and prioritizes the product backlog. The Product Owner accepts or rejects sprint deliverables.

Product Backlog: Prioritized list of user stories describing features and capabilities to be developed. The backlog evolves throughout the contract.

Sprint/Iteration: Time-boxed development period (typically 2 weeks). Each sprint produces a potentially shippable increment of software.

Sprint Review: End-of-sprint demo where the team demonstrates completed user stories to the Product Owner and stakeholders.

Retrospective: End-of-sprint team meeting to assess process and identify improvements.

Velocity: The team's average rate of completing work (measured in story points per sprint). Used for planning and forecasting.

Continuous Integration/Continuous Deployment (CI/CD): Automated testing and deployment pipelines that enable frequent, reliable code releases.

DevSecOps: Development, Security, and Operations — the integrated practice of embedding security into the development and operations pipeline from the beginning.

---

Proposing on Federal Agile Solicitations

Technical Approach for Agile Proposals

Federal agile proposals typically require you to describe:

Agile Methodology: Which specific agile framework? Scrum, SAFe (Scaled Agile Framework), Kanban, LeSS? For large DoD programs, SAFe is most commonly requested. Explain not just the framework but how you adapt it for federal constraints.

Team Composition: Agile teams require specific roles — Scrum Master, Product Owner interface, developers, UX researchers, QA/test engineers, DevSecOps engineers. Demonstrate you can staff the full-stack team.

Sprint Cadence and Ceremonies: Describe your sprint length, planning approach, daily stand-up format, review process, and retrospective approach. Be specific — government evaluators are increasingly sophisticated about agile practices.

Definition of Done: How do you define when a user story is complete? What testing, documentation, and review requirements must be met? A clear "definition of done" shows agile maturity.

CI/CD Pipeline: Describe your automated testing and deployment approach. Federal programs increasingly require automated security testing (SAST, DAST) in the CI/CD pipeline.

Metrics and Reporting: How will you report velocity, burndown, defect rates, and other metrics? Government program offices need visibility into agile progress.

Past Performance for Agile Proposals

Past performance on agile federal contracts is evaluated differently than traditional projects. Highlight:

• Sprint velocity and consistency over multi-year engagements
• Number of user stories delivered over the contract
• Change in velocity over time (demonstrating team maturity)
• Zero-downtime deployment success rates
• User satisfaction metrics if available

---

Government-Furnished Tools and Access

Federal agile programs often involve specific government-mandated tools:

Jira/Confluence: Many federal programs require Atlassian toolsets for backlog management.

GitLab/GitHub Enterprise: Source code repositories. Many DoD programs use GitLab running in IL4 or IL5 classified environments.

Microsoft Azure DevOps: Widely used in civilian agencies.

DISA-approved cloud environments: DoD software must run in DoD Impact Level (IL) environments — IL2, IL4, IL5, or IL6 depending on data sensitivity.

Ensure your proposed team is familiar with government-mandated tools before promising capabilities in your proposal.

---

Digital Service Acquisition Resources

For solicitations based on 18F or USDS practices, review:

• 18F De-risking Guide (available on GitHub): Explains how modern digital service procurement works
• USDS Digital Services Playbook: The 13 plays underlying most federal digital service programs
• TechFAR Hub: OMB guidance on using FAR authorities to enable agile procurement

Understanding the underlying philosophy of digital service acquisition makes your proposals more credible and your performance more effective.

---

Key Takeaways

• Agile software development is now the federal standard for new software programs — driven by OMB, DoD Software Acquisition Pathway, and USDS/18F influence.
• T&M is the most common contract type for agile development; sprint-based FFP is growing for outcome-oriented agencies.
• SAFe (Scaled Agile Framework) is the most commonly required methodology for large DoD programs; Scrum is standard for smaller programs.
• CI/CD and DevSecOps are expected capabilities — not differentiators — in federal software development proposals.
• Agile proposals must be specific about methodology, team composition, sprint cadence, definition of done, and metrics — generic agile descriptions fail.
• IL environment compatibility is a DoD requirement — ensure your team is familiar with DISA cloud environments and their tooling restrictions.

Find federal IT and software development opportunities on RFxNerd →