|
|
In search of Lean Business Value
I’m looking for useful and usable definitions of Business Value. Lean should have a lot to say about value (when they’re not talking about waste): Value Stream, (non-)value-adding work, Value Stream Manager.
 And yet, a book like Creating a Lean Culture: Tools to Sustain Lean Conversions that describes Lean Management doesn’t define what Value is or how you define it. The Lean Manager’s job is to ensure that the right thing is done the right way. “The Right Thing” has been defined beforehand and the Lean Production Manager ensures that the value (as defined in the product to deliver) is delivered quickly and efficiently. In production, quality has been defined and is constant (except when the product changes). The emphasis of the production manager is on “the right way” and increasing flow by reducing waste because those are the only variables the production manager (and workers) can influence.
Implementing Lean Software Development: From Concept to Cash has a separate chapter on Value, which comes just before the chapter on Waste. The chapter doesn’t really define value. The closest to a definition of value comes from Lean Solutions: How Companies and Customers Can Create Value and Wealth Together. What do customers want?
- Solve my problem completely
- Don’t waste my time
- Provide exactly what I want
- Deliver value exactly where I want it
- Supply value exactly when I want it
- Reduce the number of decisions I must make to solve my problems
This gives us a good set of criteria to check, because each of these criteria reduces the customer’s value if done badly. How do we know what customers value? The advice is to understand the customer by:
- Living in the circumstances of the customer, for example when the chief engineer of the Siena minivan cruises from Canada to Mexico to understand how to improve the car.
- A similar technique is “apprenticing”, where we learn how to do the work from a user
- Observe real users at work
- Perform usability testing to ensure we haven’t reduced customer value
Toyota Way Value
If we look at the 14 Management Principles from the World’s Greatest Manufacturer from the Toyota Way (p. 37) we see that Customer and Value are only mentioned a few times:
- Generate value for the customer, society and the economy – Principle 1: Long Term Philosophy
- Quality for the customer drives your value proposition – Principle 5: Build a Culture of stopping to fix problems, to get quality right the first time
So, Value == Quality for the Customer.
Chapter 5 describes how Quality for the Customer was defined for the Lexus.
- Look at who the competitors are
- For each competitor, what do customers like and dislike about them?
- Rank order the quality attributes
- Select a small number of target qualities (in this case: top speed, fuel consumption, noise, aerodynamics and weight)
- Define constraints and basic needs (reliability, safety, resale value, interior…)
- Set targets for each of the quality attributes
Now, we know that if we ask potential customers and users what they like in existing products and want to see in the new product we’re not going to get a very exciting list. In “Kano model” terms, we’re going to get the “must have” basic needs and some performance needs (“It uses a bit less fuel than my current car? Nice.”). Where do we get the exciter features that make the difference?
In this case the exciter was the word AND. The new car had to beat its rivals in all of the target qualities: lighter AND faster AND more fuel-efficient AND quieter AND… than the leader in each quality.
Toyota Production System Value
 The Toyota Production System (and all the material derived from it) doesn’t say much about value because value has already been defined and is a constant (or constraint) for production. The Toyota Product Development System has as its first principle “Establish Customer-Defined Value to Separate Value-Added from Waste“.
How is this done?
- Appoint program leaders who have the background and experience to establish an emotional connection with the target customer
- Perform Genchi Genbutsu (Go See the Actual Work) to see the customer in action in their environment
- Create a vision for the product which includes quantitative and qualitative goals (using “Value Targeting Process”, as described above)
- Create a concept paper based on thorough discussion, information gathering and consensus-building
- The leader and the concept paper guide development throughout the project
- The project is broken down into functional teams, each with their own leader who applies the same process recursively, so that each team has a customer perspective
- Value targets are set
- Cross-functional teams work together to find ways to achieve all the value targets
Business Value is a Model
At Agile 2008, Chris Matts and Andy Pols had a session about Business Analysis. They made one statement which clarified what I was looking for and what I was doing:
Business Value is not a value. Business Value is a model.
There’s not just one value or one quality: different stakeholders all value lots of (conflicting) things. Moreover, value is not static. For example: whether I deliver a car (or a software project) next week or in six months can have enormous effects on your valuation of that exact same product.
As with all models, much of the value comes from the thinking about value and the modeling, not the final model. When I come onto a project, I will always ask about the Business Value Model. If you have an explicit and agreed model, decision-making will be much more effective. If you don’t have an explicit model, that tells me a lot: we’re going to have constant discussion about goals and value. Even worse, some teams have an explicit model (“espoused theory“), but use another model (“theory in use“) which leads to no end of conflicts and dysfunctional behaviour. I can usually deduce very quickly what the real model is from the actions of those involved. That’s why I like to add a third part to the statement:
Business Value is not a value. Business Value is a model. Business Value models what you value.
So… How can build a Business Value Model in our work?
Pinocchio: On Becoming a Lean Leader
Portia Tung and I will co-present the opening keynote “Pinocchio: On Becoming a Lean Leader” at the Agile Turku Day 2010 in Turku, Finland on March 17th 2010.
Come and play with us to sharpen your leadership skills!
Pinocchio by Enrico Mazzanti (1852-1910) – the first illustrator (1883) of Le avventure di Pinocchio. Storia di un burattino – colored by Daniel DONNA (via Wikimedia Commons)
Value is relative
So, if Value is relative to each person or organisation and their situation, before we can start definining Value we have to find out who’s value is important for our project. Who are we doing this for?
The Dramatis Personae
We start every project by finding out the stakeholders we need to satisfy. This, like all other agile analysis activities, is an iterative process: we start off with an initial set of stakeholders and update our list when we discover more information. We need to find at least three types of stakeholder before we can start talking about value:
The Client
The first and most important stakeholder is the Client. The Client commissions or purchases the product we create. The Client is responsible for
- Setting the goals: “I need these results…”. The success of our work will be judged against the fulfilling of the needs.
- Setting the constraints and boundaries: “You can’t touch this…”, “You have to….”. The constraints and boundaries set non-negotiable acceptance criteria for any solution we might come up with.
- Providing the team with resources: money, skills, hardware, software, data, information…
- Defining the Business Values of the product in function of time. Value isn’t static, it changes with time. For example, a games that’s released in time for the Christmas holiday gift shopping, has a lot more value than one that’s delivered a few days later. A new version that’s available at a trade show is more valuable than one that’s delivered the day after.
- Resolve issues, remove impediments and manage risks for these areas of responsibility.
At the end of the day (project), it’s the Client who’ll decide if this project or product is a success. They define value and decide whether it’s been delivered or not.
Some other names for this role are: Purchaser, Buyer, Sponsor or Executive sponsor.
The Customer
The Customer works for the Client to fill in the details and content that will allow us to achieve the given goals with the given constraints using the given resources. The Customer is responsible for
- Setting intermediate goals which, when achieved, will let us achieve the Client’s goals. Achieving these intermediate goals will tell us if we’re on track to deliver the goals of the Client.
- Defining the features to be delivered to implement the goals.
- Defining the Business Value of features, within the context of the Business Value Model of the Client.
- Defining the Acceptance Criteria of the features that allow us to unambiguously determine if the feature is done because it achives its goal.
- Follow up the state of the work, verify that the resources are being applied well to achieve the desired goals.
- Resolve issues, remove impediments and manage risks for these areas of responsibility.
Some other names for this role are: Onsite Customer, Product Owner or Product Manager.
User(s)
I’m not too fond of the word “User”, but for now this word stands for those people who will use the product we’ll create or change. As soon as we’ve identified them, we describe them using their role, group, team or organisation name so that we’re rid of the ugly word user.
If we already have people using the product, we go and see them (“Genchi Genbutsu”) so that we understand what their context and needs are. If the product is new, we may have to invent personas (with the help of Product Management and/or User Experience) and imagine what their context and needs will be.
Discovering stakeholders with the Nine Boxes interview technique
The Nine Boxes is a simple (but very difficult) interviewing technique from the Solution Selling™ sales process. We ask questions about three topics:
- What problems and opportunities does the organisation face?
- Who is impacted by this situation? How are they impacted?
- What would a future in which the problems and opportunities have been dealt with, look like? What changes for those impacted people?
The answers we get from the “Impact” topic give us a first list of stakeholders. The person managing all the impacted people is a first candidate for the Client role.
You can download the Nine Boxes game from the Agile Coach site. Try it, it isn’t as easy as it sounds. Once you master this technique you can get a lot of useful information in a short time.
Discovering stakeholders by going to the Gemba
Interviewing gives us a lot of useful information, but we don’t believe everything we’re told. Going to the place of work (“Gemba”) and seeing the work being done allows us to verify what we’ve been told and discover a whole lot more useful information. You can try two simple observation techniques:
- Stand in a circle: you draw a circle on the ground and stand in it, for at least an hour. Observe what’s happening. Note things that go wrong. Note causes of things going wrong. Note ideas for improvement.
- Staple yourself to a work order: select a client request and follow it through the process to really experience what happens in a process (which might be very different from what you’ve been told should happen).
While you’re at the workplace, take the time to talk to the people doing the work.
That’s just the start!
We’ll discover more stakeholders as we go along. These three stakeholders (with at least one type of user) are the minimum to even start to talk about value. Yet, surprisingly many projects I encounter lack one or more of these stakeholders. Agile projects typically have the Customer role, but they have problems fulfilling their responsibilities because the two other stakeholders are unclear:
- If it’s not clear who the users are, if we overlook some types of users or if we only pay lip service to the notion of customers (like on the “agile” project where for the past five years nobody in the team had actually seen a user using their product) selecting the right User Stories and defining their value (to prioritise) becomes difficult. Next time you have trouble setting priorities or selecting stories, ask who the users are and what their goals and needs are.
- If it’s not clear who the Client is, we don’t have a clear view of the overall goals and needs. We don’t have priorities between different stakeholders’ goals. We don’t have a Business Value Model that tells us what the value of the product will be. Next time you have trouble defining the Business Value, ask who the client is. Who takes care of the responsibilities of the Client? The Client decides if your work is successful, so you’d better know who that person is and what they define as success.
- If there’s more than one person in the Client role, your project will be troubled by endless fighting, shifting priorities and many changes. The Client is one person who has the authority and knowledge to take the necessary decisions. If there are arguments about value and priority, ask who will deal with this risk.
- If the appointed Client doesn’t have the authority and control over the whole area you’re working on for this product, you’ll be mired down in endless debates and requests with those who have the authority. Either reduce the scope to the span of control of your Client or find a Client with a larger span of control.
Whenever I look at a project, these are the first three questions I ask:
- Who is the Client?
- Who is the Customer
- Who will use what the project makes?
A large number of project problems and project failures are caused by not having an answer to one of these three questions.
When we have the answer to these questions we can start to ask questions about value.
Note: Dealing with constraints and boundaries
I always find constraints and boundaries worth time investigating in depth
- Constraints that mandate certain features often lead to complaints from the team as they have to implement “zero value” features. These kinds of features are “Table Stakes” or “Must Be” in the Kano Model: the whole product has no value unless those features are there. For example: in a regulated industry, all the work and deliverables to pass a required audit may not seem to have a value, but they are the price to pay to be in that market. We can include these kinds of features in two ways: additional stories (for example: “TO assess what needs to be tested AS A certifying authority I NEED a list of changes in the release with their architectural impact“) or as Acceptance Criteria that apply to all User Stories (for example: “Is this User Story’s design documented in the architectural impact document?” ). How do we prioritize these stories? Simply, they get no business value but get marked as Table Stakes. When planning, these go to the top of the priority list.
- Constraints that mandate certain technologies to be used may put undue limits on our creativity, but can make good sense: if the product is to be maintained by the Client’s organisation it should use technologies with which the Client’s people are familiar.
- Being able to break through constraints or boundaries can create an innovative and unique product. Systems Thinking and Conflict Resolution techniques can be very helpful here. Always question constraints, boundaries and the assumptions behind them!
Let’s have a look at how others define (Business) Value
Before starting to find stakeholders and discovering what they value, let’s have a look at what other people think of Value. Because real Customers don’t come to us, we can have a look at what customers might read.
Understanding Organisations
“Understanding Organisations” by Charles Handy doesn’t contain any orginal ideas but does give an overview of a lot of economical and social theories about organisations and the people in them.
However, the index doesn’t have an entry for “Value” or “Business Value”. It doesn’t even have an entry for “Customer”! The chapters on “Designing the Organisation” or “The Future of Organisations” never once mention customers.
Wow. Just wow.
The Table of Contents isn’t very useful either: Part Three consists of “Chapter 1” to “Chapter 12”. No chapter headings or titles to help me find the information I want.
Next!
Competitive Advantage
“Competititve Advantage” by Michael Porter is one of those classics that businesspeople just have to read. Summary: in a typical four-quadrant model, Porter shows that there are four generic competitive advantage strategies:
- Cost Leadership: become the low-cost producer in your market. This allows you to have the lowest prices and/or the highest margins. If other companies in the same market try the same strategy, a price war ensues.
- Differentiation: seek to be unique in your industry along some dimensions that are widely valued (aha!) by buyers.
- Cost Focus or Diffentiation Focus: the same as above, but focused on a narrow segment of the market.
Porter uses the concept of a “Value Chain”, where primary and support activities within the organisation together create value. Different Value Chains are connected in a “Value System” as the outputs of one organisation’s Value Chain create the inputs for another organisation’s Value Chain.
In competitive terms, value is the amount buyers are willing to pay for what the firm provides them. Value is measured by total revenue, a reflection of the price a firm’s product commands and the units it can sell.
The book touches on the importance of “Buyer Perception of Value”: it’s not the “objective” value delivered (whatever that is), but the buyer’s subjective assessment (based on incomplete knowledge) that’s important.
The price premium a firm commands will reflect both the value actually delivered and the extent to which the buyer perceives this value.
Therefore it’s important to know who the real buyer, the real decision maker, is and how they define value for themselves and their organisation. Because the Value Chains of seller and buyer are part of one system, an important part of delivering value is knowing how the seller Value Chain impacts the buyer’s strategy for their Value Chain. The book never uses the word Systems Thinking, but thinking about Value Chains organised in a Value System is a start.
I’m not too fond of the Value Chain concept with its fixed “Primary” and “Supporting” activities. It all starts to get a bit messy when we break the organisation into multiple Value Chains with common supporting activities and we get into Activity Based Costing territory. We do use value-delivering and supporting business processes in our analysis.
EVA and Value Based Management
A more recent book (2001) about “EVA and Value Based Management” by S. David Young and Stephen F. O’Byrne posits that there’s only one relevant type of value: Shareholder Value, not company value or customer value.
Shareholder Value is based on Economic Value Added (EVA = net operating profits – cost of capital). Market Value (the value shareholders care about) is then the invested capital + the capitalized value of current EVA (based on the estimate that the current EVA level will be maintained) + the capitalized value of expected EVA improvements (based on the estimate that the company will improve their EVA in the future). That’s a lot of estimates.
Simply put, as companies outperform or underperform EVA expectations, investors convert these surprises into value.
If Shareholder Value is the only reasonable measure, then Value Based Management is very simple: tie executive compensation to EVA. If the executives’ wealth is aligned with the company’s (shareholders’) wealth, the executives will implement strategies that increase this wealth. The actual strategies to follow are left as an exercise for the student. It turns out that things aren’t quite as simple as they sound, even when the risks that the authors acknowledge are taken into account.
… short term finance measures, including current EVA, are relatively less informative about managerial effort expended in areas that are most useful to long-term value creation.
Anyway, for our purposes this definition of value is unusable. The book acknowledges this measure can only be used at the top and then only as a lagging indicator. The solution is to use Value Drivers, a set of financial and non-financial measures which will lead to the desired results. These Drivers must include both current situation and future growth to avoid a focus on the short term. The important point is to take a Systems Thinking approach:
… the two most important success factors in implementing a balanced performance measurement system are whether top managers have clearly articulated the firm’s strategic vision and whether they have identified the key performance indicators for measuring the success of that strategy…. there must be a clear cause-and-effect relationship between the measures that are chosen and the company’s strategy.
Danger: measure the right things, the right way. Some tips from the book:
- Clearly articulate a strategic vision, consistent with the goal of creating value
- Seek input not only from internal sources but also from customers and suppliers
- Let measures evolve over time, as conditions and strategies change
- Link key measures to all levels of management compensation
- Cascade measures deep in the organisation
- Cap the total measures reported to top management at 20 or fewer
- Report key measures at least on a quarterly basis, preferably on a monthly basis and even more frequently if information technology allows [ed: ditch the information technology if it doesn’t allow this :-)]
The book is very much financial/accounting oriented. Therefore, I was pleasantly surprised by the use of “Working Capital Requirement” (WCR), which includes in capital (and thus capital costs) lots of things that traditional accounting would consider as assets (inventory, unpaid invoices). The financial analysis shows how shortening total cycle time decreases WCR and dramatically improves profitability. As Taichi Ohno said “All we are doing is looking at the timeline from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that timeline by removing the non-value-added wastes.” And you get improved quality and reliability as a bonus!
The Toyota Way
In contrast to the short-term stock market focus, “The Toyota Way” describes how to “base your management decisions on a long-term philosophy even at the expense of short-term financial goals“.
The Toyota Motor Manufacturing North America mission is:
- As an American company, contribute to the economic growth of the community and the United States
- As an independent company, contribute to the stability and well-being of team members
- As a Toyota group company, contribute to the overall growth of Toyota by adding value to our customers
A balanced view, where the survival of Toyota is based on satisfying customers and stakeholders both inside and outside the company.
User Stories Applied
Closer to home, how does the Agile literature deal with Business Value? “User Stories Applied” by Mike Cohn has no index entry for Business Value and only one for Value. Discussing the “INVEST” criteria for User Stories, Mike refines the “Valuable to the Customer” criterion to “Valuable to Purchasers or Users”. Why the distinction? The Purchaser (the person who buys the software) may have additional requirements that aren’t expressed (or even visible) by the users of the software. In the same section, the book says that User Stories must be “Valuable for the Customer and the users”. The best way to ensure that this is true is to let the Customer write the stories.
I see a few problems with this:
- Who is the Customer (who writes stories) and what is their relationship to the Purchaser? We define two roles: the Client (a bit like the Purchaser) who’s responsible for overall goals, resources and constraints and a Customer who’s responsible for the content that achieves the goals with the given resources and within the given constraints.
- There are more people, roles, teams, organisations (in short: stakeholders) affected by a project/product than just the purchaser and the users. How do we ensure that we discover and deliver what they value? We systematically discover all the stakeholders so that the Client and Customer can take their needs into account.
- What is Value? We explicitly define value(s) for each of the stakeholders, based on their goals.
- Does a purchaser buy software? Do we sell software? That’s an unfortunate point of view of many in the Agile community, strengthened by the “Working Software over comprehensive documentation” line in the Agile Manifesto. First of all, we deliver a product which may contain software, documentation, training and a lot of other stuff. The purchaser sees value in the whole, not the software bit. Secondly, purchasers and users don’t care about software (which might be a reason they don’t come to conferences where we talk about software or why they hate coming to iteration planning and demo meetings). They care about capabilities and results: what will they be able to do (better) when they get the product? When can they get it? What’s it going to cost? We talk about benefits for the organisation and its stakeholders, measurable results and complete products with our customers.
What have I learned today?
- Value is relative to each person or organisation and their situation
- Organisations and projects have lots of stakeholders
- Therefore, we will have to consider many values
- Those values must be balanced and have a systemic link with the organisation’s goals so that we get early indications that we’re (not) on the right track
- Having an explicit, clear and simple Business Value model helps decision making to reach our goal
- Most of our stakeholders don’t care about “working software”, they care about achieving their goals. Our goal is to give them the capabilities they need to achieve their goals
- Therefore, to achieve our goal we need to understand our stakeholders, their organisations and their goals
- Value has
- financial and non-financial components
- a short term and long term horizon
- quantitative and qualitative aspects
- We need whole-system thinking to pull this off.
What have you learned today?
Picture of empty auditorium courtesy of Mr Ush / CC BY-NC-SA 2.0
Solve Conflicts Without Compromise
Portia Tung and I will co-present “Solve Conflicts Without Compromise with the Conflict Resolution Diagram” at the SPA 2010 conference in London on May 19th 2010.
Come and play with us to sharpen your problem-solving skills and come up with real solutions to a difficult choice you’re facing.
The Systems Thinking materials for this session are available on the Agile Coach site.
|
|
