Thinking for a Change

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:

• 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!

Don’t estimate Business Value of User Stories

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?