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 being 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 about “what are we actually paying for?” since requirements are not defined at the onset. This shift is from the payment of tangible “things” to paying for the commitments that’ve been made in the QASP. By staying in touch with the product team, the procurement team will have ready answers to these questions.

In an agile procurement, the awardee would’ve 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 by 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 scenario demonstrates 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. These artifacts are often stored on vendors’ computers/servers. As a result, govenment access to these artifacts can be 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 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.