Going Agile: The new mind-set for procurement officials How does Agile change the role of the acquisition officer?

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:

Shift 1: From contract-centered to project-centered

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:

• Individuals and interactions over processes and tools
  
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
  
• Responding to change over following a plan

The signers of the manifesto acknowledge: “While there is value in the items on the right, we value the items on the left more.”¹ 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.² 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.

Shift 2: The vendor doesn’t run the project, the agency does

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.

Shift 3: You aren’t just buying software, you are entering a relationship

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.

Shift 4: From “lump sum, fixed price” to incremental pricing

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.”

Shift 5: From contract management to performance monitoring

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.”³ 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.”⁴ Bye-bye, Gantt charts. Hello, demos.

The road ahead

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.