I read an article on the Accurev blog yesterday entitled Three Surprises in Software Development in 2012 that got me thinking. Specifically, it was this quote from the article:
“For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality. And often all three.”
One of the large challenges I see when moving people to agile are the ideas and concepts around “business value” and “customer value”. The term “business value” is usually used synonymously with “revenue” – how much money can we make if we do this thing that we are planning to do. Usually, this number is what gets a project resourced and approved for further development.
In an agile shop, we want to focus on “Customer Value”. “Customer Value” is considered something your customer is willing to pay for. Something they will find valuable, not something you find valuable.
During the adoption of agile practices, one of the first things that needs to be done is the reframe of how people think about the work they are doing from “Business value” (revenue) to “Customer Value”. Building something your customer is willing to pay for. Thinking of it this way, “revenue” becomes a measurement of success, a “side effect” of providing value. This mindset changes the way you think about your product development and the things you do to service customers.
Lean defines three types of work that usually occur in a process:
- Work that provides value that the customer would pay directly for (Value Add Work)
- Work that does not provide direct value to the customer (Non-Value Add Work)
- Work that does not provide direct value to the customer, but is necessary in order to provide value they would pay for (Non-value Add, But Necessary)
Value add work, as mentioned above, is usually characterized as “something your customer is willing to pay for”, while non-value add is the direct opposite. A recent article I read uses blood tests as an example. Customers are willing to pay for the results, not the processes that they have to be subjected to in order to get the results (registration, paperwork, etc).
Once you identify the value add work the objective is to eliminate as much of the non-value add work as possible. You will not be able to eliminate all of it – which is why there is a bucket for “non-value add, but necessary”. Some things, like paperwork and medical history collection are necessary – your customer just doesn’t want to be exposed to it – or would not directly pay you to do it.
One of the trickiest parts of this classification is figuring out the difference between “non-value add, but necessary” and the other two. Many organizations feel that the things they do as part of their process are all “value-add” (why else would they be doing them?), while others try to eliminate anything that the customer is not willing to directly pay for (like testing or quality procedures).
Once we understand the different types of work, we have to go back to the difference between business and customer value.
There is a huge difference between something “your customer is willing to pay for” and revenue. The former is a statement of value from the customer perspective, the latter is a result of doing those things that the customer finds value in.
If you are viewing “business value” as revenue as an organization, you will make shortcuts in quality in order to hit the market or customers as quickly as possible – in most cases exposing quality defects that will effect the customer experience in a negative way. You will “ramp up resources” because the more people you have on the project the quicker you can get it done and usually you will short cycle things like testing, or code reviews because they aren’t serving the purpose of getting the product out so that people will use it.
Even worse, you will give up creative control of your product and add things based on requests of your highest paying customers – rather than think through the experience and do the things that provide your customers real value that they would pay for.
Revenue as the goal of doing something is the classic “Innovators Dilemma”. Companies continue trying to move up market by addressing their larger paying customers while diluting their product – as small upstarts develop products or processes that actually provide value – even though its not as much – at a smaller price tag. I think this “Innovators Dilemma” concept is what Steve Jobs was talking about in his biography by Walter Isaacson, when he said this:
“I have my own theory about why decline happens at companies like IBM or Microsoft. The company does a great job, innovates and becomes a monopoly or close to it in some field, and then the quality of the product becomes less important. The company starts valuing the great salesmen, because they’re the ones who can move the needle on revenues, not the product engineers and designers. So the salespeople end up running the company. John Akers at IBM was a smart, eloquent, fantastic salesperson, but he didn’t know anything about product. The same thing happened at Xerox. When the sales guys run the company, the product guys don’t matter so much, and a lot of them just turn off. It happened at Apple when Sculley came in, which was my fault, and it happened when Ballmer took over at Microsoft. Apple was lucky and it rebounded, but I don’t think anything will change at Microsoft as long as Ballmer is running it.”
Isaacson, Walter (2011-10-24). Steve Jobs (pp. 568-569). Simon & Schuster, Inc.
The goal of a product or service should be providing value to your customers, something they are willing to pay for. Revenue then becomes a side-effect – a measure of success. It becomes confirmation that you are doing the right things.
I don’t believe an organization can implement Agile successfully until this change in thinking occurs. The wrong motivators absolutely effect behavior – and most of the behaviors Agile and / or Lean try to implement is focusing on value first, providing quality software in small increments, and being able to respond to change quicker. The more you are focused on an end for you and not your customers, the more you are moving away from these values.
This doesn’t mean that revenue isn’t important – every company needs it. It means that if you are doing the right things, in the right order, it will follow and keep you going as a company.
Excellent post. I agree 100%.
In my experience as a Scrum/Agile Coach, I have also found it challenging assisting clients to make this paradigm shift from “revenue” thinking to “customer” thinking. It can sometimes be quite a task because of the natural bent of “sales leaders” to disproportionately pay attention to growing revenue almost at the expense of the real product-development efforts and improvements that assure that revenue in the first place.
Thank you, Ron.