I’ve got a couple of ideas I decided to throw into a series called Agile Economics. I know, economics doesn’t have to do with daily stand-ups, or backlogs, or self-organizing teams.
Or do they? We’ll see.
Before jumping into the economic waters, let’s remember that economics is not just theory and equations. If it was just that, it would be so easy to convince people just by showing the data.
So to the agile enthusiasts reading this I have good news and bad news: what I’ll present in this series makes complete logical and economical sense. Trying to convince people that agile practices are good based on it would be a bit futile.
But that’s not going to deter us. Let’s do some choir preaching.
The ROI Not Taken
In knowledge work, decisions (execution too, but we’ll get to that later) are the biggest drivers of business economics.
Economics see profit and loss as equivalent. These are just numbers. But we use and perceive these numbers in a completely different way when we’re making decisions.
What is the first question we ask when we’re building something new? Most of the time the first question is “How much will that cost?”.
It’s not a bad question, but its partner is often missing: “What is the value here?”. We’re concentrating on cost more than on value. And we mostly base our decisions based on it. Did you ever wonder why that is?
As Monty Python once said, society is to blame. I’ve been taught to ask this question through every point in my adult life. From vacation planning, to birthday presents, to managing projects and training. We never ask what’s the value of a birthday present, for example, because frankly, we can’t really tell.
But it goes deeper.
We perceive cost much more clearly than value. We can put hard numbers on project and equipment costs, but putting value numbers on an opportunity feels like a gamble (which it is).
Let’s say we are at a junction of creating a new product, and we ask ourselves the immortal question: What will the ROI on this new venture be?
(Let’s ignore the fact that the only way to calculate the ROI is after the fact, and even then it can not really be measured completely. Let’s pretend we can actually name one now).
As we know:
We usually don’t have a number for any of them. In reality, both value and cost, and therefore the ROI, are not constant values, but really unknown functions, depending on the complexity of our environment. For example, the value can depend on when we launch, what the competitors have at this time, the quality at release, and if there’s an economic downturn at the calculation point. Well, that and other 500 parameters, give or take.
The same is true for the cost. It’s a function of a million things as well, so if we needed to name an actual number, we’d be at a loss. But with cost, we can narrow it down, because we have the numbers. Well, most of them. OK, some of them. Or just a few.
In our case, we estimate the new product in 14 man months. We usually forget that there’s work (and re-work) after release, and we don’t take into account all the unplanned work due to changes in the market, technology, team composition and global warming.
We also don’t take into account the landslide in our shares value when the software is released and it’s buggy and nobody uses it, and our other tools that are already in the market, and are branded forever by their new brother’s halo.
We seem to be able to filter all the complexity out, but only in the cost’s case. We can say there’s a number there hiding in the fog of war. The number we can name is the minimal cost. The value numbers stay up in the air (unless you start working estimating value, most people don’t).
Here’s the funny bit: The max ROI is based on a minimal cost (which never happens) and an imaginary number that nobody knows.
The only part of the equation that is seemingly accurate, is that minimal cost. And that’s how we make our biggest decisions.
The bigger the decision, the bigger the gamble, and the risk.
How does agile and lean help us? Tune in next time.