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.

Agile and Earned Value Management
In its simplest form, earned value management (EVM) measures earned value and actual costs against planned value and budget at completion [7]. This allows for the measurement of value realized to date and forecasting of future performance. There are strong similarities between this and the project burn-down and burn-up charts typically used to measure agile projects. The project burn-down chart displays how much work is left in the project and reconciles that against the team’s rate of producing work (also called the team velocity) to identify when the project will be completed. The project burn-up chart measures how much work has been completed and how much work is remaining. This presents effort expanded. (Tamara Sulaiman published an article on “AgileEVM,” which integrates many EVM and agile concepts [8].)

Despite these similarities, there are important issues when dealing with EVM on agile projects. Many of these issues are not inherent to EVM but rather the way various program management offices implement EVM.

EVM and Waterfall
One problem is that many EVM implementations assume a waterfall or traditional lifecycle. Thus, we have an understanding of work as seen in figure 2.

Figure 2. Waterfall EVM

To address this, agile teams need to work with their project management offices to shift the mentality to an iterative EVM model, as seen in figure 3.

Figure 3. Iterative EVM

This shift in thinking promotes the concept of what agile believes to be of value. If you have dedicated half the project time to requirements and the requirements phase is done, many EVM systems will state that half of the project’s value has been delivered. The problem is that no actual system has been delivered, so the project has not seen any true value. In the agile model, the goal of each sprint (or iteration) is to have a potentially releasable system. Thus, when you have completed half of the sprints, you have delivered at least half of the value.

Baselining Work and New Work
Baselining of work is one of the problems in EVM. On agile projects, priorities and tasks often shift to reflect new knowledge or program needs. When you perform tasks out of the sequence recognized by the EVM systems, these tasks often have warning or error flags due to the fact that they began too early or too late. The solution is to have the EVM system update the sequencing in real time, or at least at the end of each iteration. This allows the EVM system to accurately reflect the work performed in the current iteration and upcoming iterations.

There is also the question of what to do if new work is discovered. In many current systems, this would require a lengthy change-request process. For fixed-cost or fixed-date agile projects, the solution is to allow the product owners to put in new work only if they take out equally sized existing work. You also would update the EVM system accordingly. If the costs or dates are not fixed, then you can update the product backlog and EVM systems to reflect the new work. You should also properly prioritize (sequence) the new work in the EVM system and on the team’s product backlog.

Education and Experience
Ultimately, the true solutions to contract, EVM, and other governance needs will come from education and experience. At its heart, the agile methodology enables teams to learn and grow. 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.

References

1. Kundra, V., U.S. Chief Information Officer (December 9, 2010), 25 POINT IMPLEMENTATION PLAN TO REFORM FEDERAL INFORMATION TECHNOLOGY MANAGEMENT, 
2. Kelman, S. (June 20, 2011), Continuity after Kundra
3. Joch, A. (October 15, 2009), Does 'early and often' work for software? http://fcw.com/articles/2009/10/19/feat-agile-development-government.aspx
4. Assistant Secretary for Information and Technology, Department of Veterans Affairs. (March 29, 2010), Project Management Accountability System (PMAS) Guide
   
5. Wailgum, T. (August 4, 2008), Inside the CIA's Extreme Technology Makeover, Part 1,
6. AgileManifesto.org. (2001), Manifesto for Agile Software Development
7. Project Management Institute. (2008) A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.
8. Sulaiman, T. (October 5, 2007) AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. http://www.infoq.com/articles/agile-evm