What is Value?leena
July 30, 2017
Continuing with my reflections (you can call them rants too :)) on my earlier post - Fixed Requirements, where the fundamental issue was that we couldn’t deliver value to the users, or rather we delivered it very late. That brings in the question "what is value, how do we know it is delivered".
We built a prototype to quickly validate and demonstrate the idea that we can build a tool sync two different systems.
When we delivered the same to the users, there were a lot of surprises in our understanding of the users, the external tools integrated for syncing and the environment in which it is deployed. For eg: for the prototype, we used a CSV to map the fields. It was fine because the users were us, the engineers, who knows how the system works. But the end users, who were non-techies, they made all kinds of mistakes in mapping. It was really frustrating for them and for us too. We had a lot of back and forth with the users explaining to them how to map the fields.
Most of us assume that value means delivering all the items in the backlog. We were also trapped into the same or we didn’t react well enough when we realised that what we are building is not adding enough value to the end users.
Great products can not be built with cheap methods. You need to make good investments:
Investing time for understanding the users
Investing in learning about good architecture and design of reliable systems
Investing in building a good workflow for delivering reliable software
These investments pay off in the long run and save time and effort later thus saving money for the business. But not investing on these initially may feel like you are saving but becomes costlier in the long run, by creating unhappy users. If our users are unhappy, am not sure what value we get by cutting corners.
In scope vs Out of scope
We couldn’t change much in this process mainly because of how the sales and support team worked. The sales team agree on a fixed requirements with the customers. And any time there is a change that was requested, it goes through a long process of:
Cross checking with the "agreed scope"
Back and forth trying to understand what is agreed and what is not?
At the end of the process arriving at a conclusion
I agree that users don’t know what they want and we shouldn’t agree with everything that the users are asking for. It was sad to see using contracts as a yardstick to decide whether to make changes to the product or not rather than considering whether it adds value.
Yes, we also need to consider the cost of building it too. But, if the focus is on adding value there will be multiple ways for achieving the same.
I was part of many such discussions and failed in convincing the team to change the course. Luckily, we could bring in small changes to the product which made it "useable" for the users and made them somewhat happy. But the journey to that was stressful and painful. Looking back, I never want to be in such a situation again.
One question we need to ask consistently while building products is "What am working on now how is it valuable to the users"? Jez Humble’s talk made me realise and align about the concept of value. And I would recommend you watch it too.
And how do we continuously deliver value? Modern Agile has the below guiding principles:
Make people awesome
Make safety a prerequisite
Experiment and learn rapidly
Deliver value continuously
Everything else, which is not aligned with the above four, are non-valuable and we should be spending our least amount of time in doing the same. But it is sad to see our industry doesn’t work that way. Hope things will change in the coming days by more and more people understanding the value of delivering value.