We all want more value. Fine! But what do you mean by value? A discussion on the meaning of "value"

In the agile community there's been lately a great deal of talk about "value" and why that is more important than "process".

I also believe that we should try to optimize for value in our software environment, be it a small ISV or a big SW corporation. But what does value mean for you?

The post-agilists (people who believe they know better, and they may...) have started touting a new goal, a new Holy Graal for the software industry, that is "value". But very little is clear about what is now called "value".

I started looking around for definitions that may useful in a discussion of "value" in the context of the software development industry. Here's what I found.

The TPS way

In the early days of TPS (Toyota Production System), Taiichi Ohno defined value very simply by stating that value are that things that the customer, if observing our actions, would be willing to pay for. Example: if you write software for consumers, but spend considerable amount of time filling in paperwork that does not directly or indirectly improve the product, that would be waste and therefore "non-value add" work.
On the other hand, if you were developing software for the medical industry and spent considerable amount of time filling in forms that would ultimately lead to the successful certification of your product by the authorities, then that would be "value add" work.

Ohno's definition is simple and useful, but requires immense knowledge of your particular industry and company before it can be applied successfully. In Ohno's practice, managers would be asked to "stand in the circle" (a circle he would draw on the floor of the factory) for hours and hours. Ohno would then come back and ask the manager, "what did you observe?". If the manager would not have a satisfactory answer, Ohno would scold them and command them to continue to observe until they had found a way to improve the operation or the process in order to add more value to the product with less effort or waste.

This story illustrates a principle that is at the core of the TPS system: Deep Understanding. Inherent to this principle is another interesting concept, that it is impossible to create a "formula" for value that would apply to all situation. In other words: only you know what is value in the context of your work and company.

Now, that's quite different than what is being discussed back and forth in the agile community now.

What others say

Let's see how other people, linked to the software industry, define value:

Some of the loudest proponents of the focus on "value" are Kai and Tom Gilb. Both have a lot of credit and Tom, in particular, has a long history of contributions to the improvement of our industry so it is interesting to see what is described as "value" in their approach

Kai and Tom, in their site write a lot about "value", in fact they talk about many different types of value. Here are some:

• value requirements
  
• value decisions
  
• value delivery (as a verb/action)
  
• product values
  
• value product owner certification (yes, certification)
  
• value management certification (again: yes, certification)
  

About requirements they write that they should be:

"Clear, Meaningful, Quantified, Measurable and Testable".

These Value Requirements seem to be designed to structure and formalize the specification of "values".

Interestingly, they clearly assign Scrum a role that has (at least in their depiction) very little to do with "value management". See for yourself.

The emphasis is on "scales" or quantification of value:

Stakeholder Values are the scalar improvements a Stakeholder need or desire.
Product Qualities are the scalar attributes of a Product.

These are important additions to the effort to define value, but not really conclusive or contributing a clear definition of what value is. Ohno's definition was clear, but impossible to measure/understand without a deep understanding of one's business.


In VersionOne's blog Mike Cottmeyer argues that:

Lean tends to take a broader look at value delivery across the entire value stream... across the enterprise... Scrum by it's very nature tends to look only at the delivery team.

(...) the Lean folks say that Scrum focuses on velocity and Lean focuses on value... "

This in itself is not really helpful in defining value, but it helps us make a distinction, if we agree. The distinction is that delivering more features may, or may not, deliver more value. They are not necessarily the same.

This argument is easy to make when you look at the market out there and see that many products with "less" features tend to deliver the same (if not more) value to their customers. (examples include the irreverent 37signals crew as well as Nintendo or Apple).

In this non-exhaustive research I came across another interesting definition of Value. This one by Chris Matts:

Value is profit

Although this may seem logical, I doubt that your customers would agree that the more profit you make the better "they" feel. In fact I would argue otherwise. If profit is your only measure of value you will be driven to make decisions that effectively reduce the value delivered to your customer, even when your profits are increasing.
Now, it is important to understand that profit has to be part of the equation, but is also important to understand that, from your customer's perspective, your profit is only value in the measure that allows you to continue to deliver value to your customer, not as an absolute value.

Conclusion

What can we conclude from this superficial evaluation of the discussion out there?

Well, for starters we can easily say that the discussion about "value" in software development is just about to get started.

We have some properties that help us understand and define value:

1. Value is that what the customer, if observing our actions, would be willing to pay for. (Ohno's definition)
   
2. Gilb says that value must be translated in some form (Value Requirements) and that the key characteristic is that these Value Requirements are Quantifiable and Measurable
   
3. Mike Cottmeyer, on the other hand, states that Features (stuff that gets developed as described in requirements) are different than Value. This means that even if we would have Value Requirements they would not necessarily add value from the customers point of view.
   

Mike's and Gilb's discussions seem, on the face of it, to be contradictory so we are left finally with a definition (Ohno's) that is useful but very hard to apply.

So, for the time being, Value is something that we cannot easily define "a priori", and for us to be able to define it requires a deep understanding of the business we are in (to be able to "guess" what the customer would pay for).

I'd say that we are still very far away from a viable (mass-usable) definition of Value for our industry.

What do you think? Have you defined value in the context of your project/company? What was that and how did you reach that definition?

Photo credit: Will Lion @ flickr