Mark Schwartz

I'm a CIO, and that, of course, means I spend most of my time thinking deep CIO thoughts. That's really what we do.

Like, am I really a CIO, or am I just a CTO dreaming I'm a CIO?

Or this is my favorite: if a router fails in a data center and there's no one around to monitor it, does it make a routing table change?

What else?

So, I have been thinking about business value, and I'm not sure why everybody else isn't talking about it. We've got an Agile Manifesto that says our highest priority is to satisfy the customer through, what is it, early and continual delivery of valuable software. There's a reason why the word "valuable" is in there.

I like the way that Jim Highsmith puts it. He says, "Agile projects are not controlled by conformance to plan, but by conformance to business value." Business value is absolutely at the center of all of our practice, and I'm a little bit surprised that we don't hear more about it.

What is this business value thing exactly? Probably because it's really obvious, but for some reason it just isn't clicking with me. Let me give you a little example of a situation that I've come across that leads me to think that maybe we don't really know what we're talking about with business value.

So, this is going to be a lightly fictionalized story because I work for the government, and you can imagine the consequences if some hostile government figured out how we prioritize our backlogs. So, I'm going to fictionalize this a little bit.

Yeah. You're laughing, but World War III is probably going to start when the Russians hack into our Jira instance and close stories that haven't met the definition of done. You can imagine the chaos, right?

So, I'm sitting in a senior leadership meeting, and the CEO is saying, "There's one kind of application that we process from customers, and it seems to be taking us a long time to process these. And so the customers are getting frustrated and they're going somewhere else, and we're losing business. We've got to solve this problem."

And I'm there thinking, "Yeah. We have an IT system that facilitates this application process. We can help with this. There's probably something we can do that will improve the situation."

And in fact, we have a full-time team that is doing nothing but working on that application, and they're doing a whole bunch of changes to it. So I wonder what's going on here.

So I go and I talk to the team. I talk to the team that's responsible for that application and I say, "What are you guys working on?"

And they say, "Oh, this is great. You're going to love this. We're using an Agile process." This is lightly fictionalized. "So, we're using Agile baseball, is what we're doing. We divide our work into two-week innings, and then at the end of each inning, we do a demo of all the runs that we've scored."

I work for the American government. That's the explanation here.

"And at the beginning of each of these two-week innings, we decide how much work we can commit to. We have a batting average that we calculate, and we figure out how many runs we can do in that inning. And we've got this guy, the pitcher. He decides what pitches to throw based on his prioritization. That's the way it works."

And so, "What are you guys working on?"

And they tell me some of the things they're doing, and it occurs to me that none of them is actually going to help solve this problem with the applications piling up.

And so I say, "Well, why? How are you choosing those things in particular?"

"Well, you've got to talk to the pitcher. The pitcher is in charge of prioritizing the pitches. He has a backlog."

So I go and I talk to the pitcher, and I say, "Just exactly how are you deciding what pitches to throw?"

And he says, looking at me like I'm a total idiot, he goes, "Well, it's based on business value."

And I say, "Well, how are you figuring out the business value?"

And he looks all insulted and he's like, "Well, I've been to certified bat boy training. I spent my two days there. I know what I'm doing here. I talk to all the end users and I know their pain points. And when they tell me about a pain point, I think about what the implications would be of solving that pain point, and I make a business case, and I decide what we're going to work on, and I prioritize."

And I said, "How about the backlog in the applications that's happening?"

He says, "Yeah. We thought about doing some work that would help with that, but some of the other pain points, if we fix them, it's going to reduce our costs. We know it's going to reduce our costs, 100% chance. The things that might fix the application process and make it go more quickly, well, those might help. They're not going to change our costs, because we have this backlog of applications. We're still going to have to employ all the people to process all those applications.

"And maybe it'll increase revenue because some of our customers won't go away, but that's speculative. Some people say maybe even 25% increase in revenue, but we don't know for sure, so I've attached a discount factor. I say there's like a 10% chance that that will happen. And so I value that story at only two runs, where I have all these other stories that are worth five runs, so we're doing those."

And I'm thinking, "Well, I can't argue with this. This is a great application of exactly what we teach people in certified bat boy training. This is the way you do it."

So when I see situations like this, where you've got a sincere pitcher, product owner, prioritizing the backlog, but yet it's not adding up to what's important to the organization, then I think maybe the problem here is that we don't really know what we're talking about when we talk about business value.

So, if you go back to the Agile Manifesto statement that I said, there's something a little tricky about the way that it's worded. It says, "We aim to satisfy the customer through continuous delivery of value."

So maybe business value is sort of customer value. It's the value we're delivering to our customers. It sounds good. It sounds very nice. But when you think about it, that doesn't really add up.

Business value can't be the same thing as customer value for a few reasons. First of all, maybe there's something that our customers would love, but it's going to be really expensive for us to build. Are we really going to build it? Is that going to add business value?

Or maybe it's going to make the customers happy, but it's not consistent with our brand. That's entirely possible.

I've known companies that have said, "Our strategy for the next year is to try to get rid of 10% of our least profitable customers." And so it's a perfectly plausible business strategy, and the best way to get rid of those customers is to destroy value for them. Don't give them what they want.

So it's hard to see customer value as meaning the same thing as business value. There seems to be a distinction there.

Beyond that, there are lots of IT situations where you're creating software for internal users of the company. And yes, that might have some connection to customer value, but it's much harder to see and make decisions based on.

So perhaps what we're really talking about is user value in those cases, not customer value. And in fact, the pitcher in this example that I gave, that's exactly his logic: "I want to create value for the users, so I find out their pain points, and I try to solve that."

But the problem with that, I think it has a lot of the same problems that I was just talking about. First of all, the users might want something that's really expensive to build, and it's not in the company's best interest. It's not going to add business value if we build it.

It's very possible that they're not seeing the strategic implications, and so while they have something that seems very important to them, it's not the most important thing to senior leadership or whoever is formulating strategy.

I think it's especially a problem when you're in a transformational situation, where leadership is trying to push a big, broad transformation, and a lot of the users might not be comfortable with that transformation, and so they're not going to see it as really important to do.

So it's very possible that business value isn't the same thing as user value or customer value.

So the next thought, and you see this a lot when you're reading Agile literature, is business value, it seems like it's a numeric thing. It's an objective business concept that you can value. Perhaps return on investment is what a lot of people propose.

So we should be doing the things in IT or in product development that have a good return on investment, or ROI.

What is ROI? It's a little bit funny that nobody really mentions that there's a problem, because it's not actually a well-defined term. If you go through your business school textbooks, you'll find that there's no definition of a return on investment.

It's definitely a return divided by an investment. Everybody agrees on that. But what's the return? How do you measure a return?

Probably the most common way of measuring it is profit. So we're going to build this feature. It's going to increase profit this much. We're going to divide that by the amount it costs to build that feature.

A couple of little problems with this. Profit in one year? Two years? Three years? Forever? What profit are we talking about here?

There's a time value of money, so usually in an economic sense, profits that are further out are going to be worth less to us. Return on investment doesn't consider that.

If we're making decisions about what to build, then we don't actually know profits. We can only project them. So we're going to estimate what kind of profit this feature is going to cause us to have later on, in the best case, if we actually try to do this.

Does everybody's product owner actually calculate return on investment for each item in the backlog? Probably not. A really hard thing to do.

So maybe we look at this new feature and we say, "We think that if we have this feature, the market's going to buy this much more of our product and it's going to increase our revenue X amount."

All right. There are a lot of assumptions. There are a lot of guesses. But what if a competitor copies the feature? Do we know if the competitor is going to copy it? What if they do a better job building the feature than we did?

What I'm getting at is the amount of assumption you have to make to do this by far outweighs the value of the calculation in many, many cases. I'm not saying in every case.

Perhaps even worse than this, though, and this has made some of my friends in the business community laugh about the idea of using ROI, is profit is not a real economic measure, actually. Profit is an accounting fiction. Fiction truly, not in a nefarious way. But profit is something that the accountants calculate by factoring in depreciation and value of inventory and all kinds of other things that really has nothing to do with the IT change that you're trying to make.

So profit is a really weird thing to use.

There's maybe an even more ironic reason why we shouldn't be using ROI or anything like it, and that is the problem that it ignores what we care about the most. It ignores agility.

And what I mean is that in an agile world, what we're trying to do is create options for ourselves. We say, "Decide at the last responsible moment." So what we want to do is do things now that are going to let us make decisions later on that will return value to the organization.

How do we value the thing that we're doing now in terms of what options it's going to create for us later on? That would be the whole point of making decisions agilely.

So ROI does not take any of those things into consideration.

There are other business metrics that we might use: net present value, shareholder value added. All of these things are really distant from what we're actually making a decision on. If we put a green button on this screen, how much is it going to increase stock price? I don't know. It's hard to work with if what we're trying to do is make decisions about how to prioritize those things in our backlogs.

If that's not enough, I've got a bigger problem for you. These things are easy to talk about if we're dealing with a publicly traded company. We can talk about how much the stock price goes up. We have formal financial statements and profit and so on.

There are about 5,000 publicly traded companies in the US. There are about 27 million businesses in the US. So public companies make up 0.02% of the businesses that are out there.

A lot of those businesses, it turns out, are really just sole proprietorships. It's just individuals running their own businesses. But if you take businesses that have more than one employee, still six million of those. So the publicly traded companies are about that many.

On the other hand, family-run businesses are 70% to 90% of global GDP. It's about a third of the Global 500 companies are family-run businesses.

So if you think of this set of companies that are closely held private companies, so small number of owners, profit doesn't necessarily matter to them. If you own a company, business value is whatever you say it is.

And I've had this experience in situations where I've worked, where the owners, we said, "You're losing money by doing this," and they said, "We don't care. That's what we want. That's the kind of company we want to have. It's going to do those things."

If you think about venture-backed companies, here's another example. Venture capitalists have their own set of concerns. They own part of the company, and often what they really care about is being able to go into the next round of financing at a much higher valuation. That is really what business value is to them.

Or business value might depend on the stage or the life cycle of the fund that they're investing, where they are in the life cycle.

So if the company is privately held, it's up to the owners what business value is. We're not going to get anywhere with ROI or any of those other measures.

1.5 million nonprofits in the US. What's business value for them? Probably something along the lines of mission accomplishment.

I happen to work in DHS, the Department of Homeland Security. What's business value there? Presumably avoiding terrorist incidents, maybe.

So go ahead and calculate all the ROI you want. You're not really going to be approaching what we really think of as business value.

We're, of course, the nice immigration people, as Lisa said. The not-as-nice immigration people are Immigration and Customs Enforcement, ICE. They're the ones who detain illegal aliens.

So they have detention facilities. They arrest people, put them in those facilities. What is business value for them? Let's go back to customer value. I guess customer value, it's how comfortable are the beds in the detention facilities? Is that really how we're going to make our decisions?

So you can see, I managed to confuse myself thoroughly by trying to figure out what this business value thing is.

I think maybe the most upsetting, concerning thing about business value is the idea that the pitcher decides, or the product owner, or whatever. So we have agile teams, and I think we're tempted not to think too much about business value because the business decides.

I'm in IT. Somebody else makes that decision for me, and the business people obviously know about business value, right?

Well, first of all, I wouldn't jump to that conclusion. The product owner has exactly the same set of problems that I just said. There's nobody who has some kind of special wisdom about business value for all of these reasons.

But I think the deeper problem here is if you have a product owner who is drawn from the business and you're saying, "Let them make the decisions about business value. Tell the team what's important," and then the team just does it, what we really have is a mini-waterfall.

This is requirements being determined by the business and being tossed over the wall to the IT team that's going to implement them. If that's your way of thinking about product ownership, all we've done is we've set up this product owner to represent the entire business and still have them toss requirements over the wall, or decisions about business value over the wall, to an IT team that is then going to execute.

So, the questions around business value here really get to the essence of what we mean by agility. What we're thinking of when we think about DevOps is the team responsible for delivering business value.

Well, if it's a product owner who represents the business, who's making all the decisions about business value, then the product owner is responsible for business value. The team is responsible for delivering the product that the product owner has specified.

Isn't that the same as the waterfall model, just sort of shrunk down? Is it the team's responsibility to deliver product or to deliver outcomes? Or are the outcomes the responsibility of the product owner?

So, the answer, it turns out I'm only allowed to talk for 25 minutes here, and how much do I have left?

Two.

Two minutes left here.

So the answer, of course, is in this wonderful book that I've written.

Actually, there is a lot more to be said about the subject. But the important thing, I think, is this conversation. What do we mean exactly when we set up our agile practice and we say teams are autonomous and responsible for delivering value?

Do we mean that one person on the team is allowed to understand what business value is and tell everybody else? Or is the team really going to be responsible for delivering business value on behalf of the enterprise? In which case, maybe we need to rethink how we're setting things up.

But the one thing absolutely for sure is that the team can't deliver business value unless it understands what business value is. So these questions are absolutely critical for...

Well, back to my original point: why isn't everybody talking about this? We have this agile framework where we've decided that delivering business value is what we're all about, and we're telling teams, "Go out and deliver business value."

It kind of matters what we mean by business value.

So, I will leave you with that. Please think about it.