Contract Design

Describing Agile in Solicitations

When contracting professionals design solicitations, it is recommended to dedicate a section to explaining the Agile software development process. Doing so helps to alert industry, and specifically small businesses, that agile principles will be used rather than traditional software development methods.

In general terms, the agile development process is guided by the Product Owner’s high-level requirements as expressed in the Product Vision. The Product Owner works closely with the agile team as they conduct user research, develop user stories based on that research, and create acceptance criteria that help determine when certain increments of functionality have been achieved. During contract administration, the Agile team (which includes contracting and program personnel) conducts release planning to identify the major milestones on the product roadmap, and then sprint planning to break the releases down into the work needed to deliver outcomes.

In some cases, the product roadmap may have been developed already, however it should always be considered a living document to enable the Agile team to be flexible when issues or opportunities arise. As part of the Agile process, the Government will approve the specific plans for each iteration, establish the priorities, approve plan revisions reflecting the experience from completed iterations, and approve the working software to determine whether it meets the stated requirements.

The solicitation should also describe the required testing of functional requirements and make it clear that testing should be integrated into each sprint cycle. As a side note, if a contractor being considered for an Agile development effort does not identify a clear plan for testing and feedback incorporation, it is a bad sign that they do not truly understand Agile.

Below is an example of how a typical agile process could be written up in a solicitation.

Solicitation Description of an Agile Process

“The contractor will work in a team-based Agile environment. The Agency will create and maintain system roadmaps, project plans, and product and release backlogs that will be the basis for the contractor’s work. The Product Owner will specify high-level requirements to the Agile team. As in typical Scrum-based Agile processes, the Agency Product Owner will work together with the team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria will specify expected functionality for a user story, as well as any non-functional requirements that must be met in the development of the story. The Agency Product Owner, supported by SMEs and business analysts, will determine whether or not acceptance criteria have been satisfied.”

Firm Fixed Price vs. Time & Materials/Labor Hour

Because Agile software development is heavily process-driven, must agencies only use Firm-Fixed-Price (FFP) contracts to get the desired result?

The selection of a contract pricing structure for acquisitions using Agile software development is no different than those for any other contract. Contracts utilizing Agile software development are not limited to FFP arrangements; the CO is encouraged to select the pricing structure that will result in reasonable contractor risk and provide the contractor with the greatest incentive for efficient and economical performance.

The selection of a contract type for acquisitions using Agile software development is no different than those for any other contract. As with all contracts, there is not a one size fits all pricing structure that fits all contracts using the Agile software development methodology. FAR 16.103(a) states that selection of contract type requires exercise of sound judgment that will result in reasonable contractor risk and provide the contractor with the greatest incentive for efficient and economical performance.

In cases where requirements are easily identifiable, FFP contract types have the advantage of shifting risk to the contractor, which gives the contractor the maximum incentive to control costs and perform efficiently. FFP contract types have been used successfully for commercially available off-the-shelf item solutions or developmental services for software projects or increments where the Government knows the specific functional characteristics that will satisfy its objectives. A FFP model focusing on a fixed process and objectives can be highly effective by utilizing short option periods, such as 3-6 months, to ensure high levels of performance.

On the other hand, time-and-materials (T&M) or Labor-Hour contract types may be suitable if circumstances do not allow the agency to define its requirements sufficiently to allow for a FFP type contract and uncertainties involved in contract performance do not permit costs to be estimated with sufficient accuracy to use a FFP arrangement. See FAR 16.6 In these cases, forcing a FFP arrangement could force the contractor to build in unnecessary contingencies that would result in a higher price for the Government. It is important to take into account that contract types other than FFP may be delivered at a lower cost because the Government has more control over funding and development decisions. Additionally, a T&M or Labor-Hour contract type may be beneficial if an agency is using a blended team where one vendor has no direct or exclusive control over the outcome of the products.

Types of Agile Software Development Successfully Acquired

Agencies have used T&M or Labor-Hour contracts for Agile software development for:

• an integrated electronic benefit system
• a multi-faceted, complex integrated electronic medical record system
• a blended team where one vendor has no direct or exclusive control over the outcome of the products.

Agencies have used FFP contracts for Agile software development for:

• an electronic enterprise platform to maintain a centralized view of all communications, interactions, and outreach.
• design and deployment of an enterprise collaboration system using cloud-based applications.

Per FAR 16.103(c), an agency might consider hybrid contracts that allow the agency to achieve a better match between the requirement and how the work is priced. Work for which there is a basis for firm pricing could be awarded for a FFP while requirements for which there remains considerable uncertainty can be acquired on a T&M or Labor-Hour basis. IDIQ contracts can be structured as hybrid contracts to allow the agency to choose among the various pricing structures. Another example could be having a hybrid contract with FFP for the milestone releases and Labor Hour type line items for the sustainment. If the agency has a hybrid contract with T&M as a component, the agency is encouraged to move to FFP when pricing history is established and when the pace as an integrated team is set.

If other than FFP based approaches are used, such as those in FAR 16.3 cost-reimbursement contracting and FAR 16.6 T&M and Labor-Hour contracts, agencies ensure results by holding contractors accountable to the software sprint (iteration)/release schedule and by being involved in the Agile process.

Through highly disciplined time-boxed sprints (iterations), Agile forces agencies to manage risk by ensuring progress is continually monitored in real time, including with the direct involvement of end-users.

• Requirements are defined at the beginning of each sprint (iteration) – typically through “user stories,” or outcomes, that describe a feature or capability from the customer’s perspective. User stories can be as simple as, “As a user, I want to schedule an appointment online.”
• Some agencies use “Sprint Zero,” a preliminary sprint exclusively dedicated to preparing for the first sprint. The goal is to create a basic framework and baseline for the project so future sprints can add incremental value in an efficient way.
• Testing is an integral part of each sprint – from the outset of the project and the beginning of system development.
• Standard performance metrics should be used to measure cost and schedule performance and maximize contractor efficiency.

To ensure results, the Government must ensure that the “definition of done” is clear, comprehensive, and objective. This definition is established post-award at the beginning of each sprint. The contractor is considered to be “done” if working software has been produced that meets a set of criteria that the Government will use to evaluate a software demonstration of packaged, documented, tested, independently verified, and releasable. “Done” should ensure that the capacity of the application is such that all users are able to access and use it. To be considered successful, a contractor must also meet cost and schedule goals.

Agile practices bring to light projects likely to fail much sooner than traditional practices. Because of the small initial scale, this practice reduces the scope of failure and allows projects to take corrective action quickly, irrespective of whether the contract is FFP or cost-based. As a result, although a contractor will only be held to best efforts if a cost-based contract type is used, the Government’s exposure to major cost overruns will be significantly limited.

In fact, the Government’s exposure to risk under other than a FFP contract is arguably less than that under a FFP contract that follows the traditional methodology. History shows that the likelihood of significant problems being surfaced late in a traditional project is substantial – by some accounts at least 70 percent-- along with the likelihood that the Government will end up sharing, or paying for, the cost of the overrun because the initial specifications turn out to be faulty or otherwise inconsistent with what customers determine they ultimately need.

Structuring Firm-Fixed-Price (FFP) Contracts

When using a FFP contract, how could the contract line items be structured?

In a FFP contract, the line items may be structured by iterations (sprint cycles) with the unit of measure being the iteration. The Government may also use optional line items to account for additional work if needed.

For this sample line item, iterations are listed as “sprints,” but would be modified based on the type of Agile process being used. These scenarios are used to illustrate examples of how a contract may be structured, not dictate how it should be structured.

Scenario 1: New Task Order or New Contract- no known quantity of velocity/capacity of iterations is available. This method works well where a known budget amount is set and the program office needs to determine how much work effort translates.**

Firm-Fixed-Price Contract Period of Performance: Base Period [insert date of award through a set date]

Item No.	Supplies/Services	Quantity	Unit	Unit Price	Amount
0001	Baselining effort	100	day	$	$

Upon completion of the 100 day timeframe, Government and contractor shall mutually agree upon the team’s capacity/velocity. Note: decision making under the contract is the purview of the Contracting Officer. The contractor cannot make a decision about the nature of the contract requirements as that would be an inherently governmental function.

Deliverable

1. Implement proposed methodology (30 days)
2. Operate team under proposed method through several iterations (60 days)
3. Define and agree to mutually agreed sprint capacity (10 days)

Item No.	Supplies/Services	Quantity	Unit	Unit Price	Amount
0002	Sprints	TBD	sprint	$	NTE $500,000

Upon completion of line item 0001 – the final quantity of Sprints will be determined based on the agreed upon capacity and compared to the available budget remaining in order to determine how many Sprints could be awarded.

Scenario 2: Follow-on Effort or New Competition. This method works when the iteration has already been defined and agreed upon by the Government, whether this is through historical knowledge of a previous effort or through the solicitation requirements established in a competition.**

Period of Performance: Base Period = 12 months

Item No.	Supplies/Services	Quantity	Unit	Unit Price	Amount
0001	Sprint	15	Sprint	$	$

Each Sprint needs to be defined either by the Government or by the contractor in their proposal. The goal of each Sprint deliverable is to have working code that has undergone some process of testing and quality assurance. An example of a sprint deliverable could be spelled out as follows:

Sprint = Includes Analysis, design, development, testing, QA, documentation, and production of releasable code in a 3-week iteration. Estimation method uses Small, Medium, and Large scale for user stories (S, M, L being defined in solution).

Incentive Contracts

Key Question: Do incentives under FAR Part 16 work with contracts for Agile software development?

Yes, the Government is highly encouraged to use incentives in contracts for Agile software development, if appropriate, to motivate contractor performance.

FAR Part 16 describes different incentives that may be used in contracts to ensure the best results. Recently, Government agencies have had success with firm-fixed-price incentive contracts (FAR 16.204, 16.403), firm-fixed-price contracts with award fees (FAR 16.404), and performance incentives (FAR 16.402-2). See Appendix C: Sample Language for Government Contracts for Agile Software Development Services.

Examples of Performance Incentives

• Use award term contracts where the contractor earns an extension after the Government determines that the contractor’s performance is excellent (extension conditioned upon the Government’s continuing need for the service and the availability of funds).
• Provide incentives for completing all (or a certain percentage of) sprint cycles with 100% client acceptance, or tie incentives to minor or major releases.
• Use of firm-fixed-price incentive contracts (FAR 16.403) or firm-fixed-price contracts with award fee (FAR 16.404) may provide additional contractor incentives. With a firm-fixed-price incentive contract, capture 10% of the fixed fee in an incentive pool and distribute it when the contractor meets key milestones, pay the remaining 90% as a firm-fixed-price performance payment. Agency and contractor agree in advance to acceptance criteria, performance requirements, and metrics.

---

Agile Development Request for Quotation (RFQ) Sample

For an example of how to set up an RFQ for agile developing using a firm-fixed-price contract type, visit our Resources page and refer to Templates & Samples.

Additional resources

• Solicitation Development

  Use this Agile Software Development Solicitation Guide from 18F to support your contract design efforts.

• Solicitation Examples

  This is a GitHub Repository containing Solicitation Examples for Modular Contracting.

Next: Contract Vehicles for Agile