The majority of agile related articles, blogs, books keep telling us that value is paramount and that we should sequence work by value and that we should be value driven. However, none seem to tell us what exactly value is and what exactly the author means. A notable exception would be the well thought out work available at Black Swan Farming’s Web site.
Most likely, this lack of specificity is due to the realization that nailing down the definition of value is hard and we run into all sorts of problems when we try and concretely define what that term really means.
The first question that pops into mind is: “Are we talking about customer value, or business value, or operational value?” Those three are not the same and sometimes what’s perceived as valuable from one perspective is frowned upon by another (e.g., better utilization of pizza delivery drivers/vehicles negatively affects quick delivery to customers). Additionally, the word customer is ambiguous–are we referring to the user or the buyer of our product or service?
To complicate matters further, we often have situations where something may have customer value but no business value. For example, the company may not want to invest in the development of products or functionality because it is too costly relative to the revenue it’ll provide; likely will be hard to maintain; or inconsistent with the company’s strategy, competitive positioning, or brand. In certain situations, the reverse is also true–there are things that may be valuable to the business but not to the company’s customers. A company investing in analytics and business intelligence reporting to better determine how to target customer segments, or a company consciously making a decision to deliberately lose X% the least profitable (or unprofitable) customers, are examples of items with no customer but significant business value. The same line of thinking can be applied to operational value as well–things need to be done to keep the lights on or to improve the ability of existing systems to service current and anticipated needs.
As if that wasn’t enough, a further complicating factor is that value is not a constant; it changes over time. Fashion trends and seasonal clothing are examples where value becomes negligible at the end of a narrow time window. On the other hand, the value of specific tax functionality increases dramatically the closer we get to tax season but plunges once early tax filers discover that the functionality they need doesn’t exists. A similar but smaller window opens up for late filers but that disappears after April 15th as well. What this means is that we cannot prioritize work based on “value” once and forget about it–there is a need to revisit this every so often.
And finally, we ignore the very real possibility that someone else will come along into the market, disrupt it, and refute all of our assumptions. This becomes more likely in competitive environments for high value-add products, services, or features.
A number of IT departments try to get around this problem by treating the business as a customer and by doing what the business asks for in the order asked for. But, the business is NOT the customer! They are partners that together provide value to the customers. When we start treating internal groups as customers we lose sight of the real customers and start prioritizing work based on the (often conflicting) needs or perceptions of the many internal groups.
Common ways of calculating “business value” are ROI–the benefit (or return) of an investment divided by the cost of the investment expressed as a percentage or a ratio–and NPV, that unlike the point-in-time ROI considers the flows of money over time. However, NPV is difficult to calculate accurately due to significant assumptions about discount rates and future inflows. And neither work well when dealing with non-profits–they care about other things over making financial profits. In reality, there are multiple goals of an organization:
– reduce costs
– gain market share
– build better relationships with a customer segment or intermediary (e.g., latino roofing contractors)
– increase assets under management
– code maintainability, security needs
And when we really think about it, doesn’t the, currently in-vogue, term “business value” really mean what is valuable to the company? And shouldn’t everyone and every group/function/division already be doing what the company values? Does the term “business value” as currently used really add any additional meaning?
Considering the difficulties, I’ve come to believe that we need to abandon the idea that business value is a simple formula into which we can plug-in values ahead of time and apply to feature sequencing. Instead, we need to realize that “value” requires interpretation–and sometimes a sole product owner doing all the interpretation does not make work well.
We instead need to focus on the organization’s goals and the desired outcomes. Value of proposed initiatives, then is their ability and degree to address the sought after strategic goals. Lower level initiatives/projects/whatever should be in support of those higher-level goals–the battles should help win the war.
And because, of the rapid rate of change, we cannot know up-front exactly to what degree an individual initiative will contribute to the higher-level goal(s), we must treat the proposed initiatives as hypothesis. As we really do not know with certainty what is valuable and to what extent, we encourage experimentation, learning, and continuously improving our ability to meet the desired goals.
How have you defined and used value when sequencing work?
