Cost vs Value Measurements for Agile Approaches

Some of my clients have struggled with their project governance as they move to agile approaches. In the past, they've asked for estimates and costs—by requirement—and then tracked the variance for those estimates and costs.

The governance people do not record assumptions. They only record estimates and actuals. They want to “measure” the project success by adherence to estimates of date and costs, not by when the project creates which kind of value.

The people in projects and programs spend a lot of time to create those estimates. Then, assumptions change, needs change, the market changes, and the information has little to no value. The time people spent generating that information was a waste. The original plans are no longer useful. The planning was useful because the planning activities helped people discover risks. See my series on Balance Innovation, Commitment, & Feedback Loops: Summary.

However, the governance people judge the projects and programs by how well their original estimates (for date and cost) line up with the actuals.

This kind of measurement is antithetical to agile principles. Worse, the estimate generation effort has an invisible cost. We can see it in an agile approach, because the more time we spend estimating up front, the longer it takes us to deliver that first increment of value. Our estimates might be more accurate, but the real question is this: does it matter?

Investment, Cost, Value Have Different Meanings

When I plan an investment, I also think about the horizon for the “return.” That's why I find Cost of Delay so helpful in thinking about how to sequence which kinds of work. I want to deliver the most valuable work first.

Agile approaches allow us to do that. They allow us to capitalize the work once it's done, so we can recognize revenue and change how we manage the internal monies.

When I think about cost, I think about the money I use now or relatively soon. I might not expect to see a monetary return at all. When I buy a book, I plan to enjoy it or learn something from it. I don't expect the book to be an investment in the same way as when I buy a software product. I expect to learn how to use the product and then I will be more effective at something.

Software products are different than other kinds of products. Software (and other high tech products) make us more capable in several dimensions—they allow us to do work we otherwise could not accomplish. That productivity thing.

Software products offer value in at least these ways:

• As a producer, I can sell the product (or, in the case of an agile approach, the feature, or the smallest thing I can release).
• As a user, I enhance my productivity.

That means that the cost of a product is not necessarily relevant, if (and that's a big if) you can release the product fast enough and recognize revenue fast enough. That means small stories, and as close to continuous delivery as you can get. That means that the faster you deliver, the faster you can recognize value and reduce your investment.

Where Are You on the Delivery Continuum?

First, take a look at the potential for release frequency image. If you produce a software-only product, you are on the far left.

Now, take a look at where you are in your deliverable continuum.

The smaller your deliverables, the faster you can release, the more often you can plan smaller chunks, and the easier it is to capitalize the effort.

If you have large deliverables, you will find you spend more time in planning. And, you will have to plan larger things.

This matters because the more time you spend in planning, the more other people—including governance people—want to “hold” you to your estimates. They turned those estimates into commitments.

The way to stop this kind of governance is to break your feature sets into small stories and deliver them, at least once a day. More often is better.

Measure Delivered Value and Cost of Delay

Remember that the primary measure of progress is working software (see the Agile Manifesto principles). Not work in progress. Not planned work. Not estimates and costs. Working software.

How fast can you get to working software? (I mean totally working, not cruft or unfinished work.) That's cycle time.

How valuable is that work? Can you recognize revenue from that work?

How will you value the next set of work? I recommend Cost of Delay, not any form of estimation.

If the people who want to assess your project see working software every day, isn't that enough governance?

Use Measures That Reinforce an Agile Approach

I realize that many organization in the midst of a transformation have trouble integrating “agile governance” with more “traditional governance.” I suggest everyone move to the “agile governance” measures. The measures would reinforce smaller, more frequent deliverables.

The point of projects or programs isn't to meet estimates. The point is to deliver value to the customer. Why not use measures that reinforce faster value to the customer?