This is the first article in a 3-article series on integrating Agile methodologies within the context of the Federal Acquisition Regulation. This article focuses on the Requirements Development and Acquisition Planning phase of the acquisition lifecycle.
Far too often Federal Government digital service projects fall short of their goals for a variety of different reasons; one such explanation being a narrow interpretation of the Federal Acquisition Regulation (FAR). The TechFAR Handbook for Procuring Digital Services Using Agile Processes, has recently been developed to highlight the flexibilities of the Federal Acquisition Regulation; allowing agencies to improve the results of digital service projects through the use of Agile methodologies.
The TechFAR Handbook focuses on the aspects of the FAR that apply to digital service acquisitions. The purpose of the handbook is to correct any misconceptions that may discourage Federal Agencies from procurements that employ innovative digital service development. In particular, the handbook focuses on software development procurements and the use of Agile principles. For each stage of the acquisition process, the handbook includes information about important regulatory provisions and provides tips for the effective use of Agile approaches.
Are Agencies Authorized to Develop Acquisitions Based upon Agile?
Agile software development is a process characterized by frequent and incremental product releases that are generated in close collaboration with the customer.
An overarching concern exists as to whether Agencies are authorized to design acquisitions based upon Agile principles. The FAR does not specifically reference Agile concepts, however, in order to eliminate concerns, the TechFAR Handbook points out that Agile development methods are consistent with modular contracting as outlined in Part 39 of FAR. Modular contracting and Agile software development have a number of shared goals which include frequent delivery of usable capabilities, increased flexibility, reduction of risk and increased monitoring of contractor performance. It is important to remember that “Agile is not a method of procurement, but a methodology on how the contractor performs the work.”
While the method may be new, ultimately, the procurement itself maintains the necessary values of Government solicitations including: competition, accountability and selecting the best value to the public.
How to Begin: Requirements Development and Acquisition Planning
The FAR has provided guidance for performance-based service contracts for many years by specifying desired outcomes. Likewise, the handbook notes that a similar approach of developing a vision for the end result can be used to implement a contract with an Agile software development methodology.
Thorough acquisition planning is essential to the success of Agile software development. Priorities and requirements for the acquisition must be detailed in a product vision, which should be coupled with an explanation of how Agile processes will be used to accomplish the vision. The cross functional team, or Integrated Product Team (IPT), should define the project’s core capabilities. As with performance-based contracts, requirements may be stated within a Statement of Objectives (SOO).
In general, product visions should include:
Solicitations should explain the Agile software development process.The process will be guided by the requirements of the Product Owner, an Agency member who works closely with the team. The Agile Team and Product Owner will work together to establish acceptance criteria, and the Agile Team will develop multiple user stories to form the software release within the timeframe provided.
Testing requirements should also be included in solicitations. Testing must address all functional requirements and be integrated into each sprint cycle. The agency will approve the plan for each iteration, establish priorities, approve all revisions and ultimately approve the working software.
Will the Government Have Sufficient Documentation?
With Agile software development, ongoing interactions involving the contractor, stakeholders and Product Owner result in documentation which enhances and further defines the original product vision; documentation and software are generated concurrently. The evolving product definition is more refined than could have been possible at the outset, because it builds on the experience of previously completed sprint cycles.
While the Agency must oversee that all required documentation is generated, product documentation is generated as the product evolves. Documentation for user stories, acceptance criteria and “definition of done” acceptance criteria will support Agency requirements.
By integrating a product vision and description of Agile methodologies into the early phases of a procurement, Agencies can begin to take advantage of innovative, proven commercial methodologies.
In the next article, we will look at considerations for selecting a contract vehicle and creating the most appropriate contract pricing structure. To continue the discussion about how to use Agile in the context of the Federal Acquisition Regulation, contact us.