GMU playbook: Agile contracting

In this week’s blog post on our acquisition playbook study, we discuss agile contracting. When technical solutions are uncertain, it is wise to provide room for discretion in contractual relationships. This is the first of our software-intensive plays.

Read the Draft Playbook, May 13, 2021

Background

Government leaders have good reason to talk about the need for agility. The principles of agile have not only been adopted by the fastest growing startups in the commercial sector, but also by the largest incumbent firms including IBM, AT&T, Procter & Gamble, John Deer, and many others. Survival in commercial markets demands adaptation.

Though many definitions of agile exist, the Agile Manifesto provides four guiding principles:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The Agile Manifesto finds a companion concept in the idea of formal relational contracts. Oliver Hart, a Nobel prize winning economist, noted how strategic partnerships between organizations can be improved by focusing on desired outcomes and relationship management processes.

For example, when Dell selected FedEx in 2005 for its hardware return-and-repair procedure, it drew up a 100+ page document filled with “supplier shall” statements. For nearly a decade, FedEx met the letter of the contract but neither side was happy. Just two years after switching to a formal relational contract, they were able to reduce costs by 42% and scrap by 67%. Both companies now consider the approach a best practice to be applied with all relationships.

Application

In many ways, the heritage of defense contracting is colored with agile processes. Lockheed’s Kelly Johnson liked to tell a story about the P-80, America’s first jet. He got a letter contract to start work drafted, approved, and signed within an hour-and-a-half. Similarly, in 1955 the entire specification for the F-4 Phantom II contract fit within two pages. By contrast, in 1980 the C-17 specification consistent of 13,516 pages.

The long list of “supplier shall” statements that has pervaded government contracting works best for well-defined procurements. For innovative products such as software, the process gives only the illusion of control. When one thing is incentivized, another is disincentivized. This leads to the perplexing situation faced by Dell and FedEx where contract obligations are met but neither side is happy. This situation is also shared by many government programs.

When technical solutions are uncertain, it is wise to provide room for discretion in contractual relationships. As defense contracting scholar Frederic Scherer said in 1971, “given the kinds of technical problems characterizing modern-day weapons developments, inflexibility of contractual instruments is incompatible with economy.”

In practice, this formal relational contract means removing much of the technical direction that presumes the product end-state from the contract work statement. In its place, there’s a vision and a process. The concept is outlined below and in the appendix of this post. There is a lot more detail for crafting agile work statements, including instructions and templates, in the TechFAR Handbook, FAI Periodic Table, and GSA Agile Contract PWS Template. In essence, the government is buying a partner rather than a pre-specified product.

The first three Mason GovCon program-level plays set the stage for this software-intensive play:

• Iteration of outcomes-based requirements with program stakeholders makes possible a collaborative prioritization process between the program office and contractor.
• Continuous market research provides information on contractor capabilities and past performance as a basis for source selection rather than detailed technical implementation plans.
• Modular open systems architecture provides general design constraints, creates independence of development teams, and prevents contractor lock in.

Discussions with acquisition practitioners in roundtables has provided valuable feedback on the challenges and opportunities of the play.

Collaboration

Once the contract provides for flexibility in technical direction, government product owners – usually the contracting officer’s representatives – must feel empowered to make decisions so long as it fits within the constraints set by the program requirements. The agile contracting approach recognizes that priorities will change, with some features being more important and others less important than originally thought. Collaboration is a substitute for extensive contract negotiations, and requires a mission command mindset throughout the organization. The product owner should consider the following collaborative tips:

• Face-to-face communication is best
• Trust the development team for the first few sprints
• Do not reprioritize the product backlog in the middle of sprints
• Facilitate the development team’s access to end users

Accountability

In traditional government processes, there is an appearance of accountability with long work statements and thousands of tasks in an integrated master schedule. Former Comptroller General Elmer Staats once remarked that 20 to 50 percent of development costs for defense programs are in documentation. Extensive documentation is supposed to reduce risk associated with “waterfall” development where tests may not occur for several years. Despite the documentation, true accountability is rarely driven into programs because real progress is not often recognized until roughly two-thirds of the way through when sunk cost bias has taken hold.

Agile processes reduce customer risk by delivering functionality early. Delivered software is the primary measure of progress rather than percent complete or earned value. The product owner must thoroughly document artifacts from agile development and integrate that into the program requirements process with the product lead and its stakeholders.

One of the dangers is that by pursuing an agile process, program stakeholders have new opportunities to hold programs accountable. The first missed milestone could threaten restructuring or cancellation. In some cases, failing early could be a good thing.

Even if the lightweight acquisition makes it less painful to cancel, usually a better first step is to address personnel issues. Product owners should let the contractor know if an individual should be dealt with before resorting to more drastic measures. Similarly, product owners should be monitored by the product lead and the contracting officer to verify that they are qualified to carry the technical responsibility entrusted to them.

Scaling

Though many will admit that agile processes seem to work for small applications, they have doubts about whether it applies to major programs that will involve hundreds or thousands of people. However, Gall’s Law states that all complex systems that work evolved from simpler systems that worked. Evidence for this statement is as pervasive in nature as it is in systems engineering. Project Hindsight in the 1960s, for example, found how each major weapon system required dozens if not hundreds of significant technologies be developed before the system could be made possible. If all these technologies where scheduled as part of a single development program, then efficiency is lost. The chances all components will advance and integrate as planned is vanishingly small.

The alternative to replacing one major system with another is to “boil the frog.” According to the fable, if you put a frog in boiling water it will jump out, but if you slowly turn the stove heat up it will slowly cook to death. Similarly, rather than requiring that a new system meet all the requirements found in a legacy system, it can introduce the core functionality and use work-arounds to fill gaps. User adoption can then drive system transition and help steer the direction of continuous development cycles.

Legacy program example

The Navy’s F/A-18 program office has been using an agile process for many years. The program office had nearly 700 organic technical folks who could take ownership of short one-page requirements. Technical direction was separated from the contract and the government lead worked closely with the contractor. This allowed the program office to issue task orders within one week or less. More than 250 separate requirements were being worked at any time, and they could be deployed as part of regular capability releases. While this sped up fielding and lowered costs, it required a critical mass of organic technical capability and a culture to support it.

Conclusion

There is empirical evidence that agile development processes work. Yet these processes often fail in organizations when the business functions remain fixed to industrial era methods. The failed situation is sometimes called “water-agile-fall.” For contracting to support agile software development, technical direction should be removed from work statements and replaced with a collaborative process. The contract remains legally enforceable, and through early releases of functioning product, accountability is improved.

APPENDIX: Major elements of a performance work statement for agile contracts

• Vision statement. This should provide the high-level scope and business motivation.
• Agile processes. Identify the core construct of the desired process:
  1. Sprint duration. Allow the contractor to define a sprint duration, but should be short (two to four weeks).
  2. Product Backlog. A list of features or user stories to be developed as well as defects to be fixed. User stories often come in the short format “As a ___, I want ___ so that ___.” Each item will be assigned an effort estimated by the development team and a business value estimate by the product owner. A solicitation may ask for an initial product backlog, but this isn’t to be contractually binding.
• Roles and responsibilities. Besides the contracting officer and procurement manager’s duties, identify at least three additional roles and their responsibilities in agile “ceremonies”:
  1. Product Owner. This is generally the Contracting Officer’s Representative, who communicates the customer vision, takes the lead of prioritizing the backlog, and participates in sprint planning/review activities.
  2. Development Team. A cross-functional team which performs on each sprint. Contractor should provide key personnel, skill types, and hourly rate.
  3. Scrum Master. A contractor who ensures cooperation between the Product Owner and Development Team, but is not the project manager. Attends sprint planning/review activities.
• Definition of Done. During each sprint planning meeting, the parties will agree to the conditions of acceptance testing for each item on the backlog. Tests should be conducted and passed, code has been reviewed, standards have been met, and documentation has been completed.
• Deliverables. Agile contract deliverables should not require specific features sets, but instead:
  1. Product backlog at the beginning of each sprint.
  2. Reports at the end of each sprint on design files, product demos, performance metrics, etc.
  3. Development prototypes when required, at the end of a sprint or call order.
  4. Code repository of the source code that comprises the product, if government owned.
• Business. Regular business items like type of contract, price, and period of performance. Additional items may include: cybersecurity requirements, intellectual property, terminations, and technology standards.

For more resources, see the Agile Contracts primer, Contracts for Agile Software Development, and the book Agile Contracts.