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.