Earned Value and Agile - back to the future

"Ignore the arguments against Earned Value from those who have not successfully deployed it" (Glen Alleman, handle @galleman ).  Hat-tip to the College of Performance Management and presenter Robert VanDeVelde, although in this post I am going to deviate a bit from the direction that Dr. VanDeVelde went. .

The current dogma is that Earned Value Management (EVM) cannot be used in fixed-price and Agile, which only happen to be the the two methods of project delivery that are recommended nowadays in preference to old-school cost-plus work.  To spin off the quote that leads this post, we can be sure that this nonsense is being sponsored by those who benefit by avoiding measurement.  It is not true for fixed-price work (we'll get to that in another post). And it is not true for Agile; in fact, that returns us to the original intent of EVM.

Agile by definition attempts to maximize earned value (EV) within the constraints of resources and time.  But how to measure that EV?

• Cost as a surrogate.  Oops, back to cost-plus.  The more hours you plan to charge, the more value the delivery has.  Well, in fact this is true for the contract coders! But not for their customer.  Even assuming no sharp practice by the coders, what if they don't need all the resources for some sprints, which therefore cost less.  Are the features built in that sprint less valuable because they cost less?
• Story points.  Here a knowledge of the vocabulary is useful.  The Function Points that are used in software cost estimation are based on parameters of the effort required to code specific capabilities of a system (interfaces, file transfers etc.). Agile story points are even vaguer: a relativistic measure, unique to the team, that assesses the relative effort of coding one feature or another, simply to determine how many features can be attempted in a specific cycle.  This is problematic on two levels:
• At bottom, it is just a measure of level of effort
• It takes quite a bit of time before the team reaches a stable enough definition of the points and a stable enough working environment that it can define its capacity to do X many story points in a sprint.  Until then the metric is quite useless.
• As a team gets more competent it can knock out more features in the same amount of time, but the measurement system (often expressed as "T-shirt sizes" - small, medium, large) remains the same.  So the metric itself changes over the life of the project, with considerably more content in a later "mediium" than an early-round "medium".
• There is still no relationship between the story point and the value of te feature.

So labor costs or labor effort are not good surrogates for value delivery. Once we've gone there, we can open up any number of non-financial metrics instead.

If we are going to do EVM on a project that uses an Agile approach, we are going to have to award customer value points to the features up front (this is also true for non-Agile approaches, but that's a post for another day).  There are a number of weighted value approaches that one could take, but why fix what isn't broken?  Agile already requires us to prioritize the features so that they can be allocated to sprints and releases. As a simple start, assume that the features have value in the same degree to which they have a priority ranking - only in the reverse order, e.g. in a 30-feature list, the lowest priority feature would have 1 value point and the highest priority feature would have 30 value points. In practice the project team needs to establish some sort of weighting system to separate the features from a simple ranking system.

Using this approach, one can develop an earned-value delivery curve which would NOT be a straight-line that simply reflects the team's capacity to do work.  It would in fact show diminishing returns later in the project - precisely the point that Agilists intended to make in the first place.  Staying ahead of the earned value baseline means finishing the features that have the highest priority, and the team cannot pad value statistics much by stuffing in low-hanging fruit from the bottom of the priority list.

Why did we lead off with "back to the future"?  This is exactly the process that was advocated when earned value first appeared. At that time, EVM distinguished itself from the then-current Cost/Schedule Status Reporting approach precisely because it tried to break the cost = value linkage.  The point then was that one should maximize the delivery of the things that provided value to the customer, not maximize the number of hours billed or the number of lines coded.  The real problem is that EVM has been co-opted by the usual suspects into an endorsement of the cost-plus mind-set -- the precise problem it was intended to solve.  Welcome to Washington.