What the heck is value? – the discipline to try to "put a finger on…"
Note: this is going to be at least two-part series (may have to break it down further in three parts if the next becomes too long. We start today with some basics on how to estimate value.
"Agile is all about working software"—if we want to be precise about what the original manifesto talks about, that's the right framing. But then, as Jeff Patton would say, the point is not to deliver stuff; in fact, the goal should be to minimize output while maximizing impact. That basically means to find a way to acceperate, so-called bigger "bang for the buck" in delivering of value (or concept technically called 'leverage').
So a more modern way you will hear people referring to is: "Agile is about delivering value". A much better frame indeed – but are we totally clear on what we mean by value? Is value the same as "putting a finger on" the dollar/euro of stuff we deliver? Is that realistic all the time?
Speaking from my own experience – as a matter of context, I've been leading (software) products with an internal focus for a while – it's often challenging. Because quite often the products we deliver have a rather far, or at least indirect, connection with direct money related activities. Also quite often our product is one part of a much bigger puzzle, a complex system, that may combine technology (product), people and proces. That makes it somewhat complex to determine whether whatever improvement we see and can meaningfully directly estimate a value (in dollar/euro) to, is to be associated to what parts of the puzzle.
That reality, in my observation, typically brings about a twofold behavior:
Be largely clueless of how to get a (enough confidence) sense of actual dollar/euro value estimation;
The best we can do is to associate it to a higher level calculation done by (some) stakeholder(s), often rather overblown as they want to make sure their asks are prioritized. (Funny story for another day, but I met a person who was in charge of retrospectively evaluating initiatives with a nice value case behind and all of that, it turned out that more often than not, the prove value was way less than initially estimated).
The latter is related to what I call "value as proxy". In essence, what we're delivering tags along for ride together with the resulting value of what is expected to be accomplished overall. For instance, in big organizations you will often do that by associating the items you are working to higher-level (portfolio) strategic programs or initiatives. Or you can say that the work is associated to improving employee morale, or that is linked to a longer-term technical investment as a kind of innovation. Quite often that will be about enough to proof-point that you are working in "valuable" things (especially in good times of abundance).
So by calling it out as a "proxy" is not a judgement, but just a matter of clarity and reality in context.
Nevertheless, whenever the discussion on value comes in a context of a product or team, from a funding standpoint (more typical when times are not as good, so some scarcity emerges), though, then we got to be honest that ultimately people are after some sense of ROI (return on investment). So the 'value as proxy' way is out by the window, by definition. Our challenge then become on getting into the rigor of estimating the value, "putting a finger on" actual/potential dollar/euro amount behind what we are doing.
But that, in my mind, just make the challenge to have that rigor more relevant and interesting, not a loss battle. So here is a simplified way I recently consolidate to provide insight to product teams on how to get to a fair sense of value estimation. One goal, three possible ways (with insight in real examples from my experience):
Whenever I coach PMs about things like that, I also remind them that's less about the precision and accuracy of the estimation; we may be off, and that's fine. The rigor and the discipline to aim at getting something, "putting a finger on" an estimated value is often the 'nudge' for what should happen next anyway: meaningful conversations; and in fact, often changing the conversation. That's ultimately what goes a long way, the estimation we should inspect and adapt anyway.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.