About “Business Value”
I’m notoriously long-winded on Twitter. Here’s what I wrote earlier today:
What do I mean by that?
In my research into your species, I’ve noticed that humans are social animals. With the exception of ideologues and other damaged people, you work best when your work is oriented toward other people. Not “people” (in the abstract), but actual individuals. Because you’re quite good at personifying objects—look how many of you act like your boats are people—you can also do well when oriented toward improving those object’s “lives”. (That is, you treat your software the way you treat your pets, which is not that different from the way you treat [some of] your loved ones.)
When it comes to software development, I’ve seen teams that are extremely… nurturing toward the product owner. I’ve seen teams that treat the product itself as a person to be groomed and prepared for its entry into the world. I’ve seen teams that identify strongly with the prototypical, personified, or actual end user and want to make her life easier.
Quite often these teams, especially Agile teams, seem obsessively focused on “Business Value”, but that’s in the context of personal relationships. “Business Value” is a shorthand, a way of keeping conversations from going astray, of keeping people focused. It is a term that signals or reminds of other things—it is not a thing in itself.
Increasingly these days, when I hear people theorizing about Agile and Lean, they are treating “Business Value” as a thing in itself. It is treated as an end, rather than as a means. (This is in keeping with the decline of Agile as a bottom-up team-oriented insurgency.)
Who cares? The good thing about old-style Agile is that it tamped down teams’ tendency to be overbearing while still involving them in the conversation about what makes the product better. Code is generative, and programmers could—and did—suggest directions the business could take based on what the code “naturally” “wanted” to do. This could lead to wonderful and illuminating conversations.
When Business Value is determined from On High and is a discrete thing in itself—a product of expertise not accessible to the hoi polloi—this conversation is short-circuited. Analysis (the province of Business) populates swimlanes on the Kanban board or the product backlog. When Development takes an item from the Analysis backlog or swimlane, the signal it sends upstream is “I need a new chunk of work” not “Let’s talk about the next good idea.”
That is: your species has another skill. Just like you’re good at turning objects into people, you’re good at turning people into objects. It’s easy for you to subordinate actual humans to the beauty of a System. You’re terribly prone to slip into ideology, to elevate objects to totems-to-be-deferred-to. “Business Value” is, I fear, becoming one such totem.
To forestall the inevitable comment: I know (I know!) that in a well-functioning organization with Respect for People, the ugliness I describe wouldn’t happen because wise philosopher-kings wouldn’t let it. I just believe there is a shortage of such wise philosopher-kings and—in their absence—we should cut with the grain of human nature.
April 5th, 2010 at 8:13 am
This seems to me to be closely related to Fowler’s points about Conversational vs Decreed stories:
http://www.martinfowler.com/bliki/ConversationalStories.html
“The product owner knows the business, what the software is for, and thus what needs to be done. The developers know technology and know how to do things, so they can figure out how to realize the demands of the product owner.
This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. “
April 5th, 2010 at 3:12 pm
I take it that what you’re saying here is, “Use the concept of Business Value correctly”, rather than “There is a superordinal goal beyond Business Value”. In which case, why is it a means and not an end?
April 6th, 2010 at 4:55 am
1. Good to see signal to noise ratio slightly improved on Twitter
2. I believe that qualifying Business Value in more detail will help. I mean, it would still be “objectified”, and it could be measured in various ways - and discussed - rather than being symbolic.
Hope this helps.
Bob
April 14th, 2010 at 4:10 am
Hi Brian, I find your post talks about a problem in very general terms. I don’t understand clearly what the problem is. Can you give a specific example of this problem, for instance a little story about how a team gets this wrong?
April 20th, 2010 at 10:30 am
sconover: yes, related.
alternity: I can’t argue with using Business Value correctly, but I just want to note that Business Value is not a *thing*. It’s an estimate, often an extremely rough estimate. If one in practice pretends it’s something absolute, independent of other decisions, and completely knowable - which people do! - I’ll bet on shortsighted decisions coming up.
bobcorrick: Could be. Akin to http://en.wikipedia.org/wiki/Balanced_scorecard
xpmatteo: what comes to mind is a counterexample. One team I worked with had something called “the refactoring board”. When someone was in some code that needed improvement, but didn’t improve it, he or she would pin a card on the refactoring board. Over time, the cards would rise higher and higher on the board. At some point, the product owner would declare himself sick of looking at them and say they should spend part of the next iteration getting the level lower.
Now, you could make the argument that the team should be more vigilant about refactoring, that internal quality is the domain of the development team not the product owner, and so on. They shouldn’t need to ask permission. The better–more disciplined, more experienced–the team, the more likely that separation of concerns would be to work.
Nevertheless, people err and people make mistakes when trying to fulfill their iteration promises, etc. Therefore, it makes sense that at some point the product owner would in fact be faced with a choice: which has more Business Value, these three stories or improving the code. I believe that it is almost *never* the case that the product owner has the information to make that decision. Which means, history tells us, he will err on the side of leaving the code messy.
That error was short-circuited in this case because (1) the product owner knew the team was *extremely* devoted to the product and to him personally, and (2) he had a personal relationship with the developers that made him share their distress at seeing the codebase slipping.
Being a little less obsessed about Business Value and a little more obsessed with human relationships led to–I suspect–a better long-term result. Of course, I can’t know that, because I certainly can’t weigh short term Business Value against long term code quality better than they could.
April 25th, 2010 at 1:54 am
[…] Brian Marick pointed out recently, it’s about achieving more (much more) through relationships, not one side or another […]