APM & SEE EXECUTIVE SUMMARY  VOL. 18, NO. 1
  

Read the Executive Report

With the increasing adoption of Agile approaches to software product development, organizations often seek to improve their performance in responding to the business needs by following a more flexible and continuous product-scoping approach. Moreover, they are breaking away from the acclaimed disadvantages of the so-called traditional approaches to software engineering and project management that stem from overstructuring, heavy documentation, excessive formalism, and the up-front detailed definition of the project’s product. These rules simply do not cope with the distinctive reality of “software products” and their development working processes.

However, as one would expect, any attempt to follow a radically new path — breaking away from any legacy of established practices — does not come without challenges and new problems. Among these are scaling up Agile product development environments; developing various products in parallel by sharing resources; and the unavoidable need for predictability of product technical performance, cost, and time (the ever-present “triple constraint”). The latter poses the challenge of how to control the Agile initiative by monitoring performance with numbers (i.e., via project controls, which are the basis for rigor, objectivity, and auditability).

It is an unavoidable fact that a radical change to the product development process does not eliminate the essential management requirements imposed by any business: When will the critical product features be available? How far are we into the initiative? When will the overall business need be responded to, and how much is it likely to cost at the end? How many resources need to be assigned? Indeed, the Agile approach does not come with a “blank check”: performance is at play, and if scope, cost, and time are to respond effectively to the business, it must be managed.

To address this management requirement, the legacy of traditional project management would recommend the adoption of the earned value management (EVM) method. Such is its current importance and emergence world­wide, that ISO initiated in early 2016 the development of an EVM standard (ISO 21508). Measuring and managing performance in the Agile product development process via well-established standard controls is still an open issue, which raises the question as to whether the EVM method can be used for this purpose and if it requires any specific adaptation. Based on more than two decades of experience using EVM in a wide range of projects and environments, I answer this question in the accompanying Executive Report by proposing a practical framework to implement the EVM method in Agile initiatives and projects, enabling better-informed decisions for improved business results.

Achieve business value and meet stakeholder expectations with EVM.

Get the complete report today and discover how the earned value management method can be adapted to fit Agile projects. Learn what data needs to be collected, recorded, and calculated, and how to establish a baseline, so that you can measure how well an Agile project is performing using EVM. Cutter members, read the report here. Not a member? Order your copy in PDF format.

The proposed approach is based on the fundamental principle that, while via an Agile process the product scope evolves continuously throughout the initiative — as opposed to attempting an up-front complete and detailed product design — at any moment in time the vision of the product being developed, although evolving, is still finite. It is determined by a set of envisioned explicit requirements in the form of a backlog. From this finite vision of product scope stems that, hand in hand, the investment available, the time required, and the resources deployed are all also finite (despite their evolving nature).

From this principle, the concept of the performance measurement baseline (PMB) can be established. This baseline does not need to be static. On the contrary, as in most projects, in an Agile project it is dynamic and progressively reviewed, but it is always defined at any present time delivering the envisioned and desired future unfolding of the project. Monitoring data and information on scope, cost, and time is then collected to produce performance metrics and indices based on comparison with the PMB. These EVM metrics and indices can then be used to make important decisions during the execution of each sprint and in sprint transitions. The framework presented in the report to implement EVM in Agile product development initiatives includes the following elements:

• A planning process to measure and integrate the project scope, cost, and time elements into a consistent PMB. This process also includes: a guideline to measure the work volume of the requirements in the backlog and to value these against a project budget; a guideline to prioritize the requirements in the product’s backlog, based on several key attributes; a guideline to structure and develop a simple but effective resource-loaded schedule, together with resource-related metrics to help manage risk; and an objective criterion to score progress in the requirements during the execution of the sprints.

• A definition of what data and information regarding scope, cost, and time needs to be collected during the execution and at the end of the sprints and how it should be recorded.

• A definition of the essential EVM performance metrics and indices to be produced, the formulas for calculation, the interpretation, and their purpose for making decisions.

• A description of the main management decisions that can be made based on the performance information from the EVM indices, more specifically adjusting resource allocation, redistributing requirements across the sprints, and reviewing the project’s budget.

A practical example is described in the report to illustrate how this framework can be implemented in practice.

The overall value-add of the EVM metrics and indices is to prevent the project team from continuing to rush through a sprint with hopes of catching up with work and then toward the end not being able to do much better than just postponing incomplete requirements to the following sprint — a “syndrome” that tends to prevail throughout the project. In addition to this performance perspective of integrating scope and resource tradeoffs, the proposed metrics also provide some insight into the economics of the Agile project by indicating whether an increase in investment is likely to ensure the implementation of the currently foreseen set of requirements identified in the project backlog. The goal of the framework presented is to provide a basis that can be simplified or made more comprehensive as needed by the project team (e.g., additional indices can be produced without the need of additional planning or data collection).

So, can a method like EVM, developed to control projects with well-defined objectives, be applied to control product development initiatives that evolve continuously toward a “moving target”? In an Agile environment, we are faced with the dynamic evolution of a finite boundary of integrated scope, cost, time, and resources; this finiteness — essential for business management and decisions — is the cradle for project management techniques, tools, methods, and frameworks. The EVM method was first developed to help with managing complex R&D projects mostly characterized by an unstable, volatile, and evolving scope. It is therefore no surprise that EVM applies to Agile projects.