Agile and Federal Governance—A Look at Contracts and Earned Value Management


Richard Cheng explores whether or not federal governance controls are ready for agile implementations. If the federal government continues to implement agile without losing agile’s fundamental concepts, contractors and the government will grow in their understanding and ability to implement effective projects and deliver value iteratively and incrementally.

Federal Agile Adoption
On December 9, 2010, the US chief information officer announced a twenty-five-point implementation plan for restructuring federal information technology [1]. One of the major reforms called out in the plan is agile software development [2].

Even before this announcement, several agencies have prominently promoted their agile capabilities. Highlights include:

  • NASA’s enterprise operations moved exclusively to agile development after officials compared error-tracking logs of traditional projects to early efforts using agile development. “We’re believers,” said Gene Sullivan, NASA’s associate chief information officer for enterprise portfolio management. [3]
  • The Department of Veterans Affairs released a Project Management Accountability System (PMAS) Guide, which describes how to implement agile on VA IT projects. This agile guide mandates, “Effective immediately, the PMAS Guide will be followed by all qualifying projects that deliver new functionality or enhance existing systems.” [4]
  • Al Tarasiuk, the chief information officer for the CIA, stated that his agency “has also moved completely to agile project management methodologies” [5].

With the increasing federal interest in agile, are federal governance controls ready for agile implementations?

Agile and Federal Governance
The Manifesto for Agile Software Development defines the essence of agile processes, stating:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have 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 

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

In these core concepts, the Agile Manifesto does not state that governance is not needed. Rather, it says the focus should be on delivering value. Governance that deters from delivering value is waste; governance contributing to the delivery of value is priceless. Governance serving as a tool to delivery of value is an issue when considering agile in the federal government. The federal government has long focused on minimizing risk, at times at the expense of delivery. This focus on minimizing risk impedes agile implementation.

Federal Contracts
One of the key barriers to iterative delivery in the federal government lies in the contracts. Most contracts state all the needs and deliveries up front. This creates a challenge to agile’s inspect-and-adapt model. However, there are some vehicles that are aligned with iterative delivery. David Neumann, Excella Consulting’s federal practice lead, suggests blanket purchase agreement (BPA) and indefinite quote indefinite delivery (IDIQ) contracts as two such examples. Both of these vehicles present a high-level statement of services or needs and allow for task orders to be issued against them. These task orders then supply a detailed scope of work. Figure 1 shows the similarities of an agile project and its iterations to a BPA/IDIQ and its task orders.


Figure 1. Similarities between agile projects and BPA/IDIQ contracts

“I have seen agile federal programs issue monthly task orders that define the scope of the project’s iterations for that month,” Neumann states. The key is to use a template repeatedly for each task order. You should update the scope section of each task order, but the rest of the task order should follow the template.

The ability to stop writing task orders is an added advantage of this model. In federal contracting, it can be difficult to terminate a contract or agreement. However, it is not nearly as difficult to stop issuing task orders. These vehicles allow the clients to control the work and contracts based on the results the vendors or contractors are delivering.


User Comments

Glen Alleman's picture


Some good ideas about agile and EVM. But some clarifications are needed. TO's must be complete and deliver either a product or a service. So a defined outcome that can be put to work is neeeded.

Second is EV does NOT define waterfall. No where in 748-B is the development method called out. EV measures the physical percent complete against the Planned Value (BCWS) - the planned budget. The Earned Value is simply BCWP = BCWS x "physical percent complete." (PPC) This can be applied to any method of developing products or providing services if you have some way of measuring PPC.

Take a look at to see how agile and EV can be integrated.

As you mention the biggest barrier to agile in the federal world is the procurement regulations. But evolving scope is common in many domains. The procured "capabilities" are fixed as they should. But the technical requirements evolve on thing like spaceflight, environmental cleanup, even in ERP. There is major confusion in the agile community on how procurement works on ACAT1 type programs where Capabilities Based Planning drives the outcomes.

Earned Value World, 2013 in Naples FL has a track on EV and Federal space. This would be a good place to come see how us in the defense business apply EV and Agile on large software intensive programs. is the starting point. What needs to be improved is how to flow down "emergent" development programs from the identified capabilities. Some agencies take this approach, some haven't. 

The final key is that it is EV then Agile, not the other way around. EV is only called out on prorgams greater than $20M and a validated system on programs greater than $50M. If you have a fully functional Agile program less than $20M in development, there is no motivation for EV. 

April 21, 2013 - 11:02am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.