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

Another post in favor of another User Story format

Some time ago I wrote a post supporting the idea of a new template for the User Story. In that post I tried to explain why we should bring the "value" (because) clause to the fore, to make it the most important clause of the User Story template.

Then John Arrowwood commented on that post and made a reasonable argument to stick to the "old" (or traditional) format for User Stories.

This is a second post in defense of the new template, where I try to explain why the "value" clause in the user story should be brought to the fore, to be the most important clause in the User Story. Here's the template I propose:

• In order to "benefit/why/value"
  
• As a "user role"
  
• I want "feature/functionality"
  

Although I don't see any logical flaw in John's argument I don't agree with it. The reason is that in reality I don't see that people understand the ultimate goal of the User Story which is to justify every functionality in terms of what value it brings to the user.

No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it. Normally the User Story writer will not understand the real "value" for the user before I do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.

I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. Writing an obvious "value"-clause delivers zero value when communicating the user story. Remember that it is the "unexpected" and "non-obvious" that actually delivers value, because it contains information that was not obvious to the reader.

Here's an example: everybody knows that as a user of Yahoo! e-mail client I want to save emails sent and received because I may want to return to some business-critical information later on, what not everybody knows is that as a Gmail user I prefer not to have a folder structure to archive old e-mails because it's easier to search than to create a folder system for archiving.

If you take as value the "archiving" then you will create a stupid folder structure for people to be able to "store" old e-mails. However if you take the "finding easily a relevant e-mail" as the value people are looking for, you may start to think twice and ask yourself if all users (all over the globe) are really librarians that think in archive-system terms. Guess not.

When you write a User Story start from the value. Always. No Exception. Ever. Start by asking yourself what does the user/customer really want to do. I mean really! (hint: seldom customers are happy with just using your product, they normally want to accomplish something!)

The value part of the User Story should be the non-obvious part of that value, the obvious explanation for a User Story does not deliver any information to the person downstream that will read the story and have to implement it.

I don't expect everybody to understand this, then again I don't expect all companies to create great products.

Learning to be better is not mandatory. Then again, neither is survival...

The value Black Swan (or the killer improvement in software development)

Thinking back to how we value our work, we must recognize that, in software, quantity is not value!

The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) -- or in Black Swan (TBS) parlance: velocity is a variable from Mediocristan. However, the value of each item does not follow a Gaussian -- in Black Swan parlance value per item is a variable from Extremistan. It is conceivable to think that we can have one item that accounts for 90% of the value we deliver, in fact that is most often the case, but even knowing this we may underestimate (or lack understanding of) the real extreme value of an item.

What does that mean in practice? How does this affect our planning or item selection? Can we in anyway predict the value? (not, according to TBS).... The payoff of a "large value" item would however be much bigger! (altavista vs Google)

In my view, given the current knowledge I have of the software development process/world, I'd say that this assertion means that the most value in a software development process can be obtained by concentrating on selecting those extreme value items that can make the software a success. Current science and practice on this, however, seems to lack any repeatability or reliability when it comes to reliably selecting the "killer" features... Do you have any links to papers/articles about value focus in the requirements selection process? link them up in the comments section.

PS: if you don't know what a Black Swan is, you better read this, or the book.