Earned Value Management in Agile

Interesting article on Dr Dobbs about Agile development and Earned Value Management

The first claim is that EVM enables you to objectively measure the value being produced by project teams. Their inherent assumption is that these project teams are actually earning value for your organization, yet in practice we know that this couldn't possibly be true. To see what the problem is, let's work through an example. Let's say that your team is part way through a project, claiming that they've achieved 65 percent earned value (EV). Your team has followed a traditional approach to development, creating a detailed requirements document, then an architecture model, then a prototype, then a design model, and now they've started working on the actual software and are about three quarters of the way through.

You claimed 14 percent EV once the requirements document was accepted, 20 percent EV at the point the architecture was accepted, 33 percent when the detailed design was signed off, and will eventually claim 85 percent EV once the programming effort ends. You've had several major code reviews and by passing them you've been allowed to make the claim that you've achieved 65 percent EV. Then, disaster strikes and you lose funding as the result of an economic downturn. Senior management asks your team to ship whatever you can, but several critical components haven't been coded yet and still need several months of development. And you would still need to perform system and user acceptance testing - another few months worth of effort. It's clear to senior management that none of their investment can be realized quickly, so the project artifacts are "put on the shelf" in the hope that some day they'll be useful to a future project team. Of course, by then the business requirements and technology platforms will have changed. In short, even though your team had claimed 65 percent EV, no actual practical value had in fact been "earned".