Here are the slides for the “Agreeing on Business Value” session we ran at Mini XP Days Benelux 2011 and will run again at the SPA conference in June.

The exercise uses a case study that’s not published, so you can’t peek and prepare for the session

Portia Tung and I ran the “Agreeing on Business Value” session at the Mini XP Days Benelux 2011 conference. In the workshop participants have to create a “Business Value Model” for a case we provided. The Business Value Model shows the most important goals and measures of the company and the relationships between goals. We often run this workshop to let a team come up with a common definition of “Business Value”. As a result of the workshop, everybody’s has a clear and common understanding of the value the project or product is going to deliver.

We asked the teams to add what they learned at the workshop on the posters. Here’s a gallery of the outputs of different groups. Click on the images to get a larger picture.

Team 1

In the model different types of goals have different colors: financial goals are blue, organisation goals are green and people goals are yellow. At the top are the “lagging measures” (those that can only be measure late). At the bottom are the “leading measures” (that can be measured early) that will be used to predict the achievement of the desired lagging goals. Arrows indicate that one goal has an effect on another. You’ll see that most things are interrelated. The good news is that achieving one goal can help achieve other goals in reinforcing loops. The bad news is that you may have to achieve many subgoals to achieve your desired goals.

This team identified the following learnings:

• Makes a complex project more clear
• Business alignment. Today business cases are made individually
• Helps to give an overview of goals for all stakeholders
• Make decisions at goal level, not at feature level
• (You can use this for) portfolio management!
• Thinking about measures

Team 2

Here we se a simpler model, but still representing the financial, organisational and people goals with their relationships. Everything leads to “Make Profit”

What they learned:

• When we talk about business value, we need to think about how to measure leading and lagging indicators
• Adding the relationships generated new insights
• Plan-Do-Check-Act
• Eliminate “business value” that doesn’t really add value

Team 3

Another very clear model with positive (+) and negative (-) effects between different goals. In the end, it all results in “Cost Cutting”

What they learned:

• It starts with a vision
• You involve everybody
• To build a model, iterate over the following steps until satisfied:
  • Identify goals
  • Define Lagging and Leading measurements
  • Identify relationships (“Diagram of Effects”)

Team 4

This model has exactly one leading and one lagging indicator per area. Together, the goals result in profit.

This team created a diagram of what they learned:

• Value is not just money
• Value must be measurable
• We have leading (“early”) and lagging (“late”) measures
• We need to identify the relationships between the measures

Team 5

This team considered more lagging (yellow) and leading (pink) goals. Many of the goals have more than one possible measurement. If you have multiple ways to measure a goal you can choose the cheapest measure to collect or find some data that’s already being collected.

The important points for this team:

• Identify
• Categorise
• Quantify
• Relationships

What the presenters learned

• Everybody got the same case, but there are differences in the models. There is no “right model”, the team has to find one that’s useful. Over the lifetime of a product or project the business value model will probably change, as different goals change in importance
• The case is not too simple, and there’s lots of information, just like a real project. Despite that complexity teams of six “strangers” came to a clear agreement on the goals of a project within 90 minutes. How long does it take in your project to come to agreement on goals and priorities. If your projects are like mine, probably the whole duration of the project
• Making our definition of business value clear, finding ways to measure and thinking about effects and relationships helps to come up with new insights
• Participants don’t ask many questions. We were available the whole time to answer questions about the technique or the case, but despite having real live “customers” in the room, participants concentrated on the written materials
• We started by describing and drawing the company vision on the whiteboard. Most teams quickly lost sight of the vision. Once they “rediscovered” the vision, they found that it answered some questions about value and priority. It would be good to remind people of the vision before every turn. Maybe we could do this in our work too? Why not start each project meeting with a reminder of the vision?

If you want to know more, head on over to the agilecoach.net site where you’ll find more about Business Value Modeling and some other useful tools.

If you applied any of these techniques, let us know how it went.

In this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.

Come and play with us!

In his post he describes the following main points:

• Business Value is multi-dimensional and not always easy to express. The key lies in the measurability of things.
• The “Business Value Model” is a technique to set the context of the “big” why and communicate this across the organization (small or big).
• It is built around the concepts we are mostly familiar with (and borrowed from other techniques).
• The “Systems Thinking” part comes into play to discover relationships between goals, capabilities, stakeholders and measurements and risks. When you turn a knob here, something will happen on the other end… and vice versa.
• A business value model is not carved in stone. You must always evaluate if what is described (or better drawn) in the model actually reflects reality.
• This visualization is important for communication. Doing the value exercise can be an eye-opener for the people in the project and/or organization.
• The “Business Value Model” should be the origin for all user stories.

Yes. That’s it. Couldn’t have said it better myself

You can see the outputs of the workshop in a previous blog entry. Read more about it on the AgileCoach site.

Hope to see you at the conference!

See you on April 1st in Mechelen.

In the Business Value Modelling session at the XP users group 6 teams created a Business Value Model for a mobile phone company struggling to keep customers and regulators happy while reducing call center costs. In the final step, each team had to create a poster that they could use to guide their decisions and to explain the reason behind the project.

As you can see from the session feedback everybody wanted to know if they had built the ‘right’ model. Let’s take a stroll through the business value model gallery and see how the teams did. Click on the images to enlarge.

Team 1

This team spent a lot of time discussing and didn’t have much time actually making the diagram. The large yellow Post-its contain the major goals. Small green Post-its are measures of the goal. Are small blue Post-its leading indicators? It’s not very clear. Only two goals seem to be worked out. There are four more large yellow Post-its to the side. What’s their meaning?

To make it perfect:

• Add a legend to the diagram
• Fully work out at least one goal
• A Business Value Model doesn’t have to be “perfect”. Make something quickly and iterate.

Team 2

This team tells a story: we have unhappy customers and we have lots of measures that make that visible (left). We have several measures (both lagging at the top and leading at the bottom) that we can use to measure and drive improvement. Then we have several things on the right that we must comply with, either constraints or non-negotiable goals. All of this should lead to happy people (customers, employees, regulators).

To make it perfect:

• The diagram focuses heavily on the customer. Where are the company, the regulators and the project sponsor? How could you represent their views?
• Does the ordering of complaints have any meaning? If you could do only one thing, where would you focus?

Team 3

This is a very clear and near diagram with a business-like 4 quadrant format. Each of the quadrants represents the view of one stakeholder. I like the big, clear goals on the yellow Post-its. Each stakeholder has both constraints and measurements/tests.

To make it perfect:

• Explain the meaning of the arrows. Am I correct in interpreting it as customers and regulators have goals which drive internal goals of the Operations Manager and IT?
• The IT measurement “daily reporting” isn’t very actionable. What’s in the report?
• The Operations manager measurement “Send confirmation” message sounds more like an action or capability than an measure or test. How can you test that confirmations have been sent? Why will that reduce costs?

Team 4

This team used a concentric circles model: on the outer circle we have the viewpoints of the stakeholders. The pink Post-Its represent a stakeholder goal; the attached blue Post-its are the measures for the goal. I’m not clear what the yellow Post-Its in the center mean. This team added a new goal that wasn’t in the original assignment: “Increase Antenna Coverage”. Apparently lots of people call in to say they can’t call

To make it perfect:

• Show some relationships between the different items so that it clear what belongs where. For example who wants to “Bill correctly”? The customer or the organisation? Who wants to port numbers quickly? The customer or the regulator?
• Explain the meaning of the yellow Post-its in the center
• Instead of the “Atern” Post-its (some leftovers from the Agile Business Conference), draw the stakeholders

Team 5

Another diagram that uses the concentric circles (or maybe a Mandala) idea. At the outside (the small yellow Post-Its) we see the stakeholders. Big bold yellow Post-its show the goals with attached measures. The Blue arrows indicate that achieving some goals helps achieve other goals. Big red Post-its indicate constraints.

To make it perfect:

• Make the stakeholders stand out more by drawing them or having larger Post-Its. Everything we do starts with the stakeholder.
• Add a small legend: for example what are the green lines?
• You don’t have to reuse the Post-its. Why not just redraw the goals and measures neatly?

Team 6

The last team had a completely drawn business value model. The central metaphor of the scales can be very powerful: by working on one side we can influence the other. Here: by increasing usability of the service, we reduce the cost of the service (or “Quality is free“). On the right, we want to reduce the number of people who call in (presumably without reducing the number of customers?). This is done, on the left, by going from a situation with few computers and lots of employees to one where computers have taken over the work. Or, as the team put it succinctly: “the solution is to replace people by computers”.

To make it perfect:

• we have one measure for cost (“# of incoming calls” on the right). How would you measure usability on the left?
• The image on the left (“replace employees by computers”) focuses on the ‘solution’. Can you represent how stakeholders will benefit?
• Replacing employees by computers is (for most people) not a very rousing goal. Is this the first message you want to get across when you explain your project? How do you think those employees feel? You’ll probably have to talk to them to implement the project.

At the end of the tour

What have we learned? A Business Value Model serves several purposes:

• To make it clear why we do the project: which stakeholder goals do we want to achieve?
• To prioritise: which goals are more important than others?
• To have project/product acceptance criteria: how will we know we achieved the goals?
• To show how we will steer the project: what measures/subgoals can we use to go in the right direction?
• To understand what is out of our control: which constraints should we abide by?
• To create a shared model of the important aspects of value and how these aspects affect each other: what is our hypothesis of how we will generate value?

What I look for in a model is:

• It’s clear: legible writing, a legend, appropriate use of colour and size
• It tells a story: “we focus first on <this> and then on <that>”, “if we do <this> it’ll lead to <that>”
• It’s motivating: the goals indicate that we’re making life and work better for people, there’s more than making money
• It’s useful: it helps me ask the right questions like “how is this feature going to help us achieve our goals?”;  helps me to make the right decisions like  “we’ll focus on area A first, because that will help us achieve our primary goal”
• It’s temporary: this is the best model of our system for now; as soon as we learn, we’ll update our model
• It’s shared: the whole team contributes to making and changing the model.

When is the model “done”? Ask yourself:

• Do I want to have this displayed prominently in the team room?
• Do I want to use this as a decision aid?
• Do I want to use this to explain the project to my most important customer or user; to the CFO; to the CEO; to a new team member?
• Do I know how we can test and invalidate the model?
• Do I want to keep this up to date?

See you at the Business Value Modelling session at XP Days Benelux. I’m looking forward to seeing the models that come out of that session.

Yesterday, I did a tryout of the “Business Value by Systems Thinking” session for XP Days Benelux.

A “Business Value Model” is one of many models our teams build to get a better understanding of the problems we need to solve. Based on the goals of our stakeholders, it shows

• what “value drivers” (or dimensions like “income”, “customer satisfaction” or “employee retention”) are part of our shared definition of Business Value.
• how we can measure that we get closer to (and finally achieve) our goals during and after the project
• what constraints limit us in our search for solutions
• how all of these things are related in a systemic model. For example, what do you think happens with employee retention if customer satisfaction goes down? What effect, if any, does shorter employee retention have on customer satisfaction? These and other causal loops may point the way to “leverage points” where we get most effect with the least amount of effort.

By building the Business Value Model we create a shared vision and align the team members. By relating all our work to the value we add, we are more motivated.

Feedback

As usual, there was much too much content. Thanks to the feedback of the participants, there will be more time for exercises and explanation, we’ll go more in depth into the real subject of the session and there wil be more feedback for participants on their model.

You can download the  tryout retrospective feedback and see what the participants thought about it. I’ll publish the output of the session in the next blog entry.

Many thanks to the participants for playing along and giving useful feedback. Thanks to Cap Gemini for hosting the event.

Answering some puzzles

• How do you prioritise based on the Business Value Model? You start with the lagging (final) goal that you want to achieve/improve first. What would it take to “achieve the goal” or “improve enough” (first define what “enough” is)? How little can we do? Do we need to mitigate some risks? Do we have enough value to release? If yes, start implementing. If no, which other goal do we need to tackle too?
• Does “Business” Value mean only financial measures? No, we also include other measures like “customer satisfaction”, “employee retention” or “happiness” (we just built a Business Value Model with “Number of people who happily use our product to do their job” as the #1 measurement). Some of those “measures” can’t really be expressed as a number, you can only see if they improve or worsen. On the other hand, Don Reinertsen recommends “if you want to be able to make (quick) tradeoffs, you should express each measure in money” in his book “Flow”.
• Is our model right? What is the perfect model? What should the final model look like? I really can’t answer that question. Your model is “right” (or: useful) if it helps you to make good decisions, if it helps you to explain the reason(s) behind your project, if it allows everyone on the team to make decisions. In the end, you test your model(s) by building something according and seeing if your hypothesis was correct. And even if it isn’t, you’ve learned something. What we’re doing here is using the scientific method: we build a testable hypothesis, we perform the test and we improve our hypothesis based on the results.

XP Day session tryout: Agreeing on Business Value with Systems Thinking

Cap Gemini will host the next Agile/XP Belgium usergroup meeting. This session is a tryout for XP Days Benelux.

We talk a lot about “maximizing business value”. We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we’ve worked with many teams to define their “Business Value Model”, a clear definition of the value a project will bring to the organisation. The exercise hasn’t always been easy but it has always brought significant benefits:

• Measurable business value in units that impact the organization (such as revenue €€€, customer satisfaction, staff retention)
• Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
• The whole team was aligned around one vision because we had clear criteria to define success
• We came up with more innovative solutions because everybody on the team, not only “the business” or “product managers/owners” could take product-related decisions based on the model
• We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
• We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
• The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you’ll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map) to define the business value model of an example project. We’ll show you the techniques we used and discuss how you can apply those techniques in you context so that you’ll be ready to start building a business value model with your team.

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Session

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

XP Days Benelux 2010 will be held in Kapellerput, Heeze (near Eindhoven), The Netherlands on 25-26 November

The program for XP Days Benelux has been published. This year we have more sessions than ever before: 41 sessions over 2 days. As always, it’s going to be hard to select only one session from the five parallel tracks.

I’ll be presenting “Agreeing on Business Value with Systems Thinking” with Portia Tung. I’ll be doing a tryout of this presentation, which has been updated after presenting it at Agile 2010. Come to the Agile/XP Belgium user group meeting on Tuesday 26th of October.

If you want to see a tryout of the “Database Change Management” session, join us in the Agile/XP Belgium user group meeting on Tuesday 5th of October.

Last Thursday and Friday I participated in the Lean and Kanban Belgium 2010 conference. I was scheduled to present a session on Friday morning, so I could go to many sessions on Thursday.

Every session that I attended on Thursday said many things I wanted to say:

• Sandrine Olivencia talked about challenging the team for continuous improvement
• Dave Nicolette talked about the dysfunctions around budgeting and the need for IT to integrate, not align, with the value stream
• Anthony Marcano and Andy Palmer explained how analysis can be implemented as a pull system
• Ryan Shriver essentially said all I wanted to say about finding the real goals of our users and quantifying their needs
• John Seddon told tales about really understanding value demand and taking a systems thinking approach to the design of work in his usual, inimitable style

What was left to say? At the end of the day I could scrap about 3/4 of my talk. The good news is that many people are independently reporting that these techniques and approaches work. And they can show results.

In the end, there was more than enough to fill an hour. After the presentation several people asked questions and discussed what I presented.

p.s. I followed Dave Nicolette‘s advice to grow a profitable consultancy: coin a new acronym. I give you “IDD”. You’ll have to watch the presentation to know what it means. And you’ll have to pay me big bucks to come implement it in your organisation

• Pinocchio: On Becoming a Lean Leader
• Agreeing on Business Value with Systems Thinking
• Estimation Games

I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.

• In “Pinocchio, On Becoming a Lean Leader” (Tuesday August 10, 13:30-15:00) Portia Tung and I help participants along the dangerous journey from toy boy to real boy. You’ll meet all your favourite characters from this Agile Fairytale and come away with some concrete actions to become a better leader.
• “Agreeing on Business Value using Systems Thinking” (Wednesday August 11, 09:00-10:30) is a workshop where Portia Tung and I help participants come up with a “Business Value Model” for their current project. You’ll be able to use the Business Value Model to identify the high value solutions that satisfy your customers. The number of places for this workshop will be strictly limited to 20.
• “Estimation Games” (Thursday August 12, 13:30-15:00) gives participants some rules of thumb to create reliable estimates with little effort. During the session we’ll play some small estimation games to put the lessons into practice. You need never be afraid again of estimating.

If you want to know more…

C’est la première édition de cette conférence et aussi la première conférence francophone sur l’agilité en Belgique.

“Les Boucles XP” est une introduction à la méthode Extreme Programming. Vera Peeters et moi avons créé cette présentation il y a longtemps pour donner un goût de la façon de travailler d’une équipe vraiment agile. A travers les pratiques et les exemples d’équipes avec qui nous avons travaillé depuis 1999, la présentation explique pourquoi cette méthode marche et comment procéder pour définir une méthode qui convient à votre équipe. Pour cela, il faut voir les choses comme un système où la valeur du tout est bien plus que la somme des valeurs des éléments.

“Agile + Business Analysis = Lean Projects” explique comment on peut combiner les techniques de Business Analysis avec ceux des méthodes Agiles pour “construire la bonne chose” et “construire de la bonne façon”. Le résultat: des projets vraiment “Lean”, de la demande du client jusqu’à la livraison. L’expérience nous a montré que cette combinaison nous a permis de livrer des projets en beaucoup moins de temps qu’auparavant et en même temps livrer un produit qui avait plus de valeur que prévu. Vous verrez quelques techniques que vous pourrez appliquer dès demain et des pistes pour en savoir plus.

A bientôt!

“Définir la Valeur Métier avec le Systems Thinking” est un atélier où on utilisera quelques techniques de Systems Thinking pour définir la “Valeur Métier” des projets des participants. Pourquoi? Parce qu’une définition de la valeur métier est le premier pas pour vraiment se focaliser sur ce qui est important. La “valeur métier” n’est pas un concept nébuleux. C’est un outil dont l’équipe se sert tout le temps. On applique le principe du “project economic framework” qui est décrit dans “The Principles of Product Development Flow: Second Generation Lean Product Development” de Don Reinertsen. Après cette session vous aurez plein d’idées pour prendre des décisions produit qui rapportent plus ET prennent moins de temps. Le nombre de places sera (strictement) limité à 20 personnes.

“Les jeux de l’estimation” vous aideront de mieux répondre aux demandes d’estimations “parfaites”. Cette session est une combination de présentation avec des petits jeux dans lesquels vous pouvez mettre en pratique les astuces présentés. Après cette session, vous n’aurez plus peur de faire des estimations. Vous saurez faire des engagements fermes avec des estimations incertaines. Si vous avez à faire avec des estimations ou engagements, vous vous devez de lire “Software Estimation: Demystifying the Black Art” de Steve McConnell.

A bientôt au Chalet de la Porte Jaune!

Si vous voulez en savoir plus…

iLean will host the next XP user group event on May 5th 2010, in Kontich.

What can Business Analysis and Agile mean for each other?

The International Institute of Business Analysis (IIBA) has created the Business Analysis Body of Knowledge (BABoK) to capture the experience of business analysts worldwide on a wide set of projects. According to the BABoK, “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

Meanwhile, Agile methods, with their own methods of understanding needs and proposing solutions, have been sweeping through many companies.

Is there room for business analysis on Agile projects? Can agile teams learn from business analysts? What happens when business analysts work in Agile teams?

The IIBA has started up a workgroup to create an “Agile extension” to the BABoK. This extension will provide practical guidance to do business analysis in Agile projects, based on experience. We’ll present this effort so that both communities can review and contribute to this project.

If you want to participate in the discussion, join the Agile BA Yahoo group.

Register for this free event on the Belgian XP Group wiki.

Why Agile + Business Analysis?

Why am I interested in seeing the Agile and Business Analysis communities collaborate?

Business Analysts could learn something:

• You don’t have to specify everything upfront. You can deliver your analysis incrementally and iteratively, at the pace it’s consumed by the implementation team(s), prioritized by value and risk.
• You don’t have to specify everything in consistently excruciating detail. You can ask your team mates what information they need and only provide just enough detail, depending on how risky the topics are.
• You don’t have to do everything alone. You can coach other team members to apply business analysis techniques.
• You don’t have to specify things before the project starts and move on to the next project before you see the results. You can be a full member of the team that delivers value and participate in the release parties.
• You don’t have to be an intermediary (or worse, a “Shuttle Diplomat“) between “The Business” and “IT”. You can be a facilitator who brings out the best in the whole team.

Agile teams could learn something:

• You don’t have to invent “Business Value”. Business Analysis can help you link the benefits the organisation expects to the capabilities it needs.
• You don’t have to create a “Vomit of User Stories” and spend an inordinate amount of time “grooming” that backlog. Business Analysis can help you to focus on the value-adding capabilities.
• You don’t have to make the giant leap from organisational goals to detailed user stories in one go. Business Analysis provides many techniques to gradually break down large problems.
• You don’t have to limit yourself to User Stories. Business Analysis provides may other ways of modeling what users and stakeholders need.
• You don’t have to go it alone as Product Owner or Onsite Customer. Business Analysts and business analysis techniques can help you get the job done, identify more value and work at a sustainable pace.

I’ve been applying business analysis techniques since my first agile project in 1999 (although we didn’t call it business analysis then). The results:

• Our projects were smaller, cheaper and delivered faster than those of the competitors.
• By focusing on the few high value delivering features, we were able to release incrementally, thereby generating real value quickly for the customer.
• By focusing on what was really needed, not what was wanted, our systems were smaller, easier to understand and easier to maintain.
• By using simple but effective business analysis techniques the cycle time from request to proposal was dramatically shorter than our competitors’.
• By having everyone in the team working on the business analysis we often came up with innovative solutions and delighted our customers. How often do your customers tell you “Wow! I didn’t know you could do that!” ?

It’s not enough to appoint someone to be the “Product Owner” and expect to become a productive team. More likely, you’ll end up with a burnt out Product Owner. First of all, you should give effective tools to your Product Owner. Secondly, you shouldn’t build such a bottleneck into your team; provide your whole team with those tools. I know in which community you can find many such effective tools…

Juan Gutiérrez Plaza has contributed a Spanish translation of the Business Value Game. Thanks also to Leo Antolí and Thomas Wallet for reviewing this translation. Muchas Gracias!

You can download the Business Value Game in English, French and Spanish from the Belgian XP site.

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?

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:

• Client
• Customer
• User(s)

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?

The previous blog entry said that we should find the Business Values before writing user stories. Once we find the Business Values, we derive the User Stories from them.

That just raises more questions:

• What is Value?
• What is Business Value?
• Why more than one Business Value?
• Where do we find the Business Values?
• How do we derive User Stories from Business Values?

Let’s look at the first three questions and come back to the last two later.

What is Value?

The Institute of Value Management defines value as “…based on the relationship between satisfying needs and expectations and the resources required to achieve them” and “getting what you require for what you will pay“.

Jerry Weinberg (in “Quality Software Requirements volume 1“) says that “Quality is value to someone”.

Robin F. Goldsmith (in “Discovering Real Business Requirements for Software Project Success”) says that “A requirement describes some value we need to deliver to someone”.

So… if we “deliver value” we’ve satisfied a need or expectation of someone at a price they were willing to pay. We’ve provided someone with a benefit for a reasonable cost.

What is Business Value?

Wikipedia defines Business Value as “…an informal term that includes all forms of value that determine the health and well-being of the firm in the long-run” and notes that it goes beyond purely economic value.

Some theories (like “Shareholder Value“) try to reduce the different forms of value to one measurable value. I don’t think it’s as simple as that. An organisation is a complex system that’s impossible to reduce (or manage) with one measurement or goal. There will always be many (sometimes conflicting) goals, we might as well have these in the open.

Other theories like “Balanced Scorecard” try to strike a balance between 4 different views of the organisation.

Why more than one Business Value?

Because every definition of quality, benefit or value includes the term “…for someone”. We have different stakeholders with different goals and needs. They all have their definition and view of value. That raises two more questions:

• How do we know who the relevant stakeholders are?
• How do we find out what their goals and needs are?

Four views is better than one. But you’re likely to have more than four stakeholders for your project, so you’ll have more views.

Definining Business Value

Business Value may well be an informal term, but I like to define Business Value a bit more formally at the start of a project. That’s what we call “Business Value Modeling”:

• Identify the relevant stakeholders
• Identify their needs and goals
• Agree on how we measure/test the achievement of the needs and goals
• Select the (few) most important measurements and tests, the “Value Drivers”
• Define the relationship between the Value Drivers.
• Use the Value Drivers to focus and prioritise our work, from start to finish.

It’s important to define the relationship between the Value Drivers. E.g. we may have both “profit” and “customer satisfaction” Value Drivers. Which comes first? If we find a way to increase our profit at the expense of reduced customer satisfaction, would that be acceptable? There is no right answer. It depends on the company, the project and the circumstances.

Why agree on a Business Value Model at the start of the project?

Because the Business Value Model models what your business values.

The selection drivers and defining their relationship is bound to be a difficult conversation, but it’s one we want to have early on. If we don’t have this conversation from the start of the project we run the following risks:

• Continuous discussion about priorities pulling the project hither and tither
• Hidden priorities and values influencing decision making
• Trying to “keep everyone happy” with compromises. Why not solve the real conflict and increase both profit and customer satisfaction? Because we’re afraid of conflict and because compromises require less work
• Starting too many projects at the same time, trying to keep every customer happy.

How does your organisation prioritise projects or features?

Some organisations seem to value customer conflict avoidance above all else, leading to such unhealthy prioritisation schemes as “the customer who shouts loudest” or “the customer who shouted last” get to the top of the list. Sometimes a seemingly irrational prioritisation scheme hides some perfectly understandable values.

For example, in one company, the official strategy was to deliver product releases that contained a good mix of benefits for our customers all over the world. In reality, some customers (who happened to know the phone number of the CEO) always got their feature requests bumped to the top of the list. These customers all came from the same region. This had a negative effect on customer satisfaction and consequently sales bonuses of the salespeople in the other regions. Of course, sales bonuses were another powerful and hidden value driver for product prioritisation. Everybody knew this; nobody talked about this.

If we had had an in-depth Business Value Modeling conversation, we would have come to the following business value driver:

The needs of our “old” customers come before “new” customers, because their loyalty to us has allowed us to build this business

These old and loyal customers all had the CEO’s phone number, because they’d become customers long ago when the CEO did sales himself. They were all located in the same region because that’s where the company first started selling its products. Taking good care of your loyal customers is a perfectly valid business strategy, but because it was never articulated it created a dysfunctional prioritisation process.

More questions

We end with more questions than we started with. That’s a sign of a good analysis process

• How do we know who the relevant stakeholders are?
• How do we find out what their goals and needs are?
• Where do we find the Business Values?
• How can we measure/test those Business Values?
• How do we agree on the importance of Business Values?
• How do we derive User Stories from Business Values?

Let’s come back to these questions later.

What is your definition of Business Value?