The debate over the value of Earned Value Management (EVM) and integrating it into agile rages heavy as agile penetrates into more large scale IT projects that require EVM. Opinions vary but some believe that not only can agile projects apply EVM; EVM with agile is superior to EVM without agile.
Glen Alleman explains the basics of EVM: "Earned Value measures progress as physical percent complete against the planned percent complete." The Defense Acquisition University (DAU) Gold Card provides a sample visualization of how EVM represents current variance to provide input for future adjustments (note that traditional EVM terms are used).
- The cost variance shows the difference between the Budgeted Cost for Work Performed (BCWP), often called the Earned Value (EV) using newer terminology, versus the Actual Cost for Work Performed (ACWP). In this example, the project is currently over budget.
- The schedule variance shows the difference between the Budgeted Cost for Work Scheduled (BCWS) versus the BCWP expressed as dollars to approximate conformance to schedule. In this example the project is currently behind schedule.
In a May 2011 blog post titled Agile and EVM Strategies, posted on Dr. Dobb’s site, Scott Ambler acknowledges that EVM can be applied to agile projects, but he questions its value for IT development projects, agile or not.
The fundamental problem with EVM is that it has very little to do with earning value and everything to do with managing against what often proves to be naive/fictitious schedules and estimates committed to far too early in the project. Although EVM is interesting project management theory, and I have no doubt that it may work in some non-IT domains, it proves to be a really bad project management strategy in practice for IT development projects.
Although EVM can in fact be applied to agile projects, in my opinion EVM is a questionable practice, regardless of paradigm. Organizations that are trying to govern their IT project teams should monitor them in such a way that accurate and timely information is presented. This is clearly not the case with EVM
Others provide a different perspective. Glen Alleman wrote a post in response to Scott's statements and, in a private email exchange, Glen explained the symbiotic relationship of EV and agile.
EV and agile have a symbiotic relationship. EV can forecast the Estimate at Completion in units meaningful to the funder – dollars. Agile can adapt to changes in requirements will relative ease, because of the relationship between the customer and the development team (single team). Now add 1,000's of requirements, a complex architecture (ERP to manned space flight guidance), multiple funding sources, a disconnected customer (we’re in Phoenix and the customer is in Houston and we meet once a month), and a myriad of other “complications” and Agile can still provide value at the software development level and EV becomes one of several "governance" process when spending other people's money. Be that money government or shareholders.
Derek Huether, who, until recently, was an advisor to a PMO for the United States Federal Government, further states how agile approaches improve EVM, "If the vendor is forced to deliver value to the customer at the end of short iterations, there is less opportunity for some kind of manipulation of Cost Performance Index (CPI) or Schedule Performance Index (SPI) to be attempted."
Dr. Norm Brown, of the Center for Program Transformation, states the case for how agile improves EVM more strongly, "EVM becomes highly effective when agile techniques are applied to the program."
For those who are contractually obligated to adhere to EVM requirements, this is a practical issue, not a philosophical debate. Fortunately there is free, high quliaty, EVM information on the web, with several resources listed below, allowing you to make an educated decision.