Who Cares About Value?

Part of our problem discussing value is that value is a pretty elusive concept. What is valuable to me might not be valuable to you. It is easy to blur the line between what might be considered a valuable contribution and something that actually adds value to some desirable business outcome. Value can be created at many levels within the organization. You have to ask if the value you are creating can be easily translated into something meaningful to the business stakeholders. In other words, can we get the value you are creating within the organization, out of the organization?

Think about this… if you are an internal IT organization, your customers are your internal business stakeholders. The hardware and software solutions you build are enabling business processes that are valuable to the operations of your company. The value created is in the well-executed business process… not the hardware or the software you built. At the end of the day… the well-executed business process is the ultimate value proposition.

If you are a product delivery organization, your customers are the people that buy your software. Your software is only valuable to them to the extent that it enables their business processes. Value for the product delivery organization lies in its ability to build the right product, with sufficient quality, and getting it in the hands of paying customers faster than its competition. Value for the product company is derived from your customer’s willingness to pay for a product that helps them create value within their organizations. Your value proposition is not identical to that of your customer… and at the end of the day… you are one degree removed from where real value is created.

Let’s say for a moment that you are a product manager for that product delivery organization. Your goal is to get software out the door that you think your customers will use. Value is created when you define the right features and are able to engage the organization to get the features implemented into the software solution. Sure, those features have to sell, but the focus is on getting them built into the solution. Delivered end-to-end features equals value into the product. Here your value equation is two degrees removed from the real creation of value. Your software feature has to be sold to a customer and then used to actually enable the right business outcome.

What if you are a product owner working with a single team within a multi-team product delivery organization? Your customer might be that product manager trying to get an end-to-end feature out the door. Your job is to add a new feature into some major sub-component in a large systems architecture. You own that product, but it actually takes several products working in unison to deliver an actual slice of working software across the overall enterprise systems architecture. You are providing services back to the larger enterprise class system. Value to you is created when that service feature is delivered back to the project and you are now three degrees removed from the business enabling value proposition. Your service has to be integrated into the product feature, which then has to be sold, which then can be used to enable a business process.

Let’s keep going… consider for a moment that you are a technical team lead. Your customer is the product owner that defined your backlog and is trying to get enterprise services out to the Product Management team to deliver on the project outcome. Value to you is defined as some increment of working software (a user story) that enables some given transaction within the system to execute. Maybe we are accepting a data value through a system interface, transforming the data based on other system inputs, writing that transaction to the database, and giving the user feedback the operation completed successfully. Here you are four degrees removed from the business value equation. Your user story has to be combined with other user stories to enable the component feature, component features that have to be integrated into a larger value feature, sold to a customer, and then used to enable some desirable business outcome.

What if I am a developer on that team? My customer is my product owner, but it is also my team. My definition of value might be a unit-tested increment of code. If I am a tester on that team, my definition of value might be a passed test case. If I am a technical writer, my definition of value might be updated system documentation or tech manual. At this point, I am at least five degrees removed from actual business value. My work has to be integrated into the user story, which has to be integrated with other user stories at the component level, components which have to be integrated at the value feature level, which have to be sold, which have to then be used to enable our customers business processes.

So… no wonder that value is so difficult to talk about. Value is not only domain sensitive, it is context sensitive… it is role sensitive. It is sensitive to where you live in the overall development lifecycle. We have to either drastically reduce the number of hops between developer activity and the actual real business enabling value proposition OR we have to learn how to align all this lower level activity to support business outcomes that might be up to five degrees removed from the people doing the work. So next time you tell someone that agile focuses on business value… at what level of business value and how many degrees removed are you from what your customer actually cares about?

I think we have trouble selling agile because we are not talking about value at the same level our customers care about value.