Agile is a popular and growing software development approach. It promotes a focus on the product rather than the project plan. This model is very attractive for many reasons and teams are adopting it across the defense industry. However, traditional government contracts and project management are entirely plan-driven. Can you really be agile in a plan-driven world?

Agile in name only

A key part of agile is the scrum, a daily meeting of developers that should last less than 15 minutes and is conducted with all participants standing up to encourage brevity. If your scrums resemble typical project planning meetings, last close to an hour, and are conducted sitting down, you might not really be an agile team.

That’s the trap many agile teams fall in to, at least in government contracts. They use the tools and the language, but their actual work resembles traditional, plan-based methods. They’re agile in name only.

It’s hard to avoid that trap. Consider the four values of agile:

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

That is, while there is value in the items on the right, we value the items on the left more.

agilemanifesto.org

The government’s acquisition and contracting organizations are exactly the opposite. Project managers live and die by the contract; even technical leaders are more likely to focus on contractual requirements than actual mission needs. The acquisition system forces processes and tools on every step of the engineering life cycle, for both the government project office and the contractor.

And if change is inevitable, government contracts are the exception that proves the rule. Even if the mission needs have changed or weren’t well-reflected in the original requirements, it’s often easier to push forward anyway than to modify the contract.

Agile’s iterative loop of design, develop, and feedback doesn’t work if the design is driven by the requirements and not the feedback.

Agile contracts

Currently, the government project office must define all of the requirements up-front in order to receive accurate bids from contractors and to measure the delivered system against. This creates the plan-driven culture and prevents the project from easily adapting to evolving needs.

In a truly agile project, the user-driven capabilities documents still drive the overall acquisition. A representative from the project office acts as the product owner, providing the vision for capability implementation, prioritizing the backlog, and reviewing the completed work in between user evaluations. As with any agile project, the product owner can make or break the effort, so thoughtful selection is essential. And of course, frequent user engagements are a must.

Contractually, this is very do-able. The most common approach is to treat the acquisition more like a software development service than a product. The downside is that objective performance evaluations are more difficult when the end goal can’t be objectively defined up-front. The upside is that the project office gets more control and flexibility as the product evolves.

There are a variety of contractual approaches to enable agile development effectively and within existing acquisition regulations. The U.S. Digital Service collects this information and publishes it in the TechFAR Handbook. This is a must-read for project offices interested in an agile approach.

Protecting the taxpayer’s interests

Agile promises to be more effective at delivering capabilities to the end user. However, most project offices and contractors lack practical agile experience. Agile contracts must be carefully developed and implemented to ensure the success of the project.

First, the project office needs to plan for agile training for both their own organization and the contractor development team. A shared training experience ensures that everyone gains a similar understanding. Even experienced individuals should participate, ensuring that expectations are aligned across everyone involved.

Next, the project office needs to conduct due diligence on prospective contractors. The Defense Innovation Board recently published a draft Guide to Detecting Agile BS with questions to ask. These can be incorporated into the source selection process to determine if the contractor’s claimed agile experience is bona fide or in-name-only.

Finally, the government needs a mechanism to protect their interests in case of quality slips. Traditional milestone incentive payments are plan-driven and may not be compatible with an agile approach. Finding contract performance metrics which are compatible with agile is tricky. A different approach would would be for the government to own the source code, giving them the option of changing contractors if necessary.

Summary

Agile promises to deliver capabilities to the end user faster and more effectively. Government project offices can realize the benefits, but must carefully design their contracts to support the agile approach. A growing body of expertise, lessons learned, and acquisition resources are available to help make it happen.

Do you have experience implementing an agile contract? Share your experiences, positive or negative, in the comments below.