Agile Overview

What is Agile Software Development?

Key Question: Generally speaking, what is Agile software development, and how does it fit into the acquisition development lifecycle?

Agile software development is a method of software development that utilizes an iterative development process, designs services based on real user needs, and constantly improves software from user feedback. Agile software development principles apply to both pre-award and post-award contexts and require collaboration and communication between team members and end users..

It is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. The focus is on delivering work incrementally, incorporating user feedback into the design, and testing and delivering working software often. There are various Agile methodologies (DSDM, Scrum, XP, Kanban, etc.), which all adhere to the same values espoused in the Agile manifesto: individuals and interactions, working software, customer collaboration, and responding to change.

Per the Digital Services Playbook, Agile is the preferred methodology for software development contracts that create, update, or maintain digital services (e.g., websites, mobile applications, or other digital media). Agile supports frequent changes, updates, and enhancements to the software in accordance with a broad Product Vision and informed by testing, validated learning, and user feedback. The Product Vision is broken into small, manageable chunks called iterations that are maintained in a product roadmap. When all iterations are completed and accepted by the government, they deliver the desired functionality of the Product Vision.

By breaking up the development process into iterations, users receive software earlier in the development process, rather than in one “big bang” delivery at the end of the contract period. The testing, validated learning and user feedback that goes into the delivery of each iteration serves to confine the scope of the development effort, and generally does a better job of delivering useful working software that meets the functional requirements without wasting money and time on unused or unusable features.

The following chart compares traditional software development with Agile software development by describing the key events in the pre-award and post-award contexts.

Key Question: How Can Agencies Incorpoate Agile Principles?

First and foremost, when using Agile processes, the acquisition team must differentiate between functional requirements and technical requirements. Functional requirements describe what the digital service will do, or enable, for the end users. Technical requirements describe the development (e.g., coding, design, and engineering) tasks required by the contractor to deliver the functionality. In agile development, technical requirements are malleable and subject to change, but confined in scope by being tied to the functional requirements.

Agile software development starts with a Product Vision that describes the function of the digital service. It does not specify the exact technical requirements necessary to achieve the Product Vision. Instead, the contractor has the flexibility during contract performance to determine the best method for technical delivery, such as coding languages, application programming interfaces (APIs), and technology stacks in accordance with the parameters of the contract.

In agile development, contract deliverables are the functional, working software elements (deployable code) that are produced through each iteration of the product roadmap. Cost and schedule are adhered to because there is a set schedule of releases within that roadmap, during which the contractor must produce deployable code that satisfies an agreed upon “definition of done” for the functionality.

So, if your agency is ready to incorporate agile development into your digital service contracts, it is necessary to understand the differences between agile and traditional development. But more importantly, it is necessary to understand why it is different, and to appreciate how it will deliver more useful technology. While agile development is consistent with modular development described in FAR Part 39 and compliant with law and regulation, it does require a degree of culture change and a willingness to adopt new ways of thinking about information technology development.

A Typical Agile Process

The graphic below depicts a typical Agile process. With an Agile software development process, the Product Vision is used to create a product roadmap that organizes the strategic goals that will be achieved during the period of performance. Elements of the roadmap are then broken down into task-level details that are prioritized in the product backlog through the creation of user stories that describe the desired functions of the digital service. If you want to learn more, this article from ProductPlan provides a useful distinction between the product roadmap and product backlog.

Product backlog items are then used to develop technical requirements that are delivered through releases and sprints. The sprint backlog contains user stories that have been reviewed, scrubbed, and selected by the team to be worked on during a sprint. Sprints are commonly performed in 1 to 4 week cycles, and represent the time during which user stories are converted into either useful code or working software. Multiple sprints related to the same type of functionality are generally organized into releases of implementable and shippable code. While individual sprint artifacts are ready for production, they can also be bundled into a larger software release.

To increase the probability of a successful Agile software development, a focus on the entire acquisition lifecycle is critical specifically to past performance, past experience, and market research. Early vendor engagement, including conducting industry days and releasing Requests for Information (RFIs) and draft Requests for Proposal (RFPs) or draft Requests for Quotation (RFQ), is important for both the vendors and the Government. Early vendor engagement informs the vendor community about the Government’s desire to utilize Agile processes and provides an avenue for the vendors to ask questions to ensure they understand the process and what the Government is seeking to procure. The Government benefits by identifying vendors who are capable of supporting the specific software and have Agile software development experience.

A primary theme of Agile software development is the acceptance of change and flexibility in technical requirements development. Change and flexibility comes as agile teams gather feedback from users, accumulate validated learning through their development efforts, and test frequently to ensure that deployable code meets the definition of done. Therefore, it is imperative throughout the Agile process to give end users an opportunity to use the system or features to determine what works and what does not. This can be achieved through agile demonstrations (which can be working software or even wireframes and prototypes). When gaps are discovered between the product and its desired functionality, technical requirements can be updated to satisfy those gaps. This will allow the Government to benefit from the Agile process by continuously improving the technical requirements necessary to deliver the functional requirements and ultimately the Product Vision.

Key Question: Should Agile software development be used to address all IT needs?

No. Agile software development is intended for activities that require significant software design and development. Many IT needs can be met with commercial items and commoditized services, such as software-as-a-service or subscription licenses, and require little to no development work.

That said, Agile software development is very useful for certain digital services, especially those intended for use by the public (e.g., pilot IRS, healthcare.gov or recreation.gov). These types of services require significant user research and feedback, and rely upon the validated learning that agile software teams are able to achieve when working iteratively to create working digital functionality. As a rule of thumb, if the technical needs can be met with commercially available off-the-shelf items without configuration (e.g., customization), design, or development, there may be no need to apply Agile processes.

The Importance of the Agile Team

A key feature of Agile software development is the emphasis on the team approach. A cross-functional or Integrated Product Team (IPT) is integral to the success and administration of Agile software development contracts. The members of the agile team need to include key stakeholders from the program and acquisition office, and should be led by a program manager holding the appropriate level of Federal Acquisition Certification in Program/Project Management. It is essential that team members are champions for Agile, as the cultural change from traditional methods to Agile may be challenging.

To make this shift happen as seamlessly as possible, before conducting pre-award activities, the key members of the team should be familiar with Agile software development and open to learning new ways of thinking. Contracting officers and contracting officer’s representatives need not be trained as software developers, but should have a working knowledge of the concepts and processes associated with agile development. The United States Digital Service sponsors the Digital IT Acquisition Program (DITAP), a core-plus specialization for the 1102 job series, for contracting professionals who want to learn how to plan, award, and administer agile contracts.

Additional resources

• 18F Guide to Agile

  Use these Agile Principles to improve your knowledge.

• 18F Agile Lexicon

  Educate yourself on the Words & Terminology used in Agile Development.

• FAI Periodic Table of Acquisition Innovation

  Explore new approaches to support agile development contracts in FAIs Periodic Table of Acquisition Innovation.

Agency Readiness for Agile

Key Question: Are agencies authorized to shape their IT software acquisitions around Agile principles? The FAR does not expressly speak to Agile concepts such as refining technical solutions after contract award based on testing and customer feedback or buying a product with a process rather than an identified solution.

The FAR does not expressly speak to Agile concepts such as refining technical solutions after contract award based on testing and customer feedback or buying a product with a process rather than an identified solution. However, the principles of Agile software development are consistent with modular contracting, which is discussed in FAR Part 39, Acquisition of Information Technology, and specifically subsection 39.103 - Modular Contracting. In addition, as a general matter, an agency may pursue acquisition practices that are not expressly endorsed in the FAR, including Agile software development, as long as they are not expressly prohibited by law.

Although Part 39 does not directly speak to Agile software development practices, it endorses agile contracting principles where information technology systems are acquired in successive, interoperable increments to reduce overall risk and support rapid delivery of incremental new functionality. See our Policy & Guidance page for more information about agency authorization to use agile development. To determine whether your agency is prepared to shape their acquisition to enable agile software development, consider the shared goals below and then complete our Agency Maturity For Agile Assessment tool.

Shared Goals of Modular Contracting and Agile Software Development

1. Improvement in investment manageability and budgetary feasibility
2. Reduction of overall risk
3. Frequent delivery of usable capabilities that provide value to customers more rapidly
4. Increased flexibility
5. Creation of new opportunities for small businesses
6. Greater visibility into contractor performance

A number of agencies have used (or are in the process of adopting) Agile software development methodologies to improve investment manageability and reduce the time to value. As explained in this document, FAR authorities can be used to support IT projects that involve contractors performing in accordance with Agile principles. In some cases, these practices will require agencies to think beyond traditional approaches to more efficient ones, but ones that still reflect a commitment to the core values of public procurement, including competition, impartiality, accountability for results, and providing the best value to the taxpayer.

Agile is a methodology on how the contractor performs the work described in a non-prescriptive contract that allows for innovation and flexibility. The FAR specifically encourages agencies to pursue business process innovations and makes clear that they should not be constrained by the lack of specific endorsement for a particular practice. The strongest authorization for exploring agile methods comes from FAR subparagraph 1.102-4(e), which states that if a policy or procedure is not specifically addressed in the FAR nor prohibited by law, Executive Order or other regulation, agencies should not assume it is prohibited. It goes on to state that the “absence of direction should be interpreted as permitting the Team to innovate and use sound business judgment that is otherwise consistent with law and within the limits of their authority.”

Additional resources

• Agency Digital Service Maturity

  How "ready" is your agency for Agile? Take the Agile Maturity Assessment to find out!

• Foundations of Agile

  Watch these two pre-recorded webinars to improve your foundational Agile knowledge

• Overview of Agile Projects

  Read this Field Guide for An Overview of Agile Projects

Ethics & Conflicts of Interest

Under FAR 9.504, agencies are required to avoid, neutralize or mitigate significant potential conflicts of interest. FAR 9.505 addresses the underlying principle of preventing unfair competitive advantage for any given vendor. By having a close relationship with the contractor on the Agile team, is the Government inviting a conflict of interest?

The contractor's involvement on the Agile team is used only to help define software requirements in accordance with a highly defined and disciplined process that is driven by user needs established by the Government. There are certainly situations where a contractor working on one contract may create an OCI for another procurement, but the nature of the Agile methodology does not, per se, create a conflict of interest. Whether a conflict may exist depends on the specific circumstances of the acquisition; confer with your Office of General Counsel for specific guidance.

As explained earlier in this document, Agile software development involves a highly defined and disciplined process. A contractor being used in Agile software development to help refine technical requirements – a typical feature of Agile software development – would not be free to propose solutions to meet its own business interests over the Government’s interest. The contractor’s expertise is being used only to help refine technical requirements in accordance with a highly defined and disciplined process that is driven by user needs established by the Government. The needs are initially set forth in a Product Vision by the Government, which is supplemented through user stories and Government customer testing until an MVP is achieved. In other words, the contractor is not involved in establishing the Product Vision that frames the procurement, determining what overall contractual requirements are included in the solicitation, or determining if work products meet the contract terms. The Government retains the responsibility for making these decisions, including approving the specific plans and acceptance criteria for each iteration, as well as the overall plan revisions reflecting the feedback from completed iterations and priority changes. It is imperative that the Government retains this responsibility to ensure the integrity of the competitive process is upheld and is not overcome by the contractor trying to steer work to itself in the situation of a follow-on contract or a multiple award task order.

It is important to keep in mind that producing multiple releases of usable software is part of the Agile software development process. If a contractor has been awarded a contract for Agile software development, by nature, it will be involved in defining the technical or system requirements as it iterates through the Agile software development process. It will not have a conflict of interest in competing for follow on work because it should not be involved in developing the specific contract requirements or Product Vision for the follow-on RFP. It would have the normal advantage of the incumbency, which in itself, does not create a conflict of interest.

Additionally, FAR 9.505-3 applies in the respect that contracts for the evaluation of offers for products or services should not be awarded to a contractor that will evaluate its own offers, or those of a competitor, without proper safeguards to ensure objectivity.

As explained in FAR 9.505-2(a)(3), for development work, it is normal to select firms that have done the most advanced work in the field and would be expected to design and develop around their own prior knowledge. FAR 9.505-2(b)(1) allows a contractor to supply a system if it has participated in the development and design work. Given that the agency will be testing this software repeatedly throughout the development, it should already have the hardware on which it will be operating (or at least it will have already identified what hardware must be used). Consequently, even if there is a subsequent need to acquire a hardware system to run the software, the development of the software should not be considered preparing or assisting in preparing a work statement for the acquisition of the hardware system.

Next: The Agile Team