It’s usual for software people today — particularly in the Agile world — to talk about delivering value. While I, too, believe that, I live with a nagging, dragging, doubt that “value” is in fact an empty word.
Once upon a time, so legend has it, it was sufficient for programmers to write code. You might have achieved your goals if you delivered a certain subroutine, or (dread to think!) wrote enough lines of code for the day. Or perhaps it was just sufficient to get the product out of the door.
Simon Baker wrote a great paper called “No Bull”, a look back on his own 12 years in Agile software development. He told of how he realised there was more to delivery than producing the product: his team delivered a brilliantly-engineered product that they were all really proud of. But it was the wrong product, and it ended up being a £30m mistake. That kind of story is not uncommon, and it forces software people to start thinking about the bigger picture.
There is a progression here. At the base level there is writing the code you’re asked to write. At the next level is the kind of team that Simon worked in — fun, productive, responsive to change. They are delivering “value” in the sense that it’s what their internal stakeholders want. And then there is the kind of value that Simon has inevitably moved onto now: asking whether what the stakeholders want is actually good for the company, the users or the market.
But these levels of value or worth are arbitrary. The COO of a major consultancy told me recently about his focus on persuading clients that their technology development is going in the wrong direction if it doesn’t focus on exceptional customer experience. Of course, that’s worked for Apple and Amazon, and who wouldn’t want to be like them? And yet I know one company that made a strategic decision to acquire customers by specifically sacrificing good customer experience. I wouldn’t want to be one of their customers, but I can’t say they made the wrong decision. They broke into a difficult market and are continuing to do well.
Where do you draw the line? Is “value” about delivering your quota of code? Why not look beyond that: are you delivering what your internal customers want? Why not look beyond that: are you delivering what’s good for the company? Why stop there? Are you delivering what’s good for the market? If your company is about making more effective killing machines, or high-fat fast food, are you delivering “value”? The stock market may respond favourably to your products, but is the stock market a valid arbiter of value? And is anything worth anything if ultimately we’re alone in a godless universe and we’re all going to die anyway?
When working with the software team at one company, the process I created defined “value” to be “whatever the product managers said”. This is not what I use as a general rule, but it was the right thing for that situation at that time. By deliberately pushing this question just outside of the software team’s domain it allowed them to get on and make some much more pressing and immediate changes, without also having to take on that thorny problem, too. This move recognised “value” as being arbitrary, and so we happily made it an SEP — Somebody Else’s Problem — at least until the team had restabilised itself.
There is no single right level of where we define value. We can look too far and shrink into shivering despair when we realise that ultimately everything is for nought. Or we can look too near and simply do what we’re told, without questioning it. In the end what each of us probably needs to do is choose a level that balances our personal sense of capability with our personal sense of responsibility.
niksilver.com 
Start a business that *directly* depends on the value you deliver as a software team. The notion of value becomes a great deal less arbitrary and empty then!
Seriously, a lot of the angst about value comes from teams working in large corporations, not small businesses …
@PaulDyson Oh sure, I admit this is a very abstract argument. Although even in a small company whose business depends directly on the software it delivers there are still questions about strategy, and that feeds into the value question — should we add this client’s features if they’re paying well but it doesn’t move our roadmap forward? Or should we pursue our roadmap at the expense of good revenue now? And similar.
Still, I agree what’s important is in generally a lot clearer when you’re in a smaller company. That goes for value and much else besides. And in the end getting on with life is probably more important than noodly navel-gazing.
Very good article, indeed – thank you! I’d like to add a few thoughts of mine.
As you mention initially there is a big want to create awesome solutions and hence the risk is that great, but wrong software is developed. The problem is often that solutions are not aligned with business objectives and that the metrics that should be governing the projects are dim or non-existent. Features become the focus, not the value they bring.
Value is unique for every situation and project but from a software delivery point of view I think that the business plan that underpins the investment is the document to look at when forming the metrics and thus the solution. I see no big difference between producing high quality software and a high quality manufactured product. A business case is developed and endorsed by management based on business values that is good for the company’s objectives and purpose. If the business plan builds on the wrong set of assumptions, there is a slim chance that IT or in the manufacturing case, the product design people, can correct it, unless they are stakeholders in the process.
It is in most cases a tough job to get the governing metrics on the table and in software development it’s a step that is often by-passed. It’s hard but not impossible and I believe if the guiding metrics can’t be developed the investment should be questioned over-all. I think what Apple and Amazon has done so well is that they have delighted their customers with amazing products. But they have also failed with wrong design, wrong timing etc. and they have learned how to do it better.
I think that with improved business alignment and collaboration between business and IT the risk for the kind of failure you write about, is lower. There are always values, may the be No. of users, profits, cost reduction or competitiveness and the first challenge is to pick the right ones for the business plan that should govern the solution.
Nik – perhaps not arbitrary but relative? What I value others may not, but it still has value – to me. This suggests that it is important to know who the work is for – and whether you’re happy about that – inevitably not clear cut.
Its certainly not about the code (see http://www.osel.co.uk/whatsnew.htm).
Not sure about the empty bit – you having a bad day?
@Anders — I agree that working against a business case is more helpful that not, and having metrics in the business case is even better than that. But still there are (or could be) questions about whether those metrics are valid. I’ve seen business cases with metrics that senior stakeholder endorse, but I’ve had to question whether those are useful metrics to be endorsing. You could say it’s the choice of the directors to run their business poorly, or you could choose to question the directors about their outlook. In the end you need to decide where you are happy for the buck to stop.
@Clifford — I think you’re right that value is relative to one’s own outlook. But I also think that outlook is arbitrary — or at least, I cannot explain why I have this particular outlook or you have that particular outlook. So yes, it’s relative, but it’s relative to something arbitrary, and therefore it is arbitrary.
As for being empty… well, I will admit I used that word more for the rhetorical drama than anything else.