Andy Pols Geek, Entrepreneur

Reflections on the Business Value of Software

I remember having a rant at the eXtreme Tuesday Club a few years ago, "Who cares about working software, if it's not what the business need? Delivering Business Value is the most important thing!"

This was triggered from seeing too many agile teams get bogged down in the minutiae of the process. They did not think about how the business would benefit from what they did or how they could deliver value early. Delivering working software was the only important measure they cared about. They missed the subtlety of the Agile Manifesto that talked about delivering valuable software:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

I saw several agile projects that delivered software the business did not want. Chris Matts and I made it our mission to bang on about Business Value back at the Agile Development Conference in 2003. We published a paper in Cutter in 2004 based on our experience of applying these ideas on our projects.

It's great that this is starting to get traction in the agile community. There was even a whole track dedicated to this very subject at Agile 2008. This has to be a good thing.

On reflection, I think the moniker Business Value was a mistake as it confuses the conversation. People start assigning a Value to what they do. You see things like:

  • This project will attract 120 new registrations per month.
  • This project is worth $12M
  • This project will generate 4 million page hits in the first year.

The greatest problem with these statements like this is that it's impossible to re-evaluate the business value if market conditions change. There is no mention of the cost of generating this revenue or the amount of capital investment required to generate the revenue. It results in dumb behavior.

Several speakers at Agile 2008 talked about business value Story Points. Joe Little proposed assigning Business Value points to each item in a backlog. My experience is that this consumes a vast amount of energy and the business people start making up large values to game the prioritization process.

I really enjoy watching the BBC television series Dragon's Den. Entrepreneurs pitch for investment in the Den from five Angel Investors (The Dragons!), willing to invest their own money in exchange for equity. When the Entrepreneurs provide a Value, the dragons always probe for the model:

  • How much does it cost to manufacture?,
  • What's the size of the market?,
  • What form of distribution channel are you using?,
  • So how did you come to value your business at $8 Million?"
  • etc.

It's impossible for the Dragons to make a sensible investment decision from a simple value.

This is why Chris and I always say Business Value is a Model, not a number.

Software development is also an investment and, just like the Dragons (although I'm not suggesting our customers are dragons!), the Business need to probe the model to assess the value of the software investment.

Another problem is the model is is a state of flux. Few businesses exist in a vacuum. Markets change, assumptions become invalidated and competitors launch disruptive technology. If you assign a value to a story based on a model, there is a danger that the model's assumptions have changed by the time you want to implement it.  People take the business value number for granted and rarely question its validity.

I use the model as a litmus test to verify if the next chunk of work makes sense as and when you need it.

Creating solutions that deliver the maximum-business-value should be the primary purpose of what every development team does, regardless of their process. It's more then just consuming stories or taking for granted that the items in the product backlog make sense.

comments powered by Disqus