A while back, Jason Yip, tweeted about delivery of value and started an interesting thread.
Much of the discussion was about the definition of “value”. Is it specifically about revenue generation or direct customer benefit? Is it more generally about any form of value such as revenue, progress, or learning?
Value is not enough
For myself, I’ve changed the way I talk about our objectives in software delivery. While I used to talk specifically about customer value, I came to realize that there are other things from which we can realize benefit.
Today, I remind teams that they are optimizing for value, optionality, and learning.
Optimize for Value, Optionality, and Learning
Value
Value is value to the customer and value to the company. Value to the customer is capabilities that benefit the customer, be they new or improved functionality. Value to the company is increased customer satisfaction and engagement, improved efficiencies, and increased profit. Neither of these are exhaustive lists, but I hope you get the general idea.
Value is listed first, as it is still our primary focus.
Optionality
Optionality is our ability to defer decisions or change our minds.
Good coding practices increase our optionality. Code that is easily extended provides an opportunity to adjust in multiple directions.
The art of what is not done increases our optionality. When we do something light-weight to validate a hypothesis, we defer decisions until we have more data. This allows us to quickly ascertain whether or not we are on the right track and reduces the cost of change should we need to alter our path.
Learning
Learning can come from deliberate behavior, such as when we A/B test variants to see which performs better so that we can make an informed decision (see also optionality).
Learning can also happen inadvertently, such as when we launch a feature, users love it (as we predicted) and we discover that the increase in demand results in a capacity shortfall from a supplier.
When we optimize for learning, we look for opportunities to gather information and we consider how we might respond rapidly to what we infer from the information. Toward that end, we might use techniques such as canary releases and feature toggles. We might opt to release code that logs results or gathers data for evaluation without impact to the users. And we don’t allow ourselves to get caught up in the all or nothing feature fallacy.