Agile: Procuring Development Support

Two men shaking hands

Procuring Agile Development Support: How to Structure Your Scope of Work

Profile iconMaeve Budi, Ben Dryer

In the federal government, successful agile software development begins with procurement practices that will support agile processes. The initial procurement can set up the program to embrace agile practices throughout the software development life cycle (SDLC).

Scoping the work

An important step in the procurement process is to create a scope of work to outline the tasks, outcomes, or objectives the government desires from the procurement. A flexible scope of work can lay the groundwork for agile support throughout the SDLC process, whereas a rigid scope of work could restrict the agile process and impede its success. CNA recommends incorporating flexible language into a performance work statement (PWS) or statement of objectives (SOO) to focus on the desired results and performance objectives without specifying how the results should be achieved. Performance work statements and statements of objectives are contrasted by statements of work (SOW), which rigidly outline the work requirements including deliverables, deadlines, and performance standards. Focusing on the desired results instead of a specific method to achieve results allows the contractor to propose novel solutions, whereas focusing on a specific method risks pigeonholing the contractor when a more effective method may exist.

Metrics burndown chart
PWSs outline the desired outcomes and performance objectives, allowing the contractor to determine how to achieve the results.
Metrics burndown chart
SOWs rigidly define work requirements, specifying what the end result will look like and how it will be achieved.
PWS: The Contractor shall ensure information that is considered sensitive or proprietary is not compromised...
SOW: The Contractor shall develop scripts to search logs for indicators of compromise...

Performance work statements and statements of objectives have also been recommended for use in agile solicitation materials by the TechFAR Handbook. Out of over 150 solicitations for agile software development the majority of solicitations were PWS or SOO, in line with recommendations (Figure 1). Further analysis of the scopes of work confirmed the PWSs allow greater flexibility than the SOWs, frequently providing general directives such as “shall ensure,” “shall include,” and “shall support,” which occurred more frequently on average across PWS than SOW sampled. The significance of this language is demonstrated in the examples on the left, pulled from two actual solicitations. In the PWS, the contractor is required to ensure the solution achieves the required performance—protecting sensitive or proprietary information in this example. This provides the contractor with flexibility, which may result in an improved solution. Conversely, the SOW outlines a specific method the contractor must develop (search log scripts) to protect information from compromise. For agile development, the flexibility of the PWS allows the contractor to propose products and pathways that meet the agency’s requirements while incorporating agile principles such as leveraging user feedback to drive a final product.

Pie chart describing prevalence of PWS, SOW, and SOO in agile solicitation materials: 67% PWS, SOW 29%, SOO 4%
Figure 1:Prevalence of PWS, SOW, and SOO usage in agile solicitation materials