What is Business Value?

What is value? We all know that the key to a winning, high-performing organization is aligning our work with delivering value. Value for the business, value the customer wants, value that is in demand, etc. But what is business value?

Back in 2016, former CIO and current AWS Enterprise Strategist Mark Schwartz attacked this mystery with his first book, The Art of Business Value. As IT Revolution celebrates our ten-year anniversary, we’ve been taking a look back. And I find it’s safe to say that nearly 7 years after the original publication of this book, the question of what is business value continues to be a hot topic.

It’s not that we don’t understand the basic idea. Business value is whatever brings value to the business, right? Then why do we continue to struggle to align our work in technology with the needs of the business? Why is this a question that is still found on every conference agenda? Well, maybe it’s time we step back and revisit Mark’s words.

The following is excerpted from The Art of Business Value by Mark Schwartz.

A core principle of Agile and Lean theory is that software development projects should seek to maximize business value. Projects should be judged not on their adherence to cost and schedule milestones, but on their delivery of value to the enterprise. Value should be delivered as quickly as possible—in small increments—and features should be prioritized based on the amount of value they deliver. DevOps, in a sense, is about setting up a value delivery factory—a streamlined, waste-free pipeline through which value can be delivered to the business with a predictably fast cycle time. Rapid feedback from production to development then allows us to optimize that value delivery machine.

The idea of business value was central enough to Agile ways of thinking that it merited a place at the head of the twelve principles attached to the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Several of the signers of the Manifesto later elaborated on this idea in their books. Ken Schwaber, the cocreator of the Scrum framework for Agile development and a signer of the Manifesto, speaks of Scrum’s “insistence on delivering complete increments of business value.” Kent Beck, the creator of Extreme Programming (XP), pushes the concept a step further by saying that the XP team should only do things that add value to the business. Another signer of the Manifesto, Jim Highsmith, declares that “Agile projects are not controlled by conformance to plan but by conformance to business value” and then later makes a similar claim: “In the final analysis, the critical success factor for any method—Agile or otherwise—remains whether or not it helps deliver customer value.”

Strangely, although the idea of business value is so central to the Agile way of thinking, most books on agility sidestep the question of what exactly business value is. Instead, they assume that someone from “the business” will determine what is valuable and how that source of value should be translated into features and priorities. In Scrum practice, this person is the product owner. The product owner is sometimes described as the visionary who steers the product and sometimes as the steward of business value decisions: the person who maximizes business value by making appropriate prioritization and scope decisions. In either case, the product owner provides the business value context to the team.

Also interesting is the vacillation, shown in the quotes above, about whether the goal of Agile development is the delivery of business value or customer value. Highsmith, you will notice, switches from one to the other in the course of twenty-six pages. The first principle in the Agile Manifesto is ambiguous—it speaks of satisfying the customer by providing value. Is business value the same as customer value? Many of the influential Agile thinkers and writers come from product-focused software companies, so it is natural they would think in terms of customers and their needs. Product-focused companies earn their revenues by delivering value to customers, it is true—but is that value the same as what we mean by business value?

The word customer is ambiguous in this context. If we take it to mean the buyer or user of a company’s commercial software product, then the answer is no. While customers might want or value a particular feature, the business might not value giving it to them, for reasons of cost, maintainability, or consistency with the company’s brand or competitive positioning. Features that deliver customer value do not necessarily lead to increased revenues, or they can be more expensive to develop than the revenue they drive. On the other hand, we can easily imagine software features that are valuable to the business even if they are not directly valuable to the business’s customers: for instance, business intelligence reports, accounting functions, and procurement systems for supplies. Or consider a business whose strategy is to deliberately lose the 10 percent of its customers that are the least profitable—the ones who cost too much to serve and provide little revenue in return. In this case, adding business value may mean deliberately destroying customer value.

Of course, we do not have to take such a literal interpretation of the word customer. Perhaps the writers mean to include all of the users of the software, even if they are internal to the company. It seems obvious that a feature cannot be valuable unless it adds value for the person who is using it. That is why Agile approaches emphasize working directly with end users and continually soliciting their feedback. But this broader concept of user value still does not quite capture what we mean by business value. In the case of a transformational business initiative, for example, management wants to create fundamental change in the organization’s processes, but individual users in the organization may not share that vision or may not be expert in interpreting and applying it. They might have smaller, more “local” priorities than the big-picture transformation that management has in mind. By trying to maximize what users consider to be valuable, the Agile team might simply be perpetuating old ways of doing things rather than contributing to a transformation that the business values.

In speaking to users about what they need from a piece of software, I’ve found a common pattern: they believe that processes that take them a number of steps should be automated to make their jobs easier. That can be very valuable to the enterprise—or not. The user might not realize that automation might lock in a process that is likely to change and might not factor in the costs of maintaining the software as that business process changes, for example. There can be many reasons why business objectives differ from user objectives.

Perhaps the authors mean to suggest that the business as a whole is the customer of the Agile development team. IT organizations have often been thought of as customer service organizations whose goal is to satisfy the needs of internal customers. Certainly contract software development shops think in terms of satisfying a business that is their customer. If the organization as a whole is the customer of the Agile team, then the alignment between customer value and business value is exact. But is this model of the business as the customer the appropriate model for an Agile organization? I’m not so sure, and chapter 5 will explain why.

I would like to suggest that the conflation of business value, customer value, and user value is outdated and well out of step with current Agile practice. As with requirements in general, we can no longer think of business value as something known and understood in its entirety before the team begins its work. More importantly, we cannot think of business value as something determined outside the team by something called the business and then simply presented or “tossed over the wall” to the team in the form of user stories, prioritization, and feedback on product as it is produced. The responsibility for understanding and interpreting business value cannot be placed solely in the hands of a product owner. And if the success of an Agile project is to be determined by the value it delivers, then we have to think of that value in terms of outcomes, not completed stories, and measure it as such. Releasing code is not the same thing as delivering business value; to know that we have delivered business value, we must both understand what business value is and be attentive to outcomes.

This might sound like an academic exercise: business value probably sounds about as interesting to Agile practitioners as bookkeeping and accounting—things that MBAs, people inclined to that sort of stuff, study in business school. I assure you that this is a mistake. A good understanding of business value is critical to Agile practice, and I will demonstrate that the question of business value becomes stranger and more revealing the more one examines it. It is critical, for example, in distinguishing between waste and value-adding work. I will try to show that many of the difficulties we routinely face in adopting and improving software development practices in an organization can be traced to business value and its interpretation.

We must admit that there is something tautological when we say that the goal of Agile software development is to deliver business value. Business value, intuitively, is whatever the business values, and the goal of every person and function in the business is to do what the business values. To say that we want to deliver business value is to say nothing much except that we want to do the right thing, do lots of it, and do it quickly. But this does not help us understand how to select and prioritize features.

In his 2011 blog post “The Elephants in the Agile Room,” Philippe Kruchten tells of the signers of the Agile Manifesto returning to Snowbird, where the Manifesto was drafted, ten years later to discuss the difficulties they saw in the way Agile had been adopted. The thirteenth “elephant in the room,” according to Kruchten, is that business value is “mentioned everywhere, but not clearly defined, or pushed onto others to resolve.” Perhaps this is also related to the twelfth elephant they listed: “Abdicating responsibility for product success (to others, e.g., product owners).”

The question of business value is the question of purpose, motivation, mission, and direction. It is a question of value and values. If we build an elegant Continuous Delivery pipeline that harmonizes Development and Operations and continually checks its own health by feeding back from production, we have accomplished . . . what, exactly? It depends on what business needs we push through that pipeline, and what business value results from that. DevOps is form without content until we address the question of what goes in to the pipeline and what happens when product emerges at the other end.

Continue reading in The Art of Business Value by Mark Schwartz.

- About The Authors

Mark Schwartz

Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.

Follow Mark on Social Media

• 
•