Business Value vs. Customer Value

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.

Recipes are for Learning, not for Real Life

Recipe BookPeople like recipes. We’re always looking for the next ten step way to improve what we do and how we do it. We see it in leadership trainings, “methodologies”, and pretty much any self improvement or team productivity books that we read. Each of the above give frameworks along with classifications of things that you can use to solve a particular problem.

What gets lost a lot of the time is that the classification of things and the frameworks are written to teach, not to use in every day life. While you might have to consciously think about the way to classify something at first, while you’re learning, the key point of these things is to give you a way to classify and deal with information while you are learning. At some point, the idea is that the framework will fade away and you will innately have the tools at your disposal, without having to think of the distinct classifications or step by step instructions to deal with them.

Its like learning to ride a bike. When you are learning to ride a bike, you learn balance, steering, and the fact that you have to push one foot at a time on the pedals to achieve the motion you need in order to propel the bike forward. At first, its very awkward. Your steering is shaky, you don’t pedal fast enough to get the inertia needed to move the bike forward, because you are thinking of all of the things you need to do at the same time to achieve your goal. Pretty soon though, you internalize all of the independent skills you need that make up this thing called “riding a bike” and it becomes one thing rather than many concurrent things you have to think about. Pretty soon, you are modifying or adding to what you know and doing things like riding no-handed, wheelies, or whatever other things you can think of that augment your experience of this thing called “riding a bike” that makes it a little more “your own”.

Methodologies and religious arguments around software development have always put me off. When I’m asked to participate in a “methodology” discussion I usually cringe, because I know that 9 out of 10 people feel that the methodology as it is written is the goal, rather than taking the methodologies as a set of tools that are used in the learning stage to develop competence and later modify for the environment in which you work. This tends to get lost most of the time and you find teams and people doing things as they were specified in the recipe, whether they are useful or not, rather than adapting the tools – or even throwing some of them out if they do not apply.

“Agile” methodologies are a perfect example of this. You have specific formats for standups that are interpreted literally, specific tools like automated builds, unit tests, user stories, and burn down charts. Some methodologies include specific artifact definitions like activity diagrams, object diagrams, 4 + 1 architectural diagrams. In most cases you find people using all of them as they were specified in the book because they haven’t moved to the point where they understand the purpose of these tools, what they accomplish and how they do or do not fit together for a particular situation.

Agile software development is not the format of the standup or the fact that you have automated builds. As far as I can tell, Agile software development achieves the following:

  • Get the customer involved and the team communicating.
  • Break the functionality required into small, incremental, implementable pieces that are prioritized around both business and technical dependencies – with the goal of creating production ready code. Small iterations also give you the ability to adapt to changing requirements. What seems important at the beginning of one iteration might not be as important as something in the next iteration – so you plan incrementally.
  • Create production ready code at the end of each iteration, with rapid feedback cycles – this is the purpose of unit tests, and automated builds – to be able to “stop the line” when something breaks without a lot of manual intervention – and to deliver “just enough value” as soon as possible.

I think the problem is that most of the time people do not look at the philosophy around a methodology. Most of the tools that appear in these methodologies have a purpose to get to a certain philosophical goal, like the bullets listed above. Unless you understand the goal, you can have perfect stand ups and not ever really “implement agile” in the way that it was intended.

Related Articles

Does The Language We Use Make A Difference?

I was reading the article Run IT as a business — why that’s a train wreck waiting to happen and it got me to thinking … which can be dangerous. The article specifically talks about how the idea of “running IT as a business” has unintended consequences, one of which is thinking about folks outside of IT as “partners” or “customers” and how it effects the behavior of the organization.

How does the language we use effect how we behave? Is it possible that the common practice of using terms like “partner” and “customer” causes us to behave in such a way that we are disconnected, at least mentally or emotionally, from the people that we try to make a difference with?

This has long been a pet peeve of mine. I think these terms cause an artificial separation between groups. An example that I used in a meeting recently:

At a company I worked for at one time, it was impossible to get a software release out without incident. There was not enough structure, and it was obvious that tools were required to automate the process that were not available at the time, for the particular platform we were working on.

Thats right folks, this was a time in which even Capistrano didn’t exist.

I wanted to help solve the problem. At the time, with the specific deployment model this company used, solving this problem required access that I did not have. Because I was not part of the group that got this access, I was not able to get it – until I transferred.

Yes, I actually transferred to this group to solve the problem. Two days later, I had the access required.

Same person – different access.

Much feverous work ensued. Finally it was done. The problem was solved.

So I transferred back to my previous group. Guess what went with the transfer?

Yep – the access.

Same person – different access.

It sounds ridiculous doesn’t it? But it happens – a lot.

In corporate culture we tend to use terms like “Partner” and “Internal Customer” to reference each other. I think it often causes unintended consequences.

It’s kind of funny. As I was telling this story, I thought about the story of the Sneeches. You know, the folks who some had “stars on thars” and some didn’t. Each were treated differently according to the status of the markings on their bellies. In the end, they were all the same – they just didn’t know it. Actually, in the end, when the markings were automated, no one knew Who was Who.

Corporations spend (and waste) a lot of time fighting who is at what level, whose responsibility is whose. Defining roles and their responsibilities rather than getting things done. Its not that defining roles and responsibilities is bad, but we tend to confuse people with roles and in doing so keep them from performing at their full potential. We fail to realize that people may have many skills and can serve multiple roles.

The next time you use the term “partner” or “internal customer” – think about this a bit. It might make you think a little different. It’s definitely been something I’ve been thinking about lately.


I received this email from a former employee today:

I was reading a book recently, called “The Goal” as I was flying to California. It is about a big turnaround in a manufacturing plant in less than 3 months.

It is a very nicely worded book. The reason I am writing this mail is because there is one character in that book, Jonah – a professor – and he is a management consultant and the kind of questions he asks the main character Alex, the Plant manager are sufficient for him to ‘click’.

It was so interesting and I was smiling whenever Jonah showed up in the book since he reminded me of you, the way you would ask me something when I used to work for you.

If you get a chance do read that book. The book is basically about removing bottlenecks in operations.

Its nice to feel like you made a difference. I would never describe myself as a Jonah, but its nice to know someone would.

Agile / Lean or Common Sense and Permission To Change?

As anyone who reads this blog regularly knows, I’ve spent a lot of time over the last 3-4 years studying agile methodologies and most recently lean concepts and principles. I have most recently been reading a couple of books by Ricardo Semler, who runs his company in a completely democratic way – doing away with all top down authoritarian management principles and allowing the employees to make decisions on dress, salaries, where they work, when they work, and most importantly, how they work.

I remember when I had first read the book Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle and I had sent an email to my manager with a link to the book and the small sentence fragment “common sense codified”. We began experimenting with Scrum within my group, but it was very difficult to get other groups on the same page. We wound up with a lot of sprints that ended when things left development and entered the “normal corporate process” to finish things up and get them to production. We also had a lot of conversations around whether what we were doing was “standard process”.

As I started reading books on TPS and Lean, the same thing occurred. It struck me how most of the things that are characterized by “lean” are just common sense principles explained in such a way that they sound like a “process” that manager types can “buy into”. But really, they work because they make sense – and people have the permission to standardize and then change their work rather than having things written down and subsequently treating these processes like they are set in stone. You can’t change them unless you go through an agonizing approval process up the management chain.

Over the years, I’ve read and listened to many podcasts talking about the same things going on in other companies. People struggle to be able to change the way they work because they have to get “management buy-in” to take action. So much wasted effort just to try something new.

Interestingly, once the “buy-in” occurs, over and over again people try to “implement Scrum” or “do XP”, mostly by the book, and do not throw out things that do not work for the group. For some reason, we all think we have to be a part of some “methodology” in order to be effective.

One of the most fascinating things about Semlers company is the explicit trust and ability to control ones own destiny that the employees of Semco seem to receive. I ran across a particular section of the book where he was talking about the process improvements that “just started happening” due to this culture change and I found some interesting similarities to lean that I thought would be interesting to highlight. He starts off with:

The factory committee spun off groups that studied the plants products and how the workers made them, looking for ways to save time and make improvements. These teams weren’t created by Semco; they formed spontaneously, as the bracing winds of democracy swept through the food service equipment unit, and often met after hours or during lunch.

Interesting, employees actually wanted to do a better job and self organized because they could.

He goes on, talking about some of the changes:

One group restructured the dishwasher assembly line, changing it from a sequential assembly process to a batch concept in which dishwashers are assembled in twos and threes by teams of workers that do many different tasks and spend the time between batches prefabricating the components they will soon need. They also came up with a system in which all the parts for the dishwashers were stocked in open racks in the middle of the factory. Metal tags, green on one side and red on the other, hung on each rack, and the workers would flip the tags when they saw it was time to reorder, ensuring a steady supply. This was a big improvement on the traditional assembly line, in which dehumanized workers have no role in decisions regarding the production process.

What we see here are people electing to move from an assembly line to, basically, work cells implementing small batches of inventory with workers that are skilled in multiple areas. They even set up a “Kanban” system, though I doubt they knew it, where they had visual cues of when parts needed to be supplied.

Note that not once in these paragraphs does he mention the word “lean”. There was no implementation of “lean”, no “lean” or “continuous improvement” initiatives. This just seemed to make sense to the people doing the work and since they were allowed to do it – and knew enough about the overall process rather than just their small piece of the overall process (i.e. they were multi-skilled), they were able to see the obvious and execute it without all of the red tape – and get great results for the company.

He goes on:

The strength of these groups was their diversity. They included factory workers, engineers, office clerks, sales reps and executives. They didn’t have a formal head; whoever showed the greatest capacity to lead got the job, calling meetings and moderating discussions. In more than one group, a shop-floor worker guided professionals. Instead of a seniority system, or boxes on an organizational chart that guaranteed power, the groups were held together by a natural system of collegial respect.

Again, you hear this a lot in TPS. People are trained from the bottom up in the company and have skills in multiple areas. While there are “leads” that are responsible for a product line, everyone has the ability to lead when they are the most skilled for the job at hand.

The only vague reference to lean that Semler makes in this passage is the following paragraph, where he draws similarities and differences between what Semco did and TPS (though Toyota is not explicitly stated):

There are similarities between this system and the Japanese approach to organizing manufacturing operations, but also important differences. In our groups, younger members didn’t automatically submit to their elders. Moreover, once a team decided an issue, it stayed decided. There was no approval needed to make a change. Then again, there were no special rewards for new ideas. It was a spontaneous process; people participated only if they wanted to.

As I read this it really got me thinking. In most of the process agile / lean related books that I’ve read there seem to be a few common themes:

  • Trust people to do the right thing for the company
  • Give them freedom and authority to work the way they want to
  • Push decisions down the chain as far as possible
  • Work in small batches and change things that aren’t working
  • Allow those who are capable of leading to lead, no matter what their title or position is
  • Put quality checks in place – whether it be test-driven development, or quality checks at each step in an assembly
  • Fix problems at the core and stop the line as quickly as possible – in development this would be TDD and automated builds. Once a problem is found, find the root cause and put a test or quality check in place to ensure it doesn’t happen again
  • and finally, Trust people to do the right thing for the company

One more principle that I would add would be “tolerate mistakes”. Many of the issues that I’ve come across with other groups is that if they make a mistake they feel they will be punished. I’ve had great success with my team in articulating that I know mistakes will be made, but I want them to be made once, a lesson learned, and things put in place (usually automated) to ensure they won’t happen again. I’ve found that if people know it is expected that mistakes will be made, and everything doesn’t have to be perfect, they are more receptive to trying something new.

But I digress.

What Semler’s story shows me is that if people are given the freedom to work the way that is most effective, they will. More than that, if you invest in them with trust, they will want to do these things as their commitment to the company will obviously go up based on how they feel they are treated.

Semler uses a key phrase throughout his books that is repeated over and over. “Treat people like adults”. Semco, Toyota, Amazon and Google seem to do a really good job at this, as I’m sure most high functioning companies do. Read this article called The Google Way: Give Engineers Room and you will see the same concepts outlined in the excerpts on Semco that I have just written about. It seems to be a common theme.

So my real question. Is methodology and process really the answer, or is it deeper than that? Is it the way we treat employees that cause inefficiencies? If it is, if we took this base principal of trust and actually implemented it, would our employees come to the same conclusions as companies like Semco, Toyota and Google?

I think they would, because the principles and processes implemented by these companies are really just common sense without all of the complications of “process” and authoritarian management. They encourage workers to work outside their “box” and learn what they need to learn to be more effective. I would guess these employees feel valued, because they can constantly improve themselves rather than just “be the guy that puts the screw in the hole”. When you are allowed to improve yourself, your commitment rises to those who “allow” you to do so. What you wind up with is a highly efficient company that can change on a dime because people are allowed (and encouraged) to change and improve.

Most interestingly, the processes wind up looking “agile” or “lean”, without all the cruft of trying to follow a cook book.

Am I officially becoming a hippie, or does this line of thinking make sense? Let me know if I should go join a commune.