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:

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.

To provide the “complete view” from an EVM perspective, you can update traditional agile progress-monitoring tools, such as a burn chart, to incorporate cost data, effectively allowing for the tracking of both schedule performance (the number of stories completed) and budget performance (labor hours) on the same chart. In this way, it is possible to derive the key elements of earned value for individual iterations and the project as a whole when the total stories and costs for all iterations are combined, as Figure 1 shows.

Figure 1. Modified Agile Burn Chart for EVM

Using this modified burn chart as an example, the elements of earned value can be derived as follows:

• The “planned value” (PV) is observable along the “planned costs” curve and represents the estimated effort for all “planned stories (planned effort)” multiplied by team member labor rates.
• The “actual cost (AC)” is observable along the “actual costs” curve, and can be tracked as each story is completed by multiplying the actual effort for all “completed stories” by team member labor rates.
• The “budgeted cost of work performed (or earned value)” is derived from the “completed stories” curve, where the number of “completed stories” is multiplied by the estimated cost, which is the estimated effort for planned stories multiplied by team member labor rates.
• The “schedule performance index (SPI)” is calculated as [completed stories / planned stories], where a SPI of <1 indicates that the project is performing behind schedule and  you must either refine estimates or the project scope may require adjustment.
• Similarly, the “cost performance index (CPI)” is calculated as [planned costs / actual costs], where a CPI of <1 indicates a cost overrun and, again, a possible need for you to re-estimate or adjust the scope.

A benefit of the agile approach to EVM is that stories are modular and re-usable throughout a project lifecycle. Once the team validates time and effort estimates for a given story in an individual iteration, it is possible to directly refine the estimates throughout the remainder of the effort, wherever a similar story may appear. By effectively re-baselining the total schedule and cost estimates with each iteration, project managers can provide increasingly accurate predictions of project performance as work progresses.

Without a doubt, though, the greatest single benefit of agile EVM is the frequency by which you can granularly track project progress. The project team monitors story completion daily during team stand-up meetings, and burn charts can quickly show variances in both schedule and cost performance. Using this information, government managers (even those unable to attend daily project meetings) are able to rapidly identify potential problems, ask informed questions, and address emerging issues before they have a chance to impact the rest of the project.

Ensuring Program Discipline and Repeatability
One of the final obstacles facing agile projects in the government space is the perception (encountered most often among individuals with limited agile implementation experience, or who have experienced difficult government agile implementations in the past) that agile efforts lack the discipline and repeatability in execution offered by more traditional development methodologies. With their bias towards rapid, iterative delivery of project functionality, agile projects emphasize face-to-face communication and simple documentation (for example, tests serve to document requirements) over the more detailed constructs employed for traditional projects. This “lightweight, just-in-time” approach allows project teams to react quickly, but can lead to coordination difficulties for larger, geographically distributed project teams, as well as increased ramp-up times for stakeholder groups joining the project in mid-stream and – where compliance with traditional government lifecycle review gates is expected – the expenditure of significant effort on creation of compliance-focused project documents that are not directly aligned with actual project work and thus provide minimal actual value to the project effort.

To address this shortcoming in the government space, it is useful to develop a core set of tailor-able “project management framework” documents that can be easily adapted and used by new project teams as both a process reference and an on-boarding and transition guide throughout the remainder of the project lifecycle. Building on industry and project management best-practice principles (PMBOK, CMMI, etc.), this framework should at a minimum allow each project team to quickly and succinctly capture its core objectives and acceptance criteria, processes, and roles and responsibilities, and to track its progress against agency-approved performance parameters. In practice, this “framework” includes three parts:

1. Project management plan (PMP) that captures the objectives, operational processes, roles and responsibilities , and communications principles of the project team(s);
2. Tools (from simplified “dashboards” built in Excel to adaptations of enterprise application lifecycle management (ALM) systems) to capture and track project progress against established performance metrics – at a minimum, cost, schedule, and quality targets for each iteration and release; and
3. Compliance-related documents and deliverables expected as part of the agency’s development lifecycle, tailored with agency approval to better match the project’s iterative development approach and integrated into the delivery schedule.

It can be challenging for practitioners to effectively adapt these more structured elements to the unique needs of a blended-agile project without introducing undue inefficiency to the delivery process, which is why it is critical that project leadership be well-versed in both agile and traditional approaches, and must work closely with government leadership to ensure that the artifacts and tools implemented effectively meet the needs of both the project and the agency. Once implemented, however, these framework elements provide a centralized process reference for all team members – both original and new – and introduce an additional level of process discipline and repeatability that can further increase delivery consistency, reduce ramp-up and transition times, and ensure that even widely distributed project teams remain aligned with the agency’s delivery expectations.

Conclusion
When implemented properly, a blended approach to agile development offers government agencies the opportunity to leverage the greatest strengths of the agile methodology (speed, flexibility, and efficiency) while improving program accountability and reducing delivery risk – thereby increasing the likelihood that the program will deliver expected outcomes on time and on budget.

Implementing any new methodology bears adoption risks, but the blended agile approach offers the added benefit of minimizing the “newness factor” by retaining and re-purposing many of the familiar elements of an agency’s existing delivery lifecycle.

While no development methodology comes without its challenges, a blended approach to agile that carefully integrates core agile principles (short, time-bounded iterations that deliver measurable functionality) with disciplined program management elements drawn from industry best-practice offers government agencies a powerful opportunity to increase program efficiency and flexibility while retaining the high level of operational control, risk management, and accountability they (and the public) have come to expect.

Read all of the articles on Making Agile Work for Government:

Making Agile Work for Government: A Blended Approach
Making Agile Work for Government: Perceived Challenges to Agile Adoption
Making Agile Work for Government: Addressing the Challenges of Agile Adoption