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?

5 Replies to “Cost vs Value Measurements for Agile Approaches”

  1. This is a curious situation for many people. What if we could change how people think of the estimates – and treat them as actual estimates. Acknowledge that reality WILL be different from the estimates, rather than punishing people if they vary. Hold a buffer of time and money to deal with the variability AND find ways in the project to deal with the variability as the work progresses.

    Punishing people for not hitting their estimates is a sure way to get VERY inflated estimates (because they are good people and don’t want to get punished / damaged by the system).

    1. I did an assessment years ago to help a VP understand why “everything was so slow.” He’d made a practice of cutting everyone’s estimates by 20% to “help them go faster.” What he did was create a system where everyone inflated their estimates by 25%. Then, no one took advantage of any project advances if they occurred. (I had a very interesting debrief with him.)

      Even when you and I meet for lunch (readers: Jack and I live less than 2 miles from each other!) I give myself a buffer for traffic. And that’s a lunch date!

      The system of work changes people’s behaviors. People want to succeed and will work to what the system rewards.

  2. [your reply isn’t showing up on the website yet]
    It’s a classic statement that people behave in a way that is aligned with their measures. The example of padding the budget to account for the inevitable across-the-board cut (and still being held accountable to “meet the budget”) is perfect. Even if I don’t really need all the budget (money or time), I will use it because it is “mine” and I believe I will get less next time if I finish under budget this time.

    The measures that create the wrong behaviors need to change. We focus on getting work done as quickly as possible. But this means we ALSO must measure people according to how that helps the overall effort (project, program, deliverable). Maybe it would be better for the project if I stopped working on X and helped Y even if it is outside my “official” duties. But if there are rules in place (often implicit), then I won’t do that to the detriment of the project.

    1. (It’s possible you have to refresh the page to see the comments because I see them. Big Sigh. I hate it when “it works on my machine.”)

      Your comment about the budget is exactly why you and I often have new clients at the end of the year when we might not deliver the value until the next calendar year. If you don’t use your training budget, it’s gone, and worse, the org reduces the budget next year. When you and I budget, we might save money over several years to splurge on that big vacation or whatever. Orgs sometimes do crazy things.

      I really like measuring throughput and the delays that create throughput. (See Unearth Your Project’s Delays.) Single-dimension measurements invite bad behavior, or, behavior that games the system. Multiple-dimension measurements help. They’re not a panacea, but they do help, especially if you measure around the system.

  3. Pingback: Food for Agile Thought #181: Dark Agile, Agile Governance, Scrum Master Trends Report, Product Reviews – Matteo Borghesi

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.