Creating Incentivized Agile Contracts

 J. Timothy Freihofer, David Dotson, and Rhonda Maus

Changes are under way in how the Department of Defense (DoD) and the federal government in general develop, buy, and employ technology. The acquisition workforce, policies, procedures, and vendors all need to keep up with the changes. There has been a lot of talk about “Agile.” What is it? Are new procurement methods and strategies required to implement Agile?

This article focuses on the kind of thinking that will allow the contracting officer to make use of the many excellent crosswalk references between the Agile terms and available acquisition flexibilities. Traditional procurement methods for product delivery, or waterfall software implementations, lack the flexibility to take advantage of the benefits of time, schedule, and cost that Agile potentially brings to acquisition process. For this reason, DoD must look to Agile methodology, using innovative and creative acquisition planning solutions to procure products and services while maintaining compliance with the Federal Acquisition Regulation (FAR), Defense Federal Acquisition Regulation Supplement (DFARS), Service regulations, and other related federal law. This article looks at the indefinite delivery (ID) contract formulation, and formulations to incentivize Agile behaviors using Firm-Fixed Price (FFP) task orders, as examples of applying current contracting flexibilities to enable the development of Agile contracts.

To help meet the challenge ahead, acquisition professionals may choose a new way to look at the venerable statement of work (SOW) for the ID contract. That SOW is a written description of what life will be like once the product is delivered.

Just like a novel, there are smaller stories within the SOW, stories describing each character, event, and location. These lists of stories describe and contribute to the complete novel similar to the way stories about how each feature in a product or software will contribute to how the final products fulfilling the expectations after delivery. The novel is the SOW or performance work statement (PWS) in the ID contract. The details of the SOW or PWS at the ID contract level describe the negotiated Agile processes, ceremonies, artifacts, roles, and responsibilities.

The contractor and contracting officer develop the individual stories using the ID contract’s processes and execute the stories with the task orders. The contracting officer must negotiate and document the processes for writing those stories. That is the paradigm shift! Yes, we are ultimately buying a function or service. To get there we are practically buying a process of incrementally describing and executing the steps it takes to arrive at the final function.

To make Agile work, we must contract for Agile work processes and trust the successful outcome to diligent execution of those processes. We must select contractors with proven ability to exercise a process, repeatedly, until they deliver the final functionality. Repeating the process through frequent interim milestones means that adjustments can be made for subsequent milestones without requiring the major contract modifications that would be needed by traditional methods.

The new kind of thinking starts with a vison of the completed product functionality. This includes a description of the processes that will develop the described functionality in the ID contract. Task orders apply the ID contract processes to develop incremental stages and arrive at full functionality. Agile software development and acquisition procedures use this incremental thinking about an entire acquisition process to delivered product.

Software developers, including Jeff Sutherland and Kent Beck, wrote the Agile Manifesto in 2001. Are 20-year-old core values still relevant? Do they have application beyond software development? The manifesto relies on four core values. These values prioritize individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Thinking of the product delivered as a service may help in understanding how Agile operates.

“Agile is not a method of procurement, but a framework based on a set of principles: Agile is based on values and principles that encourage frequent delivery of working solutions to users in order to gain fast feedback and enable continuous learning that is supported by a culture of collaboration.”

 

—Ellen Lord, former Under Secretary of Defensefor Acquisition and Sustainment, Nov. 18, 2019.

The foundational structure of an Agile program includes:

• Release. Capability delivered to users, composed of multiple sprints.
• Sprint. Priority capabilities developed, integrated, tested, and demonstrated in an iteration.
• Daily Scrum. Team synchronization meeting to plan activities and assess progress and impediments.
• Sprint Review. Demonstrate working product to the stakeholders and end users.

This repetitive process focuses on what the risks are, how they are mitigated, and also in the end, what value and success look like.
How could indefinite delivery contract formulations allow necessary flexibilities?

Agile requires the flexibility to change the description of “acceptable product” as the product is developing. This flexibility already exists in the FAR. We do not advocate waiting for a magical, yet-to-be-developed, flexibility that will suddenly make Agile contracting a matter of fill-in-the-blank in an approved template. Such a regulatory rescue will not happen because: (a) The necessary flexibilities exist and are here, now, in the FAR, and (b) Creating new regulation at the FAR level takes a long time … time we really cannot afford.

Agile works because there is frequent and early adjustment to requirements during product development. The example of new thinking at the beginning of this article highlighted the ID contract type. FAR subpart 16.5 presents ID contracts, which allow contracting officers to issue orders against the base contract during a defined ordering period. To make Agile work, we need a contract type that contemplates how requirements can evolve without driving a mountain of administrative effort and cost historically associated with modifying the contract to change the requirement.

Implementing Agile with task orders under the ID contract helps projects achieve success in three ways. First, from an organizational perspective, Agile helps reduce costs and increase the value of the product delivered and thus increase the return on investment. Second, Agile’s emphasis on shorter delivery cycles allows teams to identify risk early in the project and, if need be, cancel the project or process before too much money is spent. Third, Agile emphasizes delivering the most valuable features first. Even if development teams cannot complete 100 percent of the features, at least the organization benefits from functionality headed toward the full product goal.

Agile welcomes change in requirements at any point in the project. So if conditions change, and they always do, Agile teams can adapt accordingly. From a technical standpoint, Agile emphasizes the importance of quality in terms of reliability and adaptability Quality is achieved through such practices as continuous integration—with 100 percent completion and acceptance of each feature before moving on to the next one.

A key difference between Agile and the more traditional waterfall thinking about requirements is that traditional thinking assumes complete requirements can be established up front and should not change as work progresses. Agile takes the opposite approach. An Agile project begins with the development of a product or project vision—the novel in our opening example.

In other words, Agile begins with the end in mind. The vision usually includes the desired goals and expected benefits. Product owners—managers given authority to make decisions regarding what is an acceptable product at the working level—translate the vision into a product or project backlog.

Product owners document the project backlog in rough outline or in the form of user stories. User stories, an Agile term, are precise, just-in-time, small technical requirements. Stories include measurable or tangible technical acceptance criteria. Product owners package user stories in short-cycle deliverables. Agile calls the short work cycles “sprints.” Product owners prioritize user stories by relative cost and benefit. When a sprint cycle begins, product owners meet with the sprint team to look at the product backlog and decide how much the sprint team will take on for that sprint cycle. While the Agile team works the sprint cycle, product owners update the plan. At the end of the sprint cycle, product owners review the work accomplished with the sprint team. During this review, the product owners and customer representatives go through the acceptance criteria defined for the cycle, and then sign off on whether the feature is fully complete.

Completed user stories free up sprint team capacity to work on more or new features during the next cycle. Sprint cycles continue until such a point product owners determine the project is completed. Ideally, the goal at the end of each sprint is to deliver the product, or a portion of it, in a condition that is releasable to users. Breaking down major milestones into shorter events allows teams to build success, catch issues early, fix, and continue working.

Courage is needed to embrace such a culture of collaboration. We must let go of the idea that minutely spelling out, within the four corners of the contract, exactly what “shall be delivered,” is the only path to reasonably assured contracting outcomes. Certainly, given enough time and funding, we can continue to specify and the contractor can continue performing, waiting until the final delivery to determine if the effort produces the desired results. We need a faster way to develop and acquire leading-edge technologies. We need a business process that identifies adjustments early and implements them without needing to alter the entire contract with each one. We need to adapt our thinking to see how we can implement Agile with the tools we now have at our disposal.

The following is another approach to describing the change in thought necessary to implement Agile. ID contracts provide contractual flexibilities to shift the Agile development team’s focus to the next user story as that particular story becomes important. This elevation in importance of the user story can happen, for instance, when the threat changes or the operators find a problem with the system.

Through task orders, the ID contract allows quick change of work focus as details of the changed requirement emerge. The most important aspect here is the value obtained by the work accomplished in functionally delivering the user stories to end users. Documentation is still a very important part of these contracts, although it looks a little bit different from requiring management plans upfront and work breakdown structures. It becomes user stories, design documents, and continuous updates.

Agile requires more technical oversight, not less. Agile contracts require more descriptions of what the detailed technical requirements will deliver. Smaller increments of work would be technically described serially rather than all at once in the beginning. Stated differently, the contract requirement is for a series of deliverables providing end-user useful functionality on their own that, combined, result in the complete satisfaction of desired end item function. This is different from fixed interim deliverable items.

The key is to review the output of short periods of performance and determine what needs to change during the next work period to reach the goal. The contract requirements are expressed in terms of sprint iterations.

How many iterations will be required in a period of performance, what do the iterations consist of, and what is the process by which those items are reviewed and approved on a regular basis? The collaboration and dialog are different and are very important. Each story under a task order is the object of the process. The contractor applies the agreed-upon process, and both contractor and government consider the results and adjust the next story under the next sprint. Here is the agility. Here is the ability to make corrections while on the path to the goal. FAR subpart 16.5, Indefinite-Delivery provides this flexibility.

Agile requires more technical oversight, not less.

How Could We Incentivize an Agile Contract?

Consider incentivizing what we most want: consistency and repeatability of the development process applied to the tasks and backlogs under each task order. The desired repeatability is the productive output generated by the sprint team. The Agile discipline has metrics for this. Incentivize consistency in those metrics over time. Agile uses the term “velocity” to describe the stable rate at which a development team should be able to produce indefinitely. Velocity is particular to each team. It is not realistic to compare one team’s velocity to another team’s velocity because they are different teams of different individuals with different skills. Development team staffing is the key to stable velocity for that team. The contractor should have incentives for taking actions necessary to keep teams together, focused, and producing at their optimum velocity.

When thinking about a contractor exercising a process repeatedly, each time in the same way, what do we want to incentivize? Repeatability and consistency. Consistently repeatable processes do not have much cost variation. Cost reduction requires subtraction of something from that process. The contractor may subtract time, people, or materials to cut cost. How will the process remain stable if we encourage constant reduction to the process parts? Clearly, common cost incentives pull the rope in the wrong direction. We want stasis, not reduction. Cost stasis denotes a mature process.

Cost reimbursement contracts may not accomplish our goal. In order to incentivize a performance metric on a cost-reimbursement contract, the contracting officer must first incentivize cost control. This would potentially work against our objectives of repeatability and consistency. Cost incentives could encourage the very behaviors detrimental to consistent staffing and constant velocity.

If stability remains constant, the value increases.

Classic Agile software development processes work best with a stable team of seven to nine multi-skilled code writers. The team performs their work in two-week sprints. The longer the team works together, the better it works together. The stable sprint team soon will reach an indefinitely sustainable development tempo. It seems that the contractor could very accurately estimate the fixed price of having that team labor for two-week sprints at a time. This is a fixed price.

A team is contacted to do work using the agreed-upon process for two weeks, and then the outcome is evaluated shortly after the two weeks. The next task order presents the team with a new story or maybe an adjustment to the story from the last task order. Agile calls this process, “sprint planning,” a collaborative effort between the government and the contractor at the start of each sprint iteration. The next task order is for the same team, same duration, but with an appropriately adjusted story generated during sprint planning. Our goal is to hold the teams and their function as a constant (i.e., FFP) and vary the tasks through the stories presented to the team.

Using Escalation Tables on FFP Task Orders

Incentivize the contractor to deliver a stable velocity from a stable team—perhaps a value scale indexed to the longevity of the stable velocity and the longevity of stability in team staffing. Alternatively, a formula blending both values could be used. Negotiate a base fixed price for teams staffed according to full-time equivalent and labor rates, and then escalate that fixed price the longer the contractor holds those two metrics constant. For example, negotiations value a new team at $100,000 for the two weeks. If, after three sprints, the team demonstrates constant staffing and a stable velocity, that same team is now worth $110,000 for the next task order. A negotiated arrangement such as this certainly is possible.

Incentives work in both directions (FAR 16.401(a)(2)). If stability remains constant, the value increases. If stability fluctuates, up or down, the team’s value under the contract decreases. Scaling to workload happens by adding or subtracting stable teams with stable velocity. This approach incentivizes objective Agile metrics without the administrative burden of calculating cost incentive outcomes.

There is tremendous flexibility open to contracting teams…

Agile Data Item Descriptions (From ACCESS Database) as Roadmaps

This article has described a way of thinking about Agile contracting and incentives. There is tremendous flexibility open to contracting teams concerning implementing language. There is much literature available on specific contract language, providing detailed examples. Rhonda Maus (DAU, Mid-Atlantic Region) developed lists of Agile resources for acquisition professionals as part of DAU’s ACQ 1700 Agile for DoD Acquisition Team Members class. ACQ 1700 is an integral part of the DAU Agile: DoD Team Member Credential (https://www.dau.edu/training/pages/credentials.aspx)

There is ample information out there regarding Agile. This begs the question, “Why does Agile software development seem so difficult to execute within the DoD?” Others have asked the same or similar questions—for example, a report by the Government Accountability Office, GAO-20-439, and a June 16, 2020, article in FEDSCOOP.

Sometimes a format or template helps lead the way. Of all the templates out there, the most frequent challenge involves where to begin negotiations on such a complex requirement as an Agile development process. We suggest repurposing the data item descriptions (DIDs) already in the ASSIST database (https://quicksearch.dla.mil/qsSearch.aspx) for use as a negotiation checklist. There are four Agile-related DIDs. The thinking here is that, if the DID provides enough of a list for developing an appropriate contract data requirements list (CDRL), it is probably good enough to use as a list of items to negotiate for the contract.

In summary, using current contracting tools to build responsive technology and software acquisition strategies requires new thinking. Relevant law, regulatory guidance, and process information already exist and are available for immediate use. We need to increase our ability to understand, define, and communicate what end state the user needs. Senior leaders will need to give project managers and contractor teams a flexible contract—and believe and trust that they can deliver the required system. The basic tenet of Agile is trust between the government and the contractor.

Agile works in an environment of trust where every team member contributes and understands roles and responsibilities. Everyone from the executive level to the production floor level will need to understand the Agile process. How does Agile deliver value? What is my contribution? Why is Agile so different from what has been done in the past? Acquisition professionals must understand the answers to these questions in order to adopt the thinking necessary to make Agile work.

Only with new thinking will leaders empower government project owners and contracting officer’s representatives (CORs) with decision-making authority. Project owners and CORs need explicit authority, bound by appropriate contract language, to make day-to-day decisions on priorities without having to run through miles of review that can delay decision making. Vesting decision-making authority at the working level contributes to Agile’s success. Acquisition executives must constantly advocate for empowering the team at the working level to remove roadblocks and get projects delivered. This is the new thinking needed to keep up with the speed of change in our world today. 

Sample Excerpt

Data Item Description

Title: Software Development Process Description Document (SDPDD) Number: DI-IPSC-82208 Approval Date: April 17, 2018

b. If the software/programmable logic development process is an Agile process, the following must be addressed within this section or subsection(s):

1. Cite the Agile technique(s) being employed (Scrum, pair programming, extreme programming, etc.).
2. For each Agile technique employed, describe your approach.
3. Describe the approach for release planning.
4. For Scrum, identify the sprint length and how it was determined.
5. Describe how the backlog is initially established, and the process for modifying and re-prioritizing it.
6. For Scrum, describe the typical sprint activities, and what happens during each iteration.
7. Identify the Product Owner and his/her roles/responsibilities.
8. Describe the acquirer’s role in the sprints if the customer is not also the Product Owner.
9. Describe the mechanism for getting acquirer (or end user) feedback for each sprint.

Read the full issue of
Defense Acquisition magazine

FREIHOFER is a DAU professor of Contract Management in Norfolk, Virginia. He is a retired Navy captain with extensive experience in Joint operations, military logistics and systems command, inventory control point, and operational contracting.

DOTSON is a professor of Contract Management at DAU in California, Maryland, with experience doing contracts as a Department of Defense contracting officer and in heavy manufacturing industry.

MAUS is a DAU professor of Software Engineering in California, Maryland, and has extensive professional software experience with Agile, contracting, engineering and program management.

The authors can be contacted at [email protected], [email protected], and [email protected].

The views expressed in this article are those of the author alone and not the Department of Defense. Reproduction or reposting of articles from Defense Acquisition magazine should credit the authors and the magazine.