Modifying Agile Contracts
Contract Modifications
Key Question: If system requirements are refined after the contract has been awarded, how can an agency ensure work was evaluated as part of the initial competition and is not considered an out of scope modification in violation of FAR 6.001(c)?
Contract scope is treated differently in Agile software development to permit teams to adapt to systemic and operational constraints, validated learning, and the real time feedback of users. To make sure all work during contract performance stays within scope, contracting professionals need only to link it to the Product Vision if one already exists, or to the high-level goals outlined in the requirements document. An example of one of these goals may be:
Goal: Increase the timeliness, accuracy, and completeness of data available to user group X.
Top Problems to Solve
- Ease of access: e.g., address existing problems where complex SQL queries and schema knowledge is required to pull case-related data; provision data that can be analyzed through tools shared across jurisdictions, such as SAS codes, R packages, or Tableau workbooks
- Timeliness: e.g., real-time access to the data in the system without affecting the application performance and reliability
- Completeness: e.g., flexible data storage, consume data from integrations, metadata; geocoding
- Flexibility: e.g., solve problems posed by missing data, data conflicts, new elements
- Accuracy: e.g., allow users to audit and clean data easily
The overarching goal is general enough to allow flexibility while also specific enough to be able to discern what is or isn’t out of scope within the context of the specific project and the system being modernized. As performance requirements are continuously refined after contract award, the sprints and releases that add incremental functionality to the end product must fall within that scope.
The FAR generally requires a new contract for any work that is considered beyond scope (e.g., a “cardinal change”). Under long-standing case law, a modification falls within the scope of the original procurement if potential offerors would have reasonably anticipated such a change prior to initial award. Contracts for agile software development can satisfy this precedent by ensuring that work identified during sprint and release planning can be linked back to the Product Vision and/or high-level goals as described in the requirements document.
To give offerors a “reasonable anticipation” of this linkage, contracting officers can make clear in their solicitations that Agile techniques will be used. This will alert offerors that creation and refinement of technical requirements will occur post-award using a highly-disciplined process of planning, testing and customer feedback. Furthermore, the Government should alert offerors to technical constraints (e.g., platforms) that may be applicable to the effort, and that software requirement changes are expected to be refined and managed as part of agile planning.
Language such as the following could be included in the requirements document that explicitly states that the Government expects that it’s understanding of the problem space will evolve as a result of the agile development process, and that priorities could potentially shift based on that evolution:
As is customary in agile development, priorities (as they relate to the modernization of ABC system) may shift over time based on the natural evolution of the Government’s and contractor’s understanding of the problem space through continued discovery, user research, stakeholder engagement, and validated learning. These shifting priorities will be accounted for through collaboration between the Government (Product Owner, agency stakeholders, etc.) and the contractor to establish a shared understanding of the work, which will be planned for and communicated through standard agile practices such as product roadmapping, backlog prioritization and sprint planning. For example, XYZ agency may decide during performance that additional functionalities for ABC system may need to be added to the roadmap/backlog due to newly emerging real-time circumstances, at which time the Government would work with the contractor to plan for and prioritize that work. This process will be managed by the ABC system product owner at XYZ agency and achieved through a regularly updated product roadmap/backlog process in conjunction with the contractor team.
As long as the newly emerging functionalities fall within the bounds of any of the high-level goals and/or the Product Vision outlined in the requirements document, it will be within scope.
Keeping Agile Work Within Scope
The mere fact that system requirements are refined to reflect the experience from completed iterations does not mean they are out of scope. However, contracting professionals should take measures to bind contract scope to guard against extraneous or non-useful features, performance delays, and budget depletion. Such measures include mutually agreed upon performance standards and a method for assessing work against these standards. Aligning the performance measurement with the Product Vision and/or defined project goals will help keep work within scope.
Service level agreements (SLA) may be used to specify the standards that working software must meet in order to be accepted by the government. This process is analogous to that used for performance-based acquisitions in FAR 37.6 where the Government issues a SOO defining its outcomes that allows for industry to provide innovative solutions that are measured under a quality assurance surveillance plan.
Generally speaking, the FAR requires that the Government must describe the general scope, nature, complexity and purpose of what it is acquiring so potential offers can make an informed decision as to whether they want to submit an offer. The scope should state broad goals and may also include functional areas. The Government should fix the schedule/timeframe in which the work is to be completed, so the contractor can propose the number of sprints and the work required in the sprints. If a baseline is available from prior similar work, the Government may be able to propose the set number of sprints to be completed in the schedule/timeframe.
To ensure that the prospective offerors understand the environment in which they may be working, the SOO should contain all applicable IT and environmental constraints as relevant context, including legacy software, privacy, and security requirements or policies that may impact the development of the software.