Skip to Main Content

Agile Procurement Playbook

A guide on how to apply the principles of agile to procurement.

Managing an agile project

This is one of the greatest challenges in terms of product delivery risk. With a traditional procurement, the whole product's success typically falls to a single prime vendor. While this may sound ideal from the government's point of view, this doesn't actually delegate the risk that's incurred in delivering the product. The government ultimately holds all of the risk, not the vendor. In an effort to de-risk a product's delivery, agencies need to change their traditional approach to managing projects and be much more involved.

Much of this management is due to the multiple modular contracts that'll be issued vs a single monolithic contract. A strong government product owner will need to understand how the modular pieces fit together. In addition to a strong product owner, the government will need to allow for open communication and collaboration early and often between vendors on different contracts. This communication and collaboration overhead can be tricky to manage.

There are a variety of sources that can help agencies embrace this new management style. In agile terminology, a scrum of scrums may be necessary if there are many teams working on the same product to ensure that information isn't siloed and that teams are working on the right thing at the right moment.

While management of a large agile project doesn't directly involve the procurement team, they should still be involved in either weekly or monthly updates from the product team. This keeps procurement experts informed and helps them tweak approaches for future procurements.

The shift into agile procurement can also raise questions on "what are we actually paying for?" due to the requirements not being defined at the onset. This shift is from the payment of tangible "things" to paying for the commitments that have been made in the QASP. By staying in touch with the product team, the procurement team will have ready answers to these questions.

The awardee would have proposed a QASP filled with metrics that needed to be met on a continuous basis and the procurement/contracting arm of the team can hold the awardee accountable through paying toward those metrics. This also allows the contracting team power and flexibility in intervening quickly when/if performance isn't being delivered in the manner outlined in the QASP. Another form of accountability can come in assigning monetary penalties for specific QASP metrics that aren't met. This would be another reason why it's important that the procurement team is part of the whole product team throughout the development of the product.

Source code

Eventually, research will need to gather insights, design will need to create artifacts such as wireframes, and engineering will need to write code to build the product. All of these artifacts need to be stored somewhere and often within the government these artifacts were saved on vendors' computers/servers. Access to those artifacts were many times limited due to internal vendor IT policies.

At a minimum, the government needs to require vendors to post the source code for the product being built in a code repository such as GitHub or Bitbucket. Doing this provides transparency for the government to see what's being built and how the overall engineering process is going. The code repository should be managed by the government so as to de-risk the possibility of a vendor acting nefariously. Once the code is version controlled, the government should consider open-sourcing the code.

Recently, there's been a large push in the federal government to open source the services that are being built and there are many documented benefits in doing this. Aside from the typical documented reasons why open sourcing is beneficial, it also removes leverage from the vendor. Information, or code, isn't hoarded or kept secretive in a way that only a single vendor can continue to develop a product.