Going Agile: The new mind-set for procurement officials has been saved
Contracting for Agile software development should focus on enabling a smooth vendor-client relationship rather than on specifying terms and conditions in exhaustive detail.
Government organizations are increasingly looking to partner with vendors who use Agile to deliver software systems. But for government to successfully take advantage of what Agile has to offer requires a change in mind-set for procurement officials.
For most things that government buys, most people aren’t overly concerned with the process of how it is made. From office furniture to computers, how the item being purchased was built doesn’t really matter.
But if you want to buy software that is developed through an Agile process, you need to alter your procurement process. The procurement officials, the lawyers, and the purchasing agency’s business leaders need to embrace a new way of thinking about their role.
Why? Because the Agile process combines design with development and user acceptance. In other words, the software’s final design emerges through a collaborative effort between developers and business users. So the traditional procurement approach, heavy on functional specifications written up front, isn’t consistent with the Agile approach.
The new mind-set of procuring for Agile involves many major shifts in thinking. Five of the most important shifts include:
The Agile Manifesto, which kick-started the Agile movement in 2001, explicitly talks about the relative value of various aspects of software development. The manifesto’s signers declared that they had come to value:
The signers of the manifesto acknowledge: “While there is value in the items on the right, we value the items on the left more.”1 Those familiar with government will quickly recognize that public procurement is strongly weighted to the items on the right.
For procurement officials looking to use Agile, this has clear and obvious implications. The contract has always been a cornerstone of public software procurement, the document that defines the relationship between a government agency and a vendor. Traditionally, a well-written contract, including detailed specifications, was seen as critical to a successful engagement.
This makes intuitive sense, and a linear, rules-based approach certainly feels safe. But experience teaches us that that feeling is often an illusion. The Standish Group’s CHAOS Report routinely shows that Agile projects have a higher success rate than linear waterfall projects, and waterfall is more likely not just to go over budget, but to fail in delivering software that works for users.2 Paper safeguards are of little use if they don’t result in successful projects. Good stewards of government focus on ensuring value from an investment. That may mean rethinking the massive requirement-laden contracts of yesteryear.
In the old contract-centric world, the contracting agency spends months, maybe years, soliciting and documenting user requirements, then “tosses” this blueprint over the wall. The vendor collects it, and many months, or years, later, delivers a final product—sometimes deeply flawed. While any number of sanctions in the contract make it appear “tough-nosed,” these sanctions may prove difficult to enforce as agencies find that the software “is what they asked for just not what they really needed.” This contract-centric approach too often leads to disappointment and disagreement.
In Agile, there is no blueprint and there is no wall. The agency and the vendor partner to build a system. The vendor’s assistance may include project management as well as the heavy lifting of development—but throughout the process the government agency actively participates, helping to ensure that the final result will meet its needs.
More than a well-written contract or massive spec document, for Agile to succeed there must be a leader at the agency with a vision for what the application is going to do: Whom does the software support? What is the business challenge being addressed? How will data enter and leave the system? The Agile process turns this vision into working software.
Agile software development requires software buyers to rethink the role of the contract. Instead of serving as the ultimate blueprint for the projects—detailed specs, precise price, firm deadlines—the contract becomes a guide for structuring the relationship between the government agency and the vendor. The shift in mind-set is profound. The agency is no longer looking to buy a “thing”—in this case a new software system. Instead, the agency is entering a relationship to jointly design and build a new software system.
Hence, the contract doesn’t primarily define the software. The contract’s main purpose is to define the expectations of the relationship. This can include pricing associated with a series of performance reviews, defining “done,” and clarifying the role of agency representatives and the vendor. One of the biggest challenges for IT vendors can be insufficient access to subject matter experts and managers empowered to make quick decisions—these should be spelled out in advance.
No builder can provide a precise fixed cost bid on a house without a highly detailed set of blueprints. The same is true when building software. Because Agile doesn’t provide precise specifications up front, it’s somewhere between difficult and impossible to calculate an accurate fixed price in advance. This means there will likely need to be some form of incremental pricing, which could entail a time and materials approach, or breaking the project into smaller chunks, or paying for “development points.”
Traditional contract management focused on the terms of the contract: Are the correct number of people on the task and are their hours properly documented? Agile leaders can still track that sort of compliance if they’d like, but more important is performance monitoring. One Agile principle states: “Working software is the primary measure of progress.”3 After every Agile “sprint,” hands-on review of the software is critical. One project manager told us, “Paper reviews are mostly worthless. You’ve got to regularly see demos of the software as it is being developed.”4 Bye-bye, Gantt charts. Hello, demos.
Agile isn’t the right approach for every project, and there is considerable variation within the various “flavors” of Agile. But for those procurement officials looking to buy software developed through Agile, a significant shift in mind-set is in order.
Tools for Agile thinking
For those looking to dig deeper, here are some additional resources on contracting for Agile development. Also see other articles in our Agile series.
18F resources
18F houses a treasure trove of information on making Agile work in government. The modular contracting guidebook helps government executives implement modular contracting at their agencies and enable Agile development. It has also created a modular contracting resources page on GitHub. Also check out its blog series that covers a wide array of topics on Agile development.
White House resource
You can also go back to the 2012 contracting guidance from the White House on modular development. The guidance, although published a few years ago, is still relevant and could be helpful for executives who want to dive into Agile.
TechFAR handbook
This handbook highlights the flexibilities in the Federal Acquisition Regulation (FAR) that can help agencies implement different plays from the digital services playbook. It also focuses on how to use contractors to support an iterative, customer-centric software development process.
Agile contracting in action
See the 18F Agile Delivery Services Blanket Purchase Agreement page for more details about how the US federal government is trying to align acquisition practices with Agile delivery practices. The 18F also has an ongoing blog series on Agile BPA.