Value streams are a Lean production concept that describes the series of product life cycle activities required to guide product deliveries from ideation through creation, deployment, support, retirement, and sustainment. As the name value stream implies, the whole point is to ensure all product delivery activities add value. From the perspective of Lean, adding customer-centric value means going beyond the provisioning of features and functions to also eliminate all forms of waste that customers don't want to have added to their costs.

VSM is an approach to methodically eliminate waste and improve productivity and efficiency while lowering costs. More precisely, you will learn that VSM encompasses Lean-oriented methods to improve work and information flow across value streams. Modern VSM tools support the VSM methods initially developed by Toyota as an approach to map material and information flows, and then later introduced to the rest of the world in the early 2000s (Jones, Womack, 2003).

When we get to the sections on Lean-Agile views and VSM, you will also find there are two forms of value streams: operations and development. Let's take a quick look at the differences between these two types of value streams.

Differentiating development from operations

Operations-oriented value streams deliver products and services to an organization's external customers, while development value streams create things used or delivered by the organization's operations-oriented value streams.

Let's put this another way, as follows:

• Operations value streams include the work and information flow that define how your company—or its product lines or lines of business (LOBs)—conducts business, earns revenue, and delivers services to its customers.
• Development value streams include work and information flows to build and support the products, services, and other artifacts used by the operations-oriented value streams to deliver value.

Operations-oriented value streams enhance customer experiences by providing products, information, and services, either online or through personal contacts. In contrast, development-oriented value streams create products and services for either internal or external customers. In other words, development value streams build stuff, while operations value streams need to sell, deliver, and support the organization's customers.

Both functions are necessary and value-adding. However, making a distinction between development and operations is important in terms of purpose, planning horizons, and who controls and funds the activities. For example, LOB executives and product owners have accountability over investment priorities in their operations-oriented value stream activities. In contrast, portfolio management team controls investment priorities over development-oriented stream activities.

Another way to look at this distinction is the operations-oriented processes of selling, delivering, and supporting products. These are tactical activities that provide value to our customers, usually over relatively short planning horizons. Development value stream investments tend to be larger, are critical to the organization's long-term survival, and require longer planning and implementation horizons. In contrast, development-oriented value streams help ensure the organization has the infrastructure, products, and services to meet its strategic objectives.

At first glance, this distinction between development and operations seems to support the traditional IT organizational model. Development teams create software products for both internal and external customers or users, and operations teams exist to keep systems running, secure, and available, while also resolving customer and user issues via helpdesk services.

Later in this book, you will learn that an IT organization implementing Lean-Agile practices should consider moving traditional IT development and operations functions within dedicated product teams. But that is getting ahead of ourselves. We'll come back to that subject later in Chapter 4, Defining Value Stream Management.

For now, let's take a look at some examples of how an IT development-oriented value stream can develop and support software applications for use by other organizational value streams, such as a customer order entry or product fulfillment.

Developing applications to support organizational value streams

The following diagram displays three organizational value streams: order entry, fulfillment, and software development. Order entry and fulfillment are operations-oriented value streams, while the software development activity is a development-oriented value stream:

Figure 1.1 – Value stream examples

Each activity block identifies the activity's name, process time (PT), lead time (LT), and percent complete and accuracy (%C/A) metrics. You learn how to use these metrics later in Chapter 8, Identifying Lean Metrics(VSM Step 5). The main point to understand is that IT is a critical development value stream that improves other operational value streams' delivery capabilities and efficiencies.

This book purposely opened with a discussion on operations- and development-oriented value streams. The current trend is to speak of VSM as a tools-based approach to improve DevOps pipeline work and information flows. DevOps pipeline flow improvements are a great application of VSM. However, your organization is missing the point if its VSM strategy is limited to DevOps. The discussion surrounding the value stream examples depicted in Figure 1.1 clearly shows how IT-based development value streams help improve operational value streams.

This book provides instruction on integrating Agile, Lean, VSM, and DevOps practices to enable business agility on an enterprise scale. These are the methods and tools that allow organizations to provide the right set of products and services customers want rapidly, efficiently, and at the lowest cost. Those organizations that do this successfully, and enterprise-wide, have a leg up when competing in our increasingly digitized economy.

We discuss all these concepts later in this chapter and throughout this book. Before we do, it's essential that you first have a clear understanding of what it means to compete in a digital economy and IT role.

Competing in a digital economy

Don Tapscott introduced the term digital economy in his book The Digital Economy: Promise and Peril in the Age of Networked Intelligence (1997). The book's key focus is on how digital technology changes the way individuals and societies interact.

Later, in 2001, Thomas L. Mesenbourg, then Associate Director for Economic Programs at the United States (US) Census Bureau, delivered a paper titled Measuring the Digital Economy. The paper describes an effort initiated by the US Census Bureau to measure the economic impact of electronic devices as the basis of our then-emerging digital economy.

In his paper, Mesenbourg describes the digital economy as having three primary components, listed as follows:

• E-business infrastructure: This includes all participating computing, network, communication, security, and software systems.
• Electronic business processes that support the digital economy.
• Electronic commerce transactions that support the selling of goods and services online.

Building products for the digital economy

The term digital economy implies something much more significant than Mesenbourg's original e-commerce-centric views in a modern context. For example, digitally enhanced technologies now allow organizations to conduct business on the internet and mobile technologies while providing near-real-time and global access to information and knowledge-based services.

Moreover, digital technologies enhance physical products with new features not possible through simple modifications in materials or mechanical components. Broadly classified as the Internet of Things (IoT), product features and capabilities can be updated, even after delivery to customers.

The key differentiator of an IoT capability is the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. At a conceptual level, IoT is a system of interrelated computing devices with unique identifiers (UIDs) that make them visible to other computing systems and digital devices via the internet and mobile connections.

IoT devices include mechanical and digitally enhanced machines and embedded objects within manufactured goods, people, or animals. As modern examples, your automobile gets factory updates to its computing and navigation systems via mobile connections. Telehealth-based IoT solutions enable real-time monitoring of patient health at long distances via external and embedded monitoring systems. As a final example, embedded biochips with transponders help identify animals and monitor their health and location in the wild and within farms, and can even identify your pets.

Connecting in the digital economy

Our modern digital economy is also more than the scope of e-commerce and digitally enhanced products. The internet has opened up extraordinary communication avenues, information sharing, and collaboration via social media tools and platforms.

Web-based social media tools enable people to interact and share information and experiences across multiple media formats (for example, audio, video, text, photos, images, and so on). Social media is all about leveraging content to drive human-to-human and business-to-human engagements.

Holly Gibbons, President of Gibbons Business Solutions, LLC., lists six categories of social media content that drive engagements (https://gibbons-business-solutions.com/6-types-of-social-media-content-that-drive-engagement/), outlined as follows:

• Promotion: Informing on products and services
• Education: Establishing expertise and enabling self-help
• Connection: Delivering an "insider" view of your business
• Conversation: Specifically targeted to engage customers
• Inspiration: "Feel-good" messages with quotes, facts, and personal stories of success that reflect the vision and values of the person or entity
• Entertainment: Connecting with audiences through sharing holiday wishes, jokes, comics, funny but informative videos, contests, and giveaways

Social media is a transformative capability that helps drive our modern digital economy. The following subsection lists other digitally enhanced business transformations.

Delivering value in a digital economy

Other names for the digital economy include the internet economy, new economy, or web economy. The evolution of the digital economy has forced traditional brick-and-mortar companies to rethink their business strategies or face being driven out of business by fierce competitive disruptors such as Amazon.com (retail), Airbnb (travel accommodations), Google (information searches), Netflix (home entertainment), Lyft and Uber (transportation services), Tesla (automobiles and aerospace), and YouTube (video-based information and entertainment content sharing).

Given their legacy investments in brick-and-mortar-based infrastructures, companies need to rapidly find creative approaches to leverage their traditional economies of scale to compete in the digital economy. In some cases, this means finding different ways of engaging with our customers. In other cases, a blended approach to integrating traditional and digital infrastructures may provide the most competitive advantage.

In any case, companies must define and execute their competitive value propositions. They must evaluate all their investments and activities to ensure maximal contributions to adding customer-centric value. Ultimately, this book introduces many interrelated concepts that help an organization deliver value in a digital economy, but before we get to those sections, we need a shared understanding of what value means. That is the topic of the following subsection.

Diving into the many concepts of value

Semantics is essential in computer science—so important that an entire IT discipline called ontology is devoted to the subject. If you look up the word ontology, you will find that the term's origins come from a branch of metaphysics that deals with the nature of being or what exists. Ontology is a compound word that combines onto (Greek ὄν) and "being; that which is" (gen. ὄντος, ontos). In other words, it's a discipline that seeks to discover what is real.

In the field of information science, Ontology deals with semantic meanings. The problem is that humans have this annoying habit of using the same terms but having very different views on what those words actually mean. Our life experiences, education, and intellectual capabilities greatly influence our understanding of the words we use. This is a primary reason why we humans so often get our communications wrong.

In contrast, traditional information systems must have a precise contextual understanding of the terms and values they employ; otherwise, they cannot correctly exchange information. The same issue applies to human-computer interactions. The words we want to use may not fit the computer's understanding of the term. This dichotomy is what drives much of the research in artificial intelligence (AI). In other words, part of AI research seeks to help computers understand the contextual meaning of words in specific types of human-to-computer interactions.

The word value has many business meanings that support various business practices or desirable business outcomes based on contextual use (that is, the term value means different things, depending on the term's application). As an example that's relevant to this book, Agile, Lean, VSM, and DevOps all share the idea that organizations must deliver value from a customer's perspective. However, they have different strategies to achieve that goal. Moreover, IT specialists and business analysts need to understand that the folks they interact with within other departments may have entirely different thoughts on what the word value means.

Using an analogy, we have a situation a bit like the story of the blind men describing an elephant. Because they cannot see, the blind men have a limited understanding of what an elephant looks like, based only on what they can experience through touch, as shown in the following diagram:

Figure 1.2 – The six blind men and the elephant

For those not familiar with the story, the first blind man touches the trunk and exclaims, "The elephant is like a thick snake"; however, the next blind man touches the ear and says, "No, it's like a fan". Next, another touches one of the elephant's tusks and says, "I don't know what you guys are talking about; it's a spear". The next blind man in line touches the elephant's leg and proclaims, "The elephant is like a big and stout tree trunk", but the blind man who touches the side of the elephant believes they have come up against a wall. Finally, the blind man who touches the tail believes he has caught hold of a rope.

There's only one elephant, but the blind men have different theories of what the elephant is, based on their particular "hands-on" experiences and their lack of a holistic view. The same issues face business analysts when they seek to understand what adds value to a business. So, before we can talk about how Agile, Lean, VSM, and DevOps improve value, we need to spend some time understanding the term's many contextual uses.

This chapter explores the many variants of value with that goal in mind, spanning ownership, accounting, marketing, supply chain, Agile, Lean, and DevOps.

Viewing value from the context of business assets

In its most straightforward context, the term value implies an asset's worth expressed from a monetary, material, usefulness, or personal view—for example, there are many ways to express public companies' business value, such as shareholder value, a firm's monetary value, value capture, fair value, and market value.

Shareholder value relates to the price of a company in terms of the value given to stockholders' shares. The shareholder's value fluctuates on the market's perception of its ability to sustain and grow profits over time. From this perspective, a company's value is roughly equivalent to the number of outstanding shares times the current share price.

Monetary value is an expression of the money an asset—such as a company, product, property, land, or service—would bring if sold. In other words, monetary value is an expression of how much money something is worth on a free and open market. Monetary value determinations come from the dynamics of supply and demand—for example, increasing the supply of a product relative to demand decreases its value. In contrast, limited supplies with high demand drive the price up.

If you talk to a Master of Business Administration (MBA) graduate or an accountant, they may use the term value capture. In their context, value capture describes a process to retain a percentage of the value provided in every business transaction, most often in the form of profit-taking. However, in matters related to public financing, value capture implies using public financing to develop infrastructure that improves a municipality's value as a whole and the value of adjoining commercial properties.

Fair value is an evaluation of business assets (and liabilities) for financial reporting in line with a country's standard accounting practices, often used to assess value in sales, mergers, and acquisitions. The International Financial Reporting Standards Foundation (IFRS Foundation) is a nonprofit industry standards group that defines globally accepted accounting standards, published as IFRS standards. IFRS standard 13 (https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/) defines fair value as "the price that would be received to sell an asset or paid to transfer a liability in an orderly transaction between market participants at the measurement date (an exit price)".

Finally, market value is a determination of what a company is worth under current market conditions. Market value is the estimated price that an asset has in the marketplace or the value that the investment community gives to the equity position—that is, the price a third party pays to obtain a position within a business or other asset in exchange for its stock or securities.

We now have a broad understanding of the term value as it applies to the ownership of businesses and other assets. But the term value can also have a contextual meaning that identifies the importance of specific business relationships, such as value chains and value networks. Value-added (VA) relationships are the topic of the next section.

Viewing value from the context of business relationships

The concept of value in terms of the ownership of business assets is straightforward in contextual use. People and businesses invest time, money, and resources to improve their business asset value, but businesses also gain value by leveraging relationships with suppliers and other partners.

In the most general sense, all external partners provide products or services to support another entity's business goals, though both partners receive value from the relationship. But here, again, we need to carefully define the types of partner relationships to understand the value each provides. For example, a business may have suppliers that deliver components and materials used in their products and deliver them to the consumer. Other partners may resell or rebrand another company's products. There are multiple variants of these relationships, such as reseller, VA reseller (VAR), and original equipment manufacturer (OEM).

A reseller is like a retail outlet that purchases and then resells products to its customers. A retail partner may be a traditional brick-and-mortar company, an online reseller, or a hybrid blend.

A VAR is a firm that enhances the value of another company's products with customizations or services. For example, a recreation vehicle (RV) manufacturer typically buys the bare truck chassis, engine, and tires from one or more primary automotive and truck manufacturers. It then adds the body and internal furnishings that make the vehicle fit for camping. VARs can also provide services around another company's products, such as installation and configuration services, consulting, troubleshooting, repair, or customer support.

An OEM firm typically takes another firm's products and rebrands and sells the original product under their company's name. The OEM can also provide product and service extensions, similar to the VAR type of business VA relationship. Regardless, the OEM procures the primary manufacturer's additional rights to rebrand its products as their own.

Establishing business relationships as value networks

A value network includes any set of connected organizations or individuals working in an integrated and collaborative manner to benefit the group as a whole. A business-oriented value network helps members buy and sell products, organize and distribute work, and share information. While there are many types of value network relationships, they all fall within two broad categories: internal or external value networks.

Internal value networks include people within an organization collaborating to achieve mutual or reinforcing goals. These internal value networks usually work within the bounds of established business processes or value streams. Both business processes and value streams describe structured approaches to work.

The term business processes tends to be associated with traditional cross-functional and bureaucratic organizational structures. The value stream concepts came out of the Lean and Lean Six Sigma approaches to product delivery. Later sections of this book provide much greater detail on the subjects of Lean production and value streams. For now, think of value streams as a series of activities that deliver products and services aligned with customer needs. Moreover, Lean production is an approach to improve product and information flows across value streams.

An organization that scales multiple but small agile-oriented teams, working in an integrated, coordinated, and synchronized fashion to develop and deliver large products, is another example of an internal value network. The Agile teams may also employ Lean product development concepts, often referred to as Lean-Agile methodologies or frameworks.

External value networks describe the cross-organizational interactions of third parties that lie outside the primary business entity's bounds but contribute to its success. In other words, the external value network has a mutual interest in supporting or benefiting from the goals of the primary business entity. In this context, external value networks include agents, business partners, customers, consultants, product users, stakeholders, suppliers, and any other person or entity participating in a value-adding relationship.

Internal or external value networks create value through their relationships, cross-functional or value-stream-oriented processes, and their specific roles within a business enterprise relative to products and services. The relationships must be mutually beneficial—in other words, all parties within the value networks receive value from their relationships. When this is not the case, the networks fail to meet their goals and expectations, and the relationships usually become disruptive. In extreme cases, the networks fall apart and the participants exit their business or employment relationships.

Additionally, participants within value networks must hold up their end of the deal. Ineffectual participants weaken the entire network, and others must step in to fill the void—assuming that is possible. On the other hand, one advantage of having a value network is that the participants can provide the resources, skills, experience, and redundancy to step in and help the weaker elements get up to speed or overcome their limitations.

This section concludes our discussion on value networks. In the next section, we look at a complementary concept referred to as value chains. Instead of looking at VA relationships as networks, value chains describe a company's activities to add value to its products and services.

Establishing business relationships as value chains

Value chains are the processes or activities by which a company adds value to its products and services. Value chains include product life-cycle activities, spanning product ideation, design, receipt of raw materials, and adding additional value through production processes at a more granular level. Value chain processes also include promoting a product, taking an order, and then selling the finished product to consumers.

Michael Porter coined the term value chain in his book Competitive Advantage: Creating and Sustaining Superior Performance (1985). Porter describes the primary value chain activities for adding value and competitive advantage in terms of the following five elements:

• Inbound logistics: Receiving, storing, and processing raw materials and inventories.
• Operations: Converting raw materials into a finished product.
• Outbound logistics: The distribution of products and services to customers.
• Marketing and sales: Including advertising, promotions, and pricing strategies, and managing all sales channels (online, inside direct, outside direct, indirect through resale partners).
• Services: These help maintain products and improve consumer experience—including customer support, product maintenance and repair, refunds, and exchanges.

Value chain analysis offers a strategy to use value chains for competitive advantage. Value chain analysis evaluates the activities involved in changing the inputs for a product or service into an output valued by a particular customer type. A value chain analysis starts with identifying every production step required to create a product and then discovering ways to increase the overall value chain's efficiency.

Michael Porter's view of value chain management (VCM) theories supports the traditional views of using business processes, best practices, organizational assets, and human resources (HR) to achieve a competitive advantage, driving further growth in the market. Michael Porter notes explicitly that his approach is to implement an activity-based theory to drive competitive advantage.

Though his approach sounds somewhat similar to Lean Development concepts, Porter's orientation is oppositional to Lean's initial focus on the customer. Porter advocates a strategy of building and delivering a product cheaper and faster than your competitors, which, in his view, automatically drives new customers and growth. However, Lean practitioners believe we must first focus on customer needs before refining activities to deliver what our customers want—otherwise, we'll miss the mark.

Now that we've made that point, let's explore value from a customer's perspective.

Defining customer value

Customer value is the value received by the end customer of a product or service. In the previous section, you learned that Lean Development strategies emphasize assessing activities to add value and eliminate those that do not add value.

Lean Development strategies make sense because, ultimately, customers are the sole arbitrators of what value means to them. Customers perceive value in terms of utility or usefulness, quality, and benefits. Our ability to deliver what they want is the determinant of customer satisfaction.

But customer value is a tricky thing. It would be nice if all our customers valued the same things. In such a homogenous world, we would only have to produce one variant of a product and be the most efficient producer. Of course, we would also have to be competitive across marketing, sales, delivery, and support processes. Such a market supports Michael Porter's view of using value chains to create a competitive advantage.

But that's not the world in which we live. Instead, customers have different budgets and different desires in terms of the features and functions they prefer. In a traditional mass-production model, marketing and sales organizations try to influence customer behavior by telling customers what they should like about their particular products and services. That strategy allows the producers to follow Michael Porter's guidance on improving value chains.

That strategy might work for a while, but only up to the point where other competitors start asking customers what they want and then deliver better offerings. As a result, customer-oriented value delivery strategies had to evolve. By the 1980s and 1990s, customer relationship management (CRM) and Lean Development strategies became mainstream practices, to focus on adjusting product development and delivery efforts to address customer needs for mass markets and profitable niche markets.

Lean manufacturing, also known as lean production, is a modern instantiation of production methods derived initially from Toyota's operating model, known as The Toyota Way and the Toyota Production System (TPS). The term Lean did not come from Toyota but was instead coined in 1988 by John Krafcik, who was then studying management and performing research under the direction of James P. Womack. Krafcik's research was part of a 5-year study at Massachusetts Institute of Technology (MIT) on the automobile's future. Krafcik's research produced much of the data referenced in the book The Machine That Changed the World (Womack, Jones, Roos; 1991). But it was Womack's, Jones', and Roos' book that articulated Lean manufacturing concepts and introduced the term lean production.

The lean concepts defined by James Womack and Daniel Jones contain five fundamental principles, outlined as follows:

• Precisely specify value by specific product
• Identify the value stream for each product
• Make value flow without interruptions
• Let customers pull value from the producer
• Pursue perfection (Womack and Jones, 1996, p.10)

CRM is a data-centric approach to managing information and interactions with customers and prospects. Specifically, CRM methods and software tools apply data analysis techniques to customer data, to better understand their history with the company and improve customer relationships. CRM is primarily a marketing-oriented function supporting their objectives to improve customer retention and drive new sales growth.

With CRM and Lean, organizations have the tools to determine what value means from a customer's perspective and then align organizational activities and resources to deliver that value. Some other methods and tools aid in identifying customer perceptions of value—for example, marketing and product management functions may conduct focus groups and initiate surveys to collect customer data. In turn, that data helps support analysis across analytical techniques, such as the following:

• Voice of the customer: A term used to describe the process of capturing customers' expectations, preferences, and dislikes.
• Customer utility map: A map of six utility levers to deliver exceptional utility to buyers against six stages of various buyer-experience cycles.
• Kano model: A method to understand, categorize, and prioritize five customer requirements (or potential features) for new products and services.
• Customer journey map: A diagram to illustrate the steps your customers go through to engage with your company, be it a physical product, an online experience, retail sale, a service, or some combination of all of these.
• Empathy map: A method used by user experience (UX) designers to understand user behavior and also visually communicate findings to other stakeholders, to provide a shared understanding of the prospective user.
• Customer value management (CVM): A method to assess the perceived value of an organization's product and service offerings. Value is assessed in terms of benefits, functions, and performance to the price, the cost, and profit margins.

This subsection concludes our discussion on the various definitions of value and why products and services must consistently deliver value from the customers' perspective. We've also learned how CRM methods and tools with Lean practices help us discover and deliver value to our customers. But how does a business entity know if they have a viable value proposition? That is the topic of the next section.

Michael J. Lanning coined the term value proposition in his published writings related to his work as a consultant at McKinsey & Company. His work pioneered concepts in developing corporate strategies, goals, and business capabilities to customer needs. Lanning outlined his concepts in his book Delivering Profitable Value: A Revolutionary Framework to Accelerate Growth, Generate Wealth, and Rediscover the Heart of Business (Lanning, 1998).

Lanning views value from the perspective of customer experiences and therefore defines the term value proposition as follows:

The combination of resulting experiences, including price, which an organization delivers to a group of intended customers in some time frame, in return for those customers buying/using and otherwise doing what the organization wants rather than taking some competing alternative.

In other words, the term value proposition implies an explicit relationship where targeted customers gain experiences from the products and services delivered by an organization, though bounded within an established time frame (that is, values can and do change over time).

The term also sets expectations that the customers must purchase, use, and otherwise do something the delivery organization wants instead of selecting a competitive option. A competitive option is not limited to the customer purchasing a competitor's products or services. The customer may choose to do nothing or to create the desired experience with their internal resources.

Note also that the value proposition definition does not directly address its use as a marketing and selling communications tool, though many people view the term's relevance from this perspective. Customers value the experiences they receive or not from using an organization's products and services. Therefore, the critical issue is to ensure an organization works in concert to deliver the desired experiences and not merely promote features or functions that may or may not be relevant.

Unfortunately, the term value proposition is most commonly used in a limited context by marketing and sales professionals as a statement of how to position a commercial product or service competitively. But that type of limited focus misses the point of Lanning's primary work, which is to align the organization with its corporate strategies to deliver profitable value. From this perspective, everyone within the organization plays a role in delivering profitable value.

That statement does not mean that marketing staff should not use value propositions to properly communicate their organization's value or for sales staff to use a value proposition to make sure they're selling the right experiences to the right customers. However, metaphorically speaking, there are two questions an organization must first address, outlined here:

• Who's driving the ship?
• Did the rest of the crew get on board?

Later sections of this book introduce value stream mapping techniques to identify and eliminate all forms of waste across an organization's value stream activities. But how would the value stream teams know which outcomes they need to align their activities to from a VA perspective? That is the proper goal of building compelling value propositions, accomplished by answering five simple questions.

Aligning business strategies through five questions

Value propositions answer five critical questions about how an entity plans to deliver value. These questions are listed here:

• Who or what are the target market customers?
• What is the planning and execution life cycle horizon for the value proposition?
• What do we want these target market entities to do in exchange for the experiences we deliver?
• Which competing alternatives do these customers have to obtain the desired experiences?
• Which resulting experiences do the customers receive (including price) versus the competing alternatives, assuming the customers do as we ask?

As a further note, Lanning makes it clear that resulting experiences must be specific, actionable, and comparative. He also notes that winning value propositions are trade-offs in that some experiences are inferior to the competitive alternatives. Therefore, what matters is optimizing experiences in total (Lanning, 1998, p. 62).

Creating a vision for the organization

Value propositions serve as strategic documents that help focus and integrate an entire business to communicate its purpose. A value proposition is a choice made by leadership that aligns with their organizational strategies, objectives, and mission. Most importantly, a value proposition expresses a vision that most benefits their target market customers.

In this context of value, the executive leadership is not responsible for deciding which products and services the organization must deliver to its customers, or even deciding how to create and deliver those products and services. To do so is an example of internal-facing product strategies that revolve around what leadership wants to do.

Yet the answer isn't to turn the question around and ask customers what your organization's value proposition should be. In that scenario, chasing customer opinions can quickly become futile as there are many different niches of customers who have different experiential preferences, and chasing specific customer preferences can inappropriately send the organization in the wrong direction from adding value to the broader or more lucrative target market clients.

Later, you will learn how to identify and prioritize customer needs as actionable work items in a product backlog. For now, it's essential to understand that an organization must eventually turn its attention to developing specific value-adding features and functions, but it's also dangerous to start such efforts until after the organization establishes its vision and can express it completely via its value proposition.

Successful leaders tend to be highly creative, and often visualize and articulate a vision for their businesses long before customers understand they need them. Examples include Steve Jobs and Bill Gates, who both saw an opportunity to bring the power of computers to the masses, forming Apple and Microsoft, respectively. Jeff Bezos, the founder of Amazon.com, imagined an online retail bookstore to change the way readers review and purchase books. Ultimately, Bezos dramatically changed the customer retail experience. Once he successfully figured out the online retail model for books, he imagined expanding the model to market and sell virtually anything and, in the process, became the wealthiest person in the world.

Elon Musk is another business leader who has used his creativity and brilliance to define multiple market opportunities. For example, he established Tesla, Inc. to mass-produce electric cars, the Boring Company to build underground tunnels to improve transportation in congested areas, and SpaceX to build reusable rocket ships that can land on their tails.

What's important to note with this latter example is that Elon Musk did not try to merge all these unique value propositions into one company. Organizations with multiple value propositions should create sufficient separation between disparate product lines to avoid confusing their customers.

Organizations may choose to separate product lines across departments, divisions, or companies. The degree of product-line separation is primarily dependent on the variances between their value propositions. The principle to appropriately differentiate products by their value propositions holds for both digital and physical products.

Delivering value

You learned in the previous section that successful chief executives are creative and often visualize new product ideas before prospective customers see a need for them. However, coming up with a creative idea is just the start. The organization's leaders collectively refine the initial vision by answering the five questions identified previously.

In the process, the leaders deliberate and articulate their shared vision within the value proposition document. In the end, the value proposition defines the business the organization is in, who their prospective customers are, and the types of experiences the business must deliver to gain their custom.

The title of Michael J. Lanning's book is Delivering Profitable Value. Organizations only survive when they obtain an adequate return on investment (ROI) to justify investments. Without sufficient funds, a business is unsustainable, so the profit objective is immediately apparent. The remaining part, delivering value, is equally critical. The ability to deliver value is what enables profitability.

In the context of value propositions, Lanning provides a set of expanded definitions for value and value delivery, as follows (Lanning, 1998, p. 316):

• Value: The net desirability customers perceive in some resulting experience(s) in comparison to some alternative—what those customers should be willing to pay accordingly
• Value delivery: Choosing, providing, and communicating some resulting experiences, including price
• Value delivery chain: The entities of relevance to a business—including suppliers, intermediaries, primary entities, customers, and offline entities—understood as delivering value to each other and as one interconnected set of relationships
• Value delivery focus: Understanding the business in terms of choosing, providing, and communicating a desirable set of resulting experiences to prospective customers
• Value delivery framework: The whole set of questions and corresponding actions of the primary and supporting value delivery system (VDS), understood in the context of the value delivery chain
• Value delivery option identification: Exploring a market space to discover which primary VDS is viable in contrast to conventional market segmentation
• Value delivery system (VDS): The end-to-end (E2E) business system working in collaboration and as a community to deliver a complete value proposition

This section concludes our discussion on value propositions. Before we end this chapter, you will learn about value from Agile, Lean, VSM, and DevOps contexts. But before we get to those topics, we need to take a quick look at the traditional business concepts related to creating value. This topic is addressed in the next section.

Ultimately, this book is about value creation and an organization's ability to create value on demand, efficiently, and continuously. Most importantly, our efforts to deliver value must align with our customers' perspectives on what adds value to their experiences with our organization and our products and services.

The definition usually ascribed to the term value creation is relatively broad, and we need to understand what people mean when they use that specific term. In its simplest expression, value creation is any process or activity that creates outputs that have more value than its inputs.

Displays of the input-transformation-output process (a.k.a. the input-process-output (IPO) model) incorporate a functional graph that displays the inputs, outputs, and required processing tasks required to transform the inputs into outputs. See the following diagram for an illustration of this:

Figure 1.3 – IPO model example

The inputs represent the flow of information and materials into a process from external sources. The processing step includes all activities (steps or tasks) required to transform the inputs into something of value. The outputs are the enhanced data and materials flowing out of the transforming process.

The IPO graphic displayed in Figure 1.3 demonstrates a value-adding activity. The value-adding process increases the value of goods and services and, by extension, improves the value of the business. The value transformation process only works if customers desire the outputs sufficiently to acquire them. It's the creation, delivery, and acquisition of value by customers that drives, in turn, shareholder value.

From a financial or management accounting perspective, we convert inputs to create outputs that drive monetary value across the value chain of an organization's products, services, and processes. However, the financial definition of creating value is limited and does not capture the full measure of the things that add value within an organization. Equally important are relentless and continual innovations, the labor and ideas of people, and branding.

As Lean-Agile and DevOps practitioners, you own the efforts associated with relentless and continual innovations, plus you provide the labor and ideas to generate value from digitally enhanced products and services. In addition, the product management and marketing functions are responsible for branding as part of their demand-creation efforts (that is, promoting the product's value proposition to create brand awareness and thereby generating customer demand to acquire the product).

Keep this simple IPO model in mind, as it forms a basic graphical approach to viewing most value stream activities. The primary difference is that we'll decompose the process function to show all associated activities and their value-adding interrelationships.

In the previous section on value propositions, you learned that our customers' experiential-based perceptions of value change over time. For that reason, value creation hinges on an organization's ability to create value on demand, efficiently, and continuously. In other words, an organization is under constant stress to change, and change is challenging in the best circumstances.

Change at a macro level occurs when an organization defines a new business strategy and potentially profitable value proposition. This type of change is much harder, especially when the organization needs to evolve from its traditional hierarchical and bureaucratic organizational structure.

Such change cannot occur solely through mandates, as any business transformation strategy of this magnitude fails without executive support and leadership, proper planning, and a controlled rollout. We'll table this topic for now and revisit it in Chapter 6, Launching the VSM Initiative (VSM Steps 1-3)

In the context of Agile's values and principles, change occurs at a micro level quite frequently, with every development iteration. This type of frequent change occurs because small, autonomous, and self-sufficient teams automatically self-organize to deliver the expected incremental value achievable within the planned time horizon— usually 1 to 4 weeks.

Moreover, at the end of each iteration, the teams conduct retrospective events to evaluate areas for improvements, and those improvements should begin in the next iteration. Teams operating with agility implement processes, such as Scrum, use change to their advantage when delivering customer-centric value in a repetitive and controlled fashion.

The following section describes the essential values and principles of Agile and Lean Development concepts.

Lean-Agile practices blend the values and principles outlined in the Manifesto for Agile Software Development, more commonly referred to as the Agile Manifesto, with the Lean Development practices initially developed at Toyota and further elaborated by John Krafcik (Krafcik, 1988), James Womack, and Daniel Jones (Womack, Jones; 1990, 2013), and Mary and Tom Poppendieck (Poppendieck, 2003).

Note

My previous book, Scaling Scrum Across Modern Enterprises, provides much greater detail on the subject of Lean-Agile concepts and practices. This section provides a gentle introduction, sufficient to understand the applications of Lean-Agile practices described in later sections of this book.

Understanding the values and principles of Agile

In 2001, 17 software developers came together at a resort in Utah to discuss their software development views to see if there was common ground from which they operated. Though many of the participants were competitors or ascribed to different software development methodologies, they found common ground in their values and principles. Jim Highsmith described their result as the "mushy stuff of values and culture" in software development (https://agilemanifesto.org/history.html).

The Agile Manifesto established 4 values and 12 principles that articulate an agile software development approach.

The essential elements of the Agile Manifesto are its values, which are expressed as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken Schwaber

Alistair Cockburn Ron Jeffries Jeff Sutherland

Ward Cunningham Jon Kern Dave Thomas

Martin Fowler Brian Marick

One of the signatories of The Manifesto for Agile Software Development is Jim Highsmith. He built and maintains the website that includes additional details of the event and the attendees' findings. The Uniform Resource Locators (URLs) for those pages are provided here:

• Manifesto for Agile Software Development: https://agilemanifesto.org/
• Principles behind the Agile Manifesto: https://agilemanifesto.org/principles.html
• History: The Agile Manifesto: https://agilemanifesto.org/history.html

These software developers represented or used lightweight software development practices to avoid the pitfalls of the traditional plan-driven and linear-sequential SDLC model (a.k.a. Waterfall). Since they used competitive methodologies, they did not find common ground across their disparate SDLC practices, but instead, found common ground in the written abstraction of their shared values and principles.

In a modern context, Agile-based software development practices have the following in common:

• Iterative and frequent development cycles.
• Incremental releases of customer-centric value.
• Small, autonomous, and self-contained teams that are nimble, adaptable, and able to self-organize to perform whatever relevant work comes their way (that is, we don't expect software development teams to perform marketing or sales-oriented work).
• Frequent interactions with customers to demonstrate the new increments of value and receive their feedback.
• Developers need the freedom to learn from experimentation, knowing they might fail, but also know to keep their failures small across brief development increments.
• Frequent retrospectives to assess areas for improvements and implement action plans to install those improvements in the next iteration.
• Technical excellence and good design enhance a team's abilities and agility.
• Diversity and respect among team members are critical elements for evolving and achieving ongoing success as a functional team.

Beyond these simple principles, software development teams are free to use whichever methods and tools they prefer. The 17 participants represented at least 7 lightweight software development methodologies. Of those 7 approaches, among others, Scrum went on to become the de facto standard for implementing small team agility.

This introductory section concludes our discussion of Agile. We'll now move on to introduce the concepts of Lean Development, and in particular, its modern relevance to Agile software development.

Reviewing the fundamentals of Lean Development

As noted in an earlier section, Defining customer value, Lean Development concepts evolved initially at Toyota. Toyota was not shy about sharing their ideas across their value chain partners and later—on a larger scale—to manufacturing companies across industries via the promotion of a booklet titled The Toyota Way 2001. They were committed to helping their value chain partners, as those efforts paid dividends in improving their value streams.

In 2004, Jeffrey Liker summarized his view of The Toyota Way via 14 fundamental management principles (Liker, 2004). I also provide examples of these principles in my book, Scaling Scrum Across Modern Enterprises.

As a quick introduction, the following list contains a summary of each management principle:

• Lean is a long-term management philosophy.
• Focus on establishing continuous flows to surface problems quickly and eliminating waste.
• Use a pull-oriented approach to order and materials entry based on demand.
• Eliminate all forms of batch processes.
• Build things right the first time, and stop production immediately when problems arise.
• Standardize tasks and processes across your value streams.
• Use visual controls such as Kanban boards to avoid hiding problems.
• Use only thoroughly tested and reliable technologies selected by your people to support their processes.
• Grow your future leaders, who already understand the work and organizational philosophies and who can teach it to others.
• Develop exceptional teams and people.
• Respect and help improve your extended network of partners and suppliers.
• Practice Gemba—go and see for yourself what's going on in the organization.
• Make decisions slowly, by consensus, and only after due diligence and consideration.
• Become a learning organization through reflection and continually improving.

Since this book is about Lean-Agile practices to improve an organization's competitive position in a digital economy, let's move on to discuss Lean Software Development practices.

Implementing Lean Software Development practices

Mary Poppendieck and Tom Poppendieck coined the term Lean Software Development in a book they wrote in 2003 by the same name. Their book was the first widely promoted example of employing traditional Lean Development practices to software development. Besides adopting and applying 7 Lean principles to software development, Poppendieck's identified 22 Lean thinking tools that aid in applying Lean to various Agile practices.

The Lean principles include the following:

• Eliminate waste: Remove anything from an activity that does not add value from the perspective of our customers.
• Amplify learning: Dedicate time and resources to learning and experimentation to improve skills, technologies, and processes.
• Decide as late as possible, to keep your options open.
• Deliver as fast as possible, through integration and automation of SDLC and operational support processes.
• Empower the team: Let the people doing the work make the most of their decisions, as they are most knowledgeable and closest to the work.
• Build integrity in: Build software systems with coherent architectures, usability, and fitness for purpose that are maintainable, adaptable, and extendable.
• See the whole: Avoid specialization of practices as specialists tend to optimize systems around their specific goals and interests.

The disciplines of Lean and Lean Software Development and the Lean tools recommended by the Poppendiecks are too broad to get into within this chapter. We revisit these topics throughout this book. But for now, let's move on to introduce the concepts of value streams, their purpose, their types, and how we define them.

Delivering value through value streams

James Womack, Daniel Jones, and Daniel Roos often get credit for defining the term value stream in their book, The Machine that Changed the World (Womack, Jones, Roos; 1990). Womack indeed discussed value streams in his later books, such as Lean Thinking (Womack; 1996, 2003) and Seeing the Whole Value Stream (Womack, Jones; 2003). However, James Martin was the first to define the concepts of value streams in detail in his book The Great Transition: Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, and Strategy (Martin, 1995).

It's easy to associate value stream concepts with the concepts of value stream mapping in Lean, but that's an incorrect association. Martin briefly introduces lean manufacturing concepts in his book, but his association of value streams with lean manufacturing applies to reinventing workflows around customer value (Martin, 1995, p. 102). In contrast, value stream mapping is a visual technique to assess information and material flows. We'll talk more about value stream mapping in the following subsection.

Martin defines value streams as an "end-to-end collection of activities that create a result for a 'customer', who may be the ultimate customer or an internal "end-user" of the value stream". Martin also notes that a value stream must have a clear goal to satisfy or delight. Martin introduces value streams as an approach to reinvent business processes to support customer needs by developing products in the most "simple, direct, and narrowly focused fashion".

Martin wrote his book when business process reengineering (BPR) was a mainstream concept, and IT organizations worked with functional and cross-functional business organizations to streamline and automate critical business processes. Martin keenly observed that business processes traditionally evolved through successive changes driven by internal needs and not by customer needs. As a result, many business processes are bloated, inefficient, and anything but customer-centric.

Martin introduces his value stream concepts as an E2E redesign of business processes at the activity or task level to create better flows. Martin makes the point that too many business systems evolved to support then-existing business processes, and those underlying processes too often evolved to support dubious agendas and objectives.

A better approach is to eliminate the concept of business processes and instead have organizations reevaluate their enterprise as a collection of value streams, all of which likely need reinventing. This approach identifies what customers value and then assesses an organization's collections of activities that deliver the value (that is, value streams). The next step is to streamline the identified value streams. Only then should an organization consider developing information systems and automation to support their newly formed value streams.

In a modern Lean-Agile and DevOps environment, we can go faster, but the Lean-Agile concepts evolved after Martin's book came out. Today, value stream identification and value stream mapping are critical components of the Lean-Agile practitioner's toolkit.

Identifying value streams

Value streams are component processes of the broader and integrated business system that describe how stakeholders—either internal or external customers—receive value from an organization. A business value stream includes a series of steps or activities necessary to provide the products, services, and experiences our customers desire at a more fundamental level.

Value streams can support product development and delivery activities and any other customer-facing services. While development-oriented value streams can provide products and services directly to customers or resale partners, a more typical scenario is that they deliver products and services to operations or customer-facing value streams. Steps that do not add value represent waste in the eyes of the customer—in other words, customers do not want to pay for things that add waste without adding value.

It's easy to think our customers won't know about these extraneous activities, but in a competitive market, you will be quickly outed by your competitors who are paying attention and providing better customer-centric value for the money.

Lanning's concept of evaluating value as desirable customer experiences gives us a model to define our value streams. So, let's quickly look at the things customers commonly want from their product, service, and solution providers, outlined as follows:

• Open, available, and easy access to knowledge:

  a. About products and services

  b. Comparative information—from the company, trusted representatives, and industry experts

  c. Product and pricing information

  d. Procurement—How and where to acquire the products and services

• Simplified and possibly real-time order entry
• Products developed with desired quality, features, capabilities, and costs
• Upsell of product upgrades and services that may make their experience even better
• Fulfillment—delivered when and how the customer prefers
• Customer support—available on demand when needed; sufficient to answer their questions and resolve any problems they may be experiencing
• Ongoing product maintenance and enhancements

This list is incomplete but is a good starting point for this discussion. Various organizational departments collaborate to define and create value streams, though specific departments may lead efforts in defining selected value streams—for example, product management usually takes the lead in defining target markets and the customers' relevant needs. In contrast, the marketing department defines the value streams necessary to create customer awareness.

Mapping value streams

In the previous section, you learned that James Martin refined the definition of the term value stream and that the lean concept of value stream mapping is separate. Martin used the term value stream to articulate the need to reinvent workflows around customer value.

Value stream mapping, also known as material and information flow mapping, is a Lean method to map and assess the current as-is and desired to-be future states of activities across the life cycle of a product or service. In other words, value stream maps provide a visual aid to document and evaluate the flow of work from the initial request through development and delivery until it reaches the customer.

As an interesting side note, the concept of mapping the flow of information and materials predates Lean, dating back to a book written in 1918 by Charles E. Knoeppel, titled Installing Efficiency Methods. Today, value stream mapping is more commonly associated with Lean manufacturing and Lean Software Development practices.

Toyota applied value stream mapping as a standard practice within The Toyota Way. Mike Rother and John Shook studied Toyota and then published a book on what they discovered on this topic, titled Learning to See: Value Stream Mapping to Add Value and Eliminate Muda. Later, Mary and Tom Poppendieck introduced Lean Software Development, in their book by the same name. Their book made value stream mapping a mainstream technique in the Lean community.

The following diagram shows a value stream map example of current and future states. We will not get into any further details on value stream mapping here. Instead, we'll hold off until Chapter 7, Mapping the Current State (VSM Step 4):

Figure 1.4 – Current/future value stream map

This section concludes the section on Lean-Agile concepts. The following section introduces VSM concepts, methods, and tools, and also introduces value stream mapping techniques and how they are used to identify the as-is status of a value stream and one or more desired to-be states that deliver value improvements. In the process, you will discover that development-oriented value streams feed operations-oriented value streams.

Section 2, Implementing Value Stream Management (VSM) - To Improve IT Value Streams, of this book provides comprehensive guidance on the methods and tools associated with VSM and introduces some of the leading VSM software products. We'll also introduce basic VSM concepts in Chapter 6, Launching the VSM Initiative (VSM Steps 1-3) Before we get to those subjects, this preliminary section aims to explain the relevance of VSM in helping organizations realize value.

Building on the foundations of Lean

If you only read recent literature on VSM, you may come away thinking VSM is an enhancement to Agile and DevOps practices that's limited to improving IT-related value streams. That's a mistake, as the practices originated Lean Manufacturing and Lean Development strategies that go back to the TPS evolution. Japanese industrial engineers Taiichi Ohno and Eiji Toyoda helped define these practices from 1948 and 1975. Toyota maintains and continues to refine its lean practices as part of its The Toyota Way initiative.

Toyota's Lean manufacturing and Lean production development practices created a significant competitive advantage that the rest of the world began to notice. By 1979, and under the guidance of James P. Womack, Ph.D., MIT initiated a multi-year International Motor Vehicle Program (IMVP) research program to study automotive value chains and Lean processes worldwide.

In 1991, James P. Womack, Daniel T. Jones, and Daniel Roos published the results of their work in a book titled The Machine That Changed the World: The Story of Lean Production, which helped make Lean production mainstream globally. Though their work focused on the automotive industry, in the epilogue of their book, the authors point out that they fully expect lean production to become the 21st century's standard global production system.

Business entities must adopt Lean production processes to compete effectively, while also leveraging IT to provide products relevant within our digital economy. The software industry was quick to see the advantages of implementing lean production concepts. Leading the charge were Mary and Tom Poppendieck, who wrote the famous book (at least in the Agile community), titled Lean Software Development: An Agile Toolkit.

Those of you who would like to learn more about Lean production and Lean software development can read my previous book, Scaling Scrum Across Modern Enterprises. Specifically, Chapter 5, Driving Business Value through a DevOps Pipeline, introduces Lean production concepts, while Chapter 6, Launching the VSM Initiative (VSM Steps 1-3) introduces Lean practices in software development.

VSM is about improving an IT organization's Lean value streams but does not replace Agile's values, principles, and practices. IT's current trend is to concatenate Lean and Agile practices as an integrated strategy, with VSM the glue that binds them together. Let's see why.

Building on Agile

VSM cannot be limited to merely installing a new discipline of agile software development. That strategy would be a bit of an overkill. For example, Dave Thomas wrote an important article titled Agile is Dead (Long Live Agility) (at https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html) that suggests we've overly complicated the concepts of Agile software delivery. He's not wrong.

If we accept Dave Thomas's premise that we are already making agile software delivery too hard, what value does the additional overhead and complexity of VSM provide? It's a good question, so let's take a closer look at the origins of VSM concepts and processes and how they affect IT value delivery organizations.

Defining VSM concepts and processes

The term VSM did not originate as an IT-related acronym. For example, Peter Hines et al. use the term in their book Value Stream Management: Strategy and Excellence in the Supply Chain (Hines et al., 2000). Their book documents a research program involving nearly 20 manufacturing, retail, and service companies. Conducted by the Lean Enterprise Research Centre (LERC), the study's objective was to apply lean production concepts to understand value and waste in the supply chain environment.

The conglomerate's broader goals were to improve, expedite, and sustain development activities across supply chains, primarily in the automotive, electronics, and fast-moving consumer goods markets. The authors use the term VSM to communicate their findings that Lean enterprises must install and manage long-lived programs to reduce waste actively and continuously across their supply chain value streams (Kaizen).

In its modern context, VSM is a lean business practice to improve software value delivery and the efficient use of IT resources. Employing Lean Software Development concepts, VSM helps IT organizations improve the flow of value to their internal and external customers.

The modern context of VSM also centers on using software tools and integrated platforms to improve DevOps pipeline flows. However, organizations that employ Lean Software Development practices can achieve many Lean production improvements without using VSM tools. Always remember—methods come before tools!

Similar to how DevOps pipelines integrate and automate an IT organization's development and operations-oriented (development and operations) processes, VSM tools help integrate and automate Lean value stream improvement activities. Modern VSM tools also provide direct capture of metrics and analytics to guide improvement options. Modern VSM tools help integrate and automate value stream mapping, measuring, monitoring, and analyzing activities across DevOps pipelines. They also support the improvement of all organizational value streams.

Still, we need to build our foundation on proven VSM methods before leveraging the tools.

Learning methods before tools

Don Tapping, Tom Luyster, and Tom Shuker present a rigorous VSM methodology in their book Value Stream Management: Eight Steps to Planning, Mapping, and Sustaining Lean Improvements (Create a Complete System for Lean Transformation!) (Tapping, Luyster, and Shuker, 2003). Their book describes VSM as a data-centric and analytical approach to plan and link value stream initiatives.

The purpose of Tapping's, Luyster's, and Shuker's book was to simplify the Lean Development concepts of demand-based pull, flow, and production leveling as an eight-step process to help accelerate, coordinate, and sustain Lean Development practices, which they called VSM. In later books, Tapping and Luyster applied their VSM concepts to all organizational value streams, such as manufacturing, customer services, engineering, payables, and—of course—IT.

Both Don Tapping and Tom Luyster were kind enough to allow us to incorporate their eight-step VSM approach as the foundation VSM methodology for this book. However, from Chapter 6, Launching the VSM Initiative (VSM Steps 1-3), through Chapter 10, Improving the Lean-Agile Value Delivery Cycle(VSM Steps 7 and 8), this book applies their VSM methodology to improve flows across an Agile-based team's implementation of CI/CD concepts and tools.

Their eight VSM steps are listed here:

1. Commit to Lean.
2. Choose a value stream.
3. Learn about Lean.
4. Map the current state.
5. Determine Lean metrics.
6. Map the future state.
7. Create Kaizen plans.
8. Implement Kaizen plans.

Note that Tapping and Luyster's eight-step VSM process does not explicitly identify IT practices—that's because IT is just another value stream among many in the Lean enterprise. On the other hand, as noted previously, IT is a critical development-oriented value stream that supports virtually all other organizational value streams in a digital economy.

This book's central premise is that IT product requirements and Product backlog items can come out of any value stream across an organization, some supporting internal customers' needs while others support external customer needs. Similarly, some IT development teams may support individual internal or external value streams in a multi-team agile development environment. Nevertheless, VSM's foundational Lean-improvement concepts apply universally.

Chapter 6, Launching the VSM Initiative (VSM Steps 1-3) contains detailed descriptions of each of the eight process steps as a general approach to employing Lean practices organization-wide, including IT. But before leaving this section, let's take a quick look at how the IT industry currently views VSM.

Implementing VSM in IT

Chapter 6, Launching the VSM Initiative (VSM Steps 1-3), explains how to identify value streams before mapping the current and desired future states. Identifying value streams is the more challenging of the two tasks and the most critical, as everything related to making lean-oriented improvements starts from there.

Traditionally, software development teams think of instantiating functional and non-functional requirements as software features and functions. However, in the Lean/VSM model, the development and operations teams focus on improving activities to deliver a continuous customer value flow.

Customer requirements do not go away in software development teams operating as value streams. Functional and non-functional requirements, along with bug fixes and addressing technical debts, all become inputs to the development-oriented value streams. The outputs are developed features and capabilities. Those are important concepts to keep in mind when we get to Chapter 6, Launching the VSM Initiative (VSM Steps 1-3).

In a modern context, VSM implements methods and tools that help organizations increase the value they deliver to customers by optimizing workflow across their value streams. Moreover, VSM often employs software technologies to integrate suites of tools to form robust VSM platforms (VSMPs).

One of the industry-leading VSMP vendors, Plutora, in their article titled Value Stream Management Platforms (at https://www.plutora.com/), lists nine key VSMP capabilities that help organizations to achieve their software goals, as shown here:

• Tool integration and interoperability
• Common data model
• Mapping people, processes, and data
• Governance and compliance
• Value stream key performance indicator (KPI) data capture and measurement
• Data analytics and analysis
• Dashboards and visualization
• Financials and budgets

In Section 2, Implementing Value Stream Management (VSM), of this book, you'll learn how these VSM capabilities help an organization improve its value streams. Plus, you will learn the basic methods that implement these capabilities. But since this is the main topic of this book, let's first look at how industry analysts assess the importance of this emergent field in IT.

Promising VSM growth

VSM applied to software development practices, and especially VSMPS, are both considered emergent concepts. However, several leading IT industry analysts, such as Forrester Research, Inc. and Gartner, Inc., now consider VSM a vital requirement and an exponentially growing trend.

For example, Forrester publishes a periodic Forrester Wave™ for VSM, with assessments of the leading VSM vendors by scores and weightings. The latest version, Forrester Wave™: Value Stream Management, Solutions, Q3 2020, provides assessments of the 11 leading VSM vendors.

Likewise, Gartner follows the VSM industry and recently released its Gartner Report titled [Gartner] Predicts 2021: Value Streams Will Define the Future of DevOps. Gartner states: [to] accelerate development and enable continuous delivery of customer value, organizations need to reach the next level in their agile and DevOps practices. I&O leaders and application leaders must focus on value stream management to maximize flow, improve delivery efficiency and drive innovation.

In the report, Gartner goes on to list its strategic planning assumptions for VSM, as follows:

• By 2023, 70% of organizations will use value stream management to improve flow in the DevOps pipeline, leading to faster delivery of customer value.
• By 2023, the use of value stream delivery platforms to streamline application delivery will grow from 10% to 40%.
• By 2023, 60% of organizations in regulated verticals will have integrated continuous compliance automation into their DevOps toolchains, improving their lead time by at least 20%.
• By 2025, 60% of I&O leaders will implement chaos engineering to add resilience and velocity improvements to value stream flow, increasing system availability by 10%.
• Through 2025, 20% of enterprises will go beyond SRE by adding IT resilience roles to improve resiliency posture between product teams and traditional DR.

(Gartner, Predicts 2021: Value Streams Will Define the Future of DevOps, Daniel Betts, Chris Saunderson, Ron Blair, Manjunath Bhat, Jim Scheibmeir, Hassan Ennaciri, October 5, 2020)

VSM appears to be growing in use and here to stay. Now, let's take a quick look at how VSM is complementary to DevOps practices.

At this point, you should have a pretty good handle on what the term value means in the context of Lean-Agile and VSM practices. In this section, we'll explore how DevOps supports the delivery of value. We'll start with a quick introduction to the basic concepts behind DevOps and how it helps instantiate at least some of the values and principles of Agile.

Delivering value in IT

Mature IT organizations install the values and principles outlined in the Manifesto for Agile Software Development to improve their focus on the customer, speed of delivery, and efficiencies. Organizations do not need to integrate or automate their Agile-based SDLC and operations-oriented processes to achieve significant benefits. On the other hand, those organizations that do can rapidly accelerate their pace of delivering new value.

Moreover, IT organizations receive even more significant benefits by improving communications and integration between development and operations. The feedback from operations helps development teams create a more VA, sustainable, and higher-quality product. The collaborations also help the development teams deploy products that are easier to deploy, configure, secure, and roll back when necessary.

It's not wrong to think of DevOps as a reengineering of the IT function. How much reengineering is dependent upon the current state of the IT organization. Those organizations still practicing traditional Waterfall-type practices require more significant changes to their processes and culture than those who practice agile-based approaches such as Scrum or eXtreme Programming (XP). Agile-based methodologies already reengineer traditional SDLC processes from a linear-sequential development life cycle process to an iterative and incremental development cycle, from a practical standpoint.

At first glance, the individual activities of Waterfall and Agile look kind of similar. For example, both approaches include the following type of work:

• Planning
• Requirements gathering and analysis
• Design and architecture
• Development
• Testing
• Customer reviews and acceptance
• Product release and deployment

The primary difference is that Waterfall treats these activities across singular projects as a linear-sequential and plan-driven process. The traditional model lengthens the overall lead time to deliver previously identified value, which often creates a host of problems in finding and fixing bugs. Late deliveries may effectively deliver what customers thought they wanted but not provide what they need at the delivery time. The organization must justify, fund, and initiate new projects before adding new enhancements and correcting defects (previously unidentified customer requirements) in the product, which usually pushes the new work out into the next fiscal year. By then, it is too late.

In contrast, Agile treats SDLC activities as a cyclical process that does not stop until the ROI for continued development no longer supports the cost of adding new value. Agile-based practices release new value incrementally across multiple iterative development cycles as a frequent and repetitive pattern. Short delivery cycles keep the code small between testing, making bugs and defects easier to find and resolve. Frequent customer reviews and team retrospectives help ensure the team stays continuously focused on their customers' current needs, priorities, and requests for improvements.

Though the Agile Manifesto speaks to CD concepts, it does not promote an integration or automation strategy. Those ideas came later. Instead, the Agile Manifesto speaks about improving collaborations and communications across the development function. DevOps started as a strategy to improve collaborations and communications between development- and operations-oriented teams. In its current form, DevOps promotes IT agility through collaboration, integration, and automation across IT to rapidly deliver customer value, higher quality, and less stress.

Automating value across IT

DevOps extends the Agile model in two important ways. First, DevOps extends beyond the traditional SDLC processes to link the activities and people within IT operations. Second, DevOps evolved in lockstep with CI and automation capabilities, which further accelerated the ideation-to-value-delivery lead time while simultaneously improving the quality of delivery.

Business process improvement (BPI) and BPR specialists know that it doesn't make sense to automate a critical business process until after analyzing and implementing the desired process improvements. Ideally, the organization takes a lean approach to map their current as-is and desired to-be value streams to determine what the new process needs to look like and then executes the work to make the desired transformations.

An adage is that automating a flawed process simply makes it put out a lousy result more quickly. In other words, if an organization is already not delivering value, automating the process produces the wrong result more efficiently and more rapidly. In other words, automating a flawed process only generates more waste more quickly.

So, before any IT organization attempts to integrate and automate its SDLC and operations activities, they first need to understand which issues they need to resolve. We'll look at these issues in the next section.

Collaborating across IT development and ops

Conceptually, DevOps began as a strategy simply to improve collaborations between IT development and operations teams. The collaborations helped development teams see the issues operations teams faced when deploying their products. Here are some example issues:

• Without proper collaboration, engineering and test environments may not adequately mimic production environments, causing a host of problems, such as the following:

  a. Production environment configuration instructions may be inadequate.

  b. Testing may not have the same applications installed as the production environments, making it difficult to see configuration, application programming interface (API), and integration conflicts.

  c. Performance testing in engineering and test environments may not adequately evaluate the loads and stresses encountered in production environments.

  d. Rollback and failover instructions developed in engineering and test environments may not work correctly in production environments.

• Development teams may not pay sufficient attention to security concerns in production environments.
• Operations teams lack a practical way to make their concerns known and to make their needs a priority within development teams.
• Operations, through their helpdesk and customer support functions, have the most direct knowledge of customer issues and desired enhancements.

In effect, IT development teams have both internal and external customers they must support. However, when development teams focus only on external customers, they are unaware of the significant technical debt accumulations that severely impact the operations teams.

Now that we've identified the communications and collaboration issues between development and operations, and the fact that development has two customers (internal and external), we can identify typical IT value streams. So, that is the topic of the next section.

Defining IT value chains and value streams

IT organizations are free to define IT value streams in any way they choose, so long as they identify their internal and external customers and take the time to organize and assess their activities to maximize customer-centric value. The VSM chapters provide detailed instructions on mapping as-is and to-be processes from the perspective of value and then monitor and analyze delivery performance against organizational improvement objectives.

On the other hand, an IT organization does not have to start from scratch—for example, the Open Group provides its IT4IT Reference Architecture (that is, IT for IT) as a standard reference architecture and value chain-based operating model for managing IT businesses. The Open Group subscribes to Michael Porter's definition of a value chain as a classification scheme for the complete set of primary and supporting activities that contribute to the life cycle of creating net value of a market offering. In the Open Group's vernacular, an IT organization is a value chain.

In this context, the Open Group defines a value stream, describing the critical activities for a discrete area within the IT value chain. The value stream activities create new net value units within the IT product or service as it progresses through its life cycle. In other words, each value stream activity within a sequence is value-adding. Otherwise, the activity shouldn't exist, or at least should not exist in its current form.

IT4IT defines four primary IT value streams, outlined as follows:

• Strategy to portfolio: Drive IT portfolio to business innovation.
• Requirement to deploy: Build what the business needs, when it needs it.
• Request to fulfill: Catalog, fulfill, and manage service usage.
• Detect to correct: Anticipate and resolve production issues.

Accelerating Agility

One of the Manifesto principles for Agile Development is that Agile processes promote sustainable development indefinitely and constantly. However, the practical reality is that those objectives are challenging to achieve. Customers always seem to have more immediate needs than the team can take on, and the team feels pressure from executives and marketing and sales staff to deliver everything at once and right now. Those pressures don't go away with Agile.

To be sure, development teams look like heroes when they incrementally deliver value that customers what, and when customers can see a timely result from their high priority requests. Still, the earlier sentence stands: "Customers always seem to have more immediate needs than the team can take on."

The integration and automation capabilities employed in a mature DevOps environment substantially accelerate the pace of delivery. In their book Accelerate: Building and Scaling High Performing Technology Organizations, the authors (Forsgren, Humble, and Kim, 2018) compare the metrics of high-performing IT development teams, using DevOps capabilities, to the metrics of the low-performing teams that did not. The results are stunning, as we can see here:

• 46 times more frequent code deployments
• 440 times faster lead time from committing code to deployment
• 170 times faster mean time to recovery (MTTR) from downtime
• Five times lower change failure rate (one-fifth as likely for a change to fail)

This book addresses the fundamental mechanisms of DevOps. Specifically, Chapter 5, Driving Business Value through a DevOps Pipeline, introduces the complexities and challenges of developing CI/CD and DevOps pipelines. Then, in Section 3, Installing DevOps Pipelines - To Compete in Our Digital Economy, of this book, we'll dive into four strategies to develop your DevOps pipelines.

We have now completed our discussions on accelerating Agility and are now going to move on to understand why and how VSM and DevOps are complementary practices.

So far, you have learned that Agile's values and principles, Lean production practices, and the collaboration, integration, and automation capabilities of VSM and DevOps all support an organization's primary objective: to deliver customer-centric value. As a Lean-Agile practitioner, your job is to help blend these concepts and capabilities into a seamless way of working.

Industry research confirms that Agile and Lean-Agile practices are now mainstream. For example, Digital.ai's 14th Annual State of Agile report (2020) found that 75% of their IT respondents are practicing Scrum or a hybrid of Scrum as their preferred Agile-based framework and that 35% of the respondents use the Scaled Agile Framework® (SAFe®) as their scaling Lean-Agile based framework of choice. Those numbers are 5% up from the previous year.

In the meantime, the installation of DevOps capabilities is increasingly viewed as table stakes to participate in our global digital economy. The high performers' metrics demonstrate that those organizations that effectively master DevOps have a significant competitive advantage over those that do not.

In contrast, VSM is still an emergent practice that is quickly evolving and gaining acceptance across the IT industry. However, given the large-scale success of Lean production concepts across the manufacturing and service industries, the fundamental lean concepts behind VSM bolsters the point of view that suggests continued adoption and success in the IT industry. This prediction stands because IT value streams must align with and support the broader Lean enterprise's value streams.

In her blog titled How to Use Value Stream Mapping in DevOps at https://www.lucidchart.com/blog/, Lizz Corrigan makes the following observation:

"In a DevOps environment, VSM and lean methodologies are tailored to specific actions, such as moving work between teams to creating tangible deliverables and incident reports. DevOps VSM is a uniting visual representation of how IT and businesses build, deploy, and manage workflows. It should begin with the SDLC and move through quality assurance and release/operations."

In short, VSM provides the infrastructure to guide and monitor new requirements through the DevOps pipeline. By the end of this book, you should have a solid understanding of how to link these capabilities to marshal and accelerate value-oriented work across IT development and operations functions.

In this chapter, you've learned why the concept of value is critical when implementing Agile, Lean, VSM, and DevOps practices to get their full advantages. You've also learned that value is an expression of desired customer experiences and that an organization as a whole needs to work in lockstep to deliver those experiences.

Current IT methodologies often use the term Lean-Agile as their primary differentiator. However, both Lean and Agile are complementary concepts, and the amalgamation of both types of practices helps IT organizations deliver VA products rapidly, efficiently, and with higher quality.

You've also learned that VSM instantiates Lean practices across IT by integrating and automating value stream identification, mapping, analysis, measurements, and monitoring capabilities to support E2E product life cycle delivery of value. Finally, DevOps helps accelerate the delivery of value.

Later chapters in Section 1, Focusing IT on the Delivery of Value, of this book provide instruction on using value stream mapping to assess current and desired future state changes to improve your value streams. Then, you will learn how to use VSM capabilities to support, analyze, and monitor your value stream improvement activities. Finally, you will learn why DevOps is a critical enabler to rapidly, efficiently, and cost-effectively implement digital applications supporting your value stream improvements.

Before we get to those chapters, we need to explore how organizations link Agile, Lean, and Systems Thinking practices as an integrated set of practices. That is the topic of the next chapter.

1. The term digital economy originally described an e-commerce view to the application of IT. In a modern context, which other elements form our digital economy?
2. Why is the issue of semantics so crucial in information sciences?
3. What is a value proposition?
4. Who has responsibility for delivering an organization's value proposition?
5. Why is it important to pay attention to value?
6. What is a definition of value streams?
7. What is the difference between focusing on features and functions versus having a focus on value streams?
8. In a modern IT context, what is the purpose of VSM?
9. In the IT4IT Reference Architecture, what are the four IT-related value streams within the IT value chain?
10. Which two roles does the implementation of DevOps capabilities play in a modern IT organization?

• Krafcik, J. (1988). Triumph of the Lean Production System. Massachusetts Institute of Technology (MIT). Sloan Management Review. Vol 30, Number 1. https://www.lean.org/downloads/MITSloan.pdf. Accessed November 16, 2020
• Womack, James P., Jones, Daniel T. (1996, 2013). Lean Thinking: Banish Waste And Create Wealth In Your Corporation, Simon and Schuster, ISBN 9781471111006.
• Womack, James P., Jones, Daniel T., Roos, Daniel (1990). Machine that Changed the World. New York: Rawson Associates, ISBN 9780892563500.
• Poppendieck, Mary, Poppendieck, Tom (2003). Lean Software Development: An Agile Toolkit. Addison Wesley, Boston, MA. ISBN 0-321-15078-3.
• Rupp, Cecil G. (2020). Scaling Scrum Across The Modern Enterprise. Implement Scrum and Lean-Agile techniques across complex products, portfolios, and programs in large organizations. Packt Publishing. Birmingham, UK.
• Liker, Jeffrey K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill. ISBN 978-0-07-139231-0.
• Rother, M., Shook, J., (1999). Learning To See: Value Stream Mapping to Create Value and Eliminate Muda, Brookline, Massachusetts: Lean Enterprise Institute.
• Martin, K., Osterling, M. (2014). Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation. McGraw-Hill. New York, NY.
• Tapping, D., Luyster, T., Shuker, T. (2002). Value Stream Management: Eight Steps to Planning, Mapping, and Sustaining Lean Improvements. (Create a Complete System for Lean Transformation!) 1st edition, Productivity Press, New York, NY.
• Tapping, D., Luyster, T., Shuker, T. (2003). Value Stream Management for the Lean Office. Productivity Press, New York, NY.
• Hines, P., Lamming, R., Jones, D., Cousins, P., Rich, N. (2000). Value Stream Management. Strategy and Excellence in the Supply Chain. Pearson Education Limited. London, England.
• Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: Building and Scaling High Performing Technology Organizations. IT Revolution. Portland, OR.