The title of this post is a little highfalutin, but it gets the idea across I hope.
After many discussions with people about this subject, I find that the words "business value" tend to mean something very narrow to most individuals.
For example, the words often mean mainly or mostly: "the numbers we put on the story cards", "the silly
NPV estimate someone made to get this project approved", "how the company benefits from this team's project", "something that only the business guys care about...probably they just want to boast that they have the project with the biggest one", etc.
It is important to note immediately that business value ties in with our highest values. To satisfying the basic human needs of those in difficult circumstances, of obtaining our highest aspirations, of leading a good life (in whatever way you define that). When I was young, I was taught two main rules: (a) Love God, and (b) Love your neighbor as yourself. Without ignoring (a), let us say that in my opinion, business value is really about expressing
caritas to specific individuals.
To me, when you use the words business value, you imply and/or are really talking about a whole bunch of things:
- a definition of what value means; and one or more specific operational definitions of BV for the effort (project) at hand
- a bunch of ideas that surround and pervade BV, that are key to the way we use it
- a recognition that communication and motivation are key
- a very practical down-to-earth subject, that is at the same time difficult and slippery
- a bunch of practices that make BV useful. I want to call these the BV engineering practices (although again that may sound too highfalutin to some)
- change and learning, so the subject is as much about adapting to change and learning about it faster, as about any hard and fast dicta on BV itself
And other things as well.
So, I wanted to back up on the subject. At least compared to some who want to rush to consensus on one definition of business value (eg, reduction in cycle time, to pick one of my favorites from Lean).
So as not to lose you, please define in your own head what Business Value means to you. Say, the business value of a project. (I assure you there are many different definitions out there.) Now, think about that as I talk about why we care about business value.
I am searching for the general ideas that pervade all views of business value. And perhaps by examining them, we may discover more about what
BV really is, or at least how to use it better.
Why do we care about Business Value?"You have to be very careful if you don't know where you're going, because you might not get there." This was Yogi Berra's wacky and wise way of saying it.
I have been on too many projects where there was no clear definition of what we were trying to accomplish. In several cases, one guessed that we were at the personal and daily whim of some project "leader" (not that I considered the leadership skills all that high).
Let me state this a different way.
In the world, my hypothesis is that there are an infinite number of good things to do. The problem is not finding a set of good things to do, but in deciding which are the most important things to do.
So one reason we care about BV is to, in this short lifetime, accomplish something truly meaningful.
Another reason is that we work in small teams. And we want everyone to be working toward a common goal. So we need to agree what that common goal is. It can be expressed in many ways, but at one level it must be called business value. Or, more specifically, the operational definition of business value for this project that motivates the team to do only (and just) what is needed as defined by business value.
Put another way, business value draws upon our natural motivations, and gives us a basis for putting a natural order into all the arrangements involved with a team's work (
eg, who does what, the architecture of the system, etc., etc.).
Another reason is based on my hypothesis that change is incessant. This means that people forget, customers change, customers' needs change, past estimates (if they were accurate) are no longer accurate, etc. To the degree we understand
BV appropriately, it can act as a guidepost in this swirl of change. We do not build new products for mere technical success. We do it to provide business value to specific people, so we must adapt to this change.
My hypothesis is that
BV itself is also changing. This is alluded to below, but more a subject for later.
Four related ideasLet me mention now four ideas that are key to understanding business value (that weren't already implied by things I said earlier).
Cost-Benefit Analysis: No buyer buys a thing in isolation. He is always comparing an apple to an orange to a box of Cheerios. He only has some much money (or time), so which gives him the most satisfaction for the buck? It is my hypothesis that we should use this kind of thinking (or should) for each project. And we should do this at a more granular level also.
Pareto's 80-20 Rule: Pareto posited that in any population, there were "the vital few". This is translated into saying: "20% of the things provide 80% of the value." And this is true for any size population (or at any level of population, if you prefer). So, it is probably true of projects, of themes within a project, of
nitty "requirements" within a story.
My hypothesis is that, in any set of stories for a project, there are at least one or two order of magnitude difference (given the same size story) between the BV on one story versus another. This information is very valuable. This is a very common (although not universal, I think) situation for product backlogs.
Knowledge-creation: There is a whole set of ideas around knowledge creation. We will greatly simplify them here. First, that a team is better at learning/discovering new things than an individual. Second, that knowledge goes through cycles of conversion from tacit to explicit (and perhaps back again). Third, that knowledge creation is energized by putting people together in a place and providing a context (meaning). (See The Concept of "Ba".) Fourth, that knowledge can be said to self-organize into a product (solution). There is increasing evidence that knowledge-creation is the core competency. Our hypothesis is that applies to Business Value in many ways.
Learning Methods: We think
BV should be used in the context of (to pick one instance) Deming's
PDSA model. This is Plan-Do-Study-Act. (Basically the scientific method.) We think short, time-boxed iterations are key. That some data is a key learning device (comparing expected results to actual results). And that general indicators are more important than slowing down for precision and "accurate" numbers. In the end, though, it's about people, not the numbers. The numbers are only a rough guide to the people. In many cases, out-of-the-box intuition may be a better guide.
A full BV engineering approachLet's give a rough first definition of what we think a minimal
BV approach would be (the fancier term would be a full
BV engineering practice).
- a well-communicated high-level definition of business value (this might have multiple dimensions)
- a well-communicated operational definition of BV for the specific effort
- a clear way to measure whether that hypothesis (as embodied in the operational definition) was correct; or how incorrect it was (probably a likelier outcome)
- a confirmation that this definition actually energized behavior (eg, the programmers wanted to see success in that way) and that it was used in a way that allowed small adjustments toward a better outcome
- a clear set of practices for using this definition throughout the course of the project
- a clear way to modify those practices, so that better practices could emerge over time
- a common understanding about the time-boxes around the practices, and a continual questioning about whether those time-boxes (presumably at different frequencies, depending on the practice) were the most effective in guiding a better delivery of business value in this specific case
- a set-out way to develop the people to perform these engineering practices (training and the like)
There should also be some discussion about the dimensions of the word "better" in the next-to-last bullet. That might mean faster, more, higher quality (perhaps more reliably hitting the target), cheaper, etc., or some combination of those, depending on the context. My personal bias would be, first, to optimize faster delivery.
It is probably necessary to say (just as we still have to say that agility requires greater discipline of a sort) that the overview of the BV engineering approach above does
not imply something like BDUF, endless documentation, high ceremony, etc.
* * * *
Now, does all that discussion make sense in the context of your current definition of Business Value? I hope so.
I would greatly appreciate your comments on this discussion. And on later related discussions. Or earlier ones. More to come.
by Takeuchi and Nonaka. This is the stepping-stone to their discussion of "Ba".
by Mark Denne and Jane Cleland-Huang. This book explains what you should go to Minimum Marketable Feature sets to get incremental funding. Or...it pays to go Agile.
by Mike Cohn. Key stuff.
by Mike Cohn. Again, key stuff.
by Mike Krzyzewski and Donald T. Phillips. I live the Duke Blue Devil basketball team. Not surprisingly, I find basketball an apt metaphor for a software development team. Coach K gives a lot of great advice about building a winning team.