One of the most useful concepts that I have come across when trying to understand the benefits of an Agile approach is the idea of value being hypothetical. I first came across this whilst watching this excellent and highly entertaining talk by Jeff Patton where he says:
"The big myth here is that value is predictable, but in fact we know it is hypothetical. When we decide to build things or buy things or spend money on things there is hypothetical value. They are bets."
Jeff goes on to talk about the fact that some of these bets can be more risky than others (and he compares a lottery ticket, which has huge potential value but little certainty, to a telephone calling card which has a predictable, but low, value).
Key point 1: The value of building new software is hard to predict. And that is because, until you have built it, you really can't know the value it will deliver. Of course you can estimate the value before it is built, but you can't know it. The value is hypothetical.
A similar point was made by Josh Lehman in his explanation of why people are not prepared to pay "less than the price of a cup of coffee" for a mobile app:
"I know I’ll like my cup of coffee. It will fully meet my expectations. It’s an experience I can fully trust will be pretty much the same each time. There’s no gamble here. Now, contrast this with your app, Mr. Developer. I don’t know you from Adam. The return I’m going to get is questionable at best. I already have 30 games on my phone, some of them very good. Do I need another one? I don’t play the 30 I have. The experience I’m going to get from adding one more game is not trustable. I’m assured of nothing. Last week I bought a game for 99 cents and it was terrible. I played it once, for 15 seconds. I could be shoving $1 straight down the toilet again for all I know. Your app, good sir, is a total gamble. Sure, it’s only a $1 gamble… but it’s a gamble and that fact matters more than any price you might place on it."
Key point 2: value does not relate to production cost. Just because a coffee costs less to produce than a mobile app does not mean it has lower value. And, as I have said before, in many disciplines (and especially in software development), the value delivered often does not relate proportionally to the costs involved. The Pareto Principle usually applies and 20% of the effort yields 80% (or more) of the value.
So how does Agile help with all of this? Well a key aim of an Agile approach is to deliver little and often. Different methods (for example XP, Kanban and Scrum) have slightly different ways of achieving this but they all share the goal articulated in the Agile Manifesto when it says:
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
By doing this you are making smaller bets with the aim of finding out as soon as possible whether you have a winning lottery ticket or just a worthless piece of paper. You are trading hypothetical value for actual value as quickly as you can.
This in turn gives you rapid feedback about the actual vs. expected value, which you can use to make better business decisions. Perhaps the actual value is higher than expected and the development should be accelerated or expanded. Perhaps you have already delivered 80% of the expected value and that is enough (particularly if another project needs to be started). Or perhaps you started to build something that has little or no value (the "terrible game I played once for 15 seconds"), in which case finding out as soon as possible and redirecting your efforts could mean the difference between abysmal failure and tremendous success.