Making Agile Work for Government: Addressing the Challenges of Agile Adoption

[article]
Summary:
Erich Knausenberger and Raj Shah examine the challenges of implementing earned value management and program management to implementing agile for government IT. Then, the authors propose a “blended-approach” by which government and other large entities can address these and other challenges.

In “Making Agile Work for Government: A Blended Approach,” we introduced the concept of a “blended approach” to agile development in the government space. This approach incorporates the core principles of agile while also applying elements of other industry best-practices without forcing agencies to completely abandon their traditional performance management methodologies as a precondition for success. In our subsequent article “Making Agile Work for Government: Perceived Challenges to Agile Adoption,” we addressed three perceived challenges to implementation of agile in the government space and explored a “blended approach” response to each.

In this article, we examine two further challenges to implementing agile for government IT programs and proposes a “blended-approach” by which government and other large entities can address these and other challenges:

fig 1

Table 1. Addressing Perceived Challenges to Agile on Government Projects

Agile Earned Value Management (EVM)
For traditional projects, it is assumed that scope can be fully defined at the outset of a project, and work can be completed in a linear, sequential fashion in which current progress rates are good indicators of future rates.

On an agile project, work is completed iteratively and is neither sequential nor linear; the work is subject to frequent refinement of scope. On the surface, these characteristics appear to put agile projects at odds with first principle of traditional EVM: The need to establish a high-quality baseline plan that can be used to measure performance and take action when deviations are observed.

Using EVM on an agile project requires us to focus on the core purpose of “earned value,” which is to relate actual project progress to actual project cost while effectively identifying and responding to problems and deviations before they significantly impact the overall delivery effort. In this regard, an agile project’s story-driven, iterative approach to delivery of functionality actually provides a more detailed view of project progress than traditional whole-lifecycle EVM techniques, and allows managers to identify and respond to problems sooner.

This more detailed view of project progress is possible because the agile approach enables you to track project performance at the individual story level. Every element of project work—whether conducting a meeting, creating a document, or writing code—can be defined in terms of a story, and in turn mapped to one or more project iterations. At the start of each iteration, a separate planning and estimation effort conducted by the project team determines the number (and type) of stories required to complete the iteration. This iteration plan, with its list of defined and mapped stories, serves as a detailed baseline plan against which EVM principles can be applied. Each story represents a discrete unit of scope and effort that can be tracked as the story is completed and evaluated against the plan to determine iteration-specific performance. The sum of stories in all iterations makes up the total scope of work to be completed by the project, a value that can be easily updated and re-baselined as your team completes project iterations.

In the modified agile approach to EVM, it is important to draw an effective link between stories, effort, and cost, as these elements underpin the connection between agile progress measures and traditional EVM. Story points, the common measure of effort associated with agile stories, are not directly traceable to labor hours because they also incorporate the relative complexity, unknowns, and labor required to implement a given story.  Instead, it is necessary to directly estimate the labor hours associated with each type of story to be implemented during the course of the iteration. By multiplying the estimated effort associated with each story (which will become actual effort once the story is complete) by team member labor rates, it is possible to derive the cost associated with each story, each iteration, and in sum the entire project.

About the author

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!