One irritating circumstance in the world around development is the fact that customers and company managment tend to view the voyage of development as something that has to be calculated like any other investment. Or at least I thought it was irritating until last week.
This investment calculus that has to take place upfront drives big design upfront, detailed planning and everything bad that goes with a model with “upfront” in it.
But last week I had a discussion with my two collegues about how to draw a curve illustrating the fact that we need to get early payback from any development project or activities. I suppose you have all experienced the fact that given multiple checkpoints a long the way, as opposed to only a single at the end you are much more likely to hit the target (after all that is what being agile is all about).
We started talking about how to visualize the fact that worked hours (the most common tracking parameter for development projects in the world, it seems) is not a good way to measure, and consequently show in a follow-up diagram, project progress. Instead it is the value of the current development result that should be put on the y-axis. This is actually nothing new (what is?), already function points and earned value are classical methods to do something this.
But the real insight here is that if we just could turn this earned value (which in agile terms of course is working functions delivered) into money we would be in a position to argue all the benefits of agile thinking to management and into the contract problem area.
Why? Because to a company executive it is easy to understand that the value returned did not come from exactly what we planned but we could still cash in the same value. Dollars for dollars, as it where. This opens up a possibility to work agile in rigidly contracted environments also, if only we can formulate the contract in terms of investment and return on investment.
So how would we estimate progress in terms of ROI? Well, I guess that anyone that can guess the ROI on a completed product, given some essential functions and properties, could also do a fairly good job of estimating partial value of same. So, do an earned value estimate on each function (or story or UseCase according to your preferences), follow up on that, and handle any change in features also as a change in the earned values. Then trade one earned value for another and, if they are comfortable with the estimated values, they will have no objections to whatever changes your agile project uncovers or requires.