The Art of Business Value

by Mark Schwartz

Feature trade-offs are decisions about business value. Risk management is about business value. Communication with the enterprise is about business value. Developer morale is about business value—it can affect the company’s costs in hiring and retaining developers, and it can affect the inclination of developers to innovate new value-creating solutions.

The question of business value is the question of purpose, motivation, mission, and direction.

one of the things ROI does not take into consideration is agility itself. Part of the business value that software development can give us is the ability to respond to unknown future needs. We can build things in a way that gives us more options in the future or in a way that gives us validated learning about the environment we are in. In economic terms, we can say that software development efforts can give us “real options”—that is, options to invest more or to not invest in the future, depending on which way the market goes. This agility has true value to the organization, but it will not be accounted for in an ROI calculation.

Each of these measures has advantages and disadvantages, but they all share two characteristics: they are really just proxies for what the company ultimately values, like shareholder value, and they are unlikely to be useful to a product owner making feature trade-off decisions.

More to the point, it seems backwards: we should be valuing the investment based on its contribution to strategy, not just on an income projection.

I believe that the product owner model is based on a hidden assumption: that both the functional requirement and the security requirement can be translated into ROI terms and compared apples-to-apples.

If we really want the Agile team to be responsible for delivery of business value, we need to give the team ownership over business value discovery and interpretation, not just over delivery on requirements.

This is because adopting Agile is not a matter of learning skills or understanding a procedure; it is about adopting a set of values and principles that require change in people’s behavior and the culture of an organization.

The organization’s culture has evolved for a reason: it has been strongly influenced by what the organization has found to deliver business value in the past.

Corporate culture is not an impediment to Agile adoption; it is a valuable clue to defining the success of Agile adoption.

When we look at a rule or a piece of bureaucratic machinery, we might just as well ask what problem it was intended to solve and why it was considered to be a good solution.