Development Value Streams

The aim of development is, in fact, the creation of profitable operational value streams.

– Allen Ward, Lean Product and Process Development [1]

Definition: A Development Value Stream is the sequence of activities needed to convert a business hypothesis into a digitally-enabled solution that delivers customer value.

What is a development value stream?

As described in Principle #10, “Organizing around value,” the value stream concept is essential to Lean thinking and SAFe. Two types of value streams are described in SAFe.

• Development value streams (DVS). This article describes DVS and the sequence of activities to develop and support the products and solutions used by operational value streams (OVS). Each DVS comprises one or more Agile Release Trains (ARTs).
• Operational value streams (OVS) describe the activities that deliver a product or service to a customer. Examples include fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a service.

Software developers, product managers, engineers, scientists, and IT practitioners, for example, work primarily in the DVS. The customers of the products and solutions they create may be either external or internal to the organization. Internal customers (or users) use systems built by the DVS to do the tasks required by their jobs.

Value streams contain all the activities, people, systems, information, and materials needed to deliver value. While OVS vary depending on their purpose, the DVS steps are fairly standard. Figure 1 illustrates the simplified structure of a DVS.

• Trigger – a new feature request triggers the value stream, though many new requests are moving through at the same time.
• Steps – these are the activities needed to define, build, validate, and release new value.
• Bar – the bar between steps shows information and materials flowing from one process to the next. It also implies the typical information handoffs as people in different steps add value to the flow.
• Ellipses (…) – these show delays between steps, typically contributing to long lead times. Decreasing delays is usually the fastest and most efficient way to reduce lead time.

The output of the DVS is a new increment of the product or solution, which is the added value of the new features released.

Why organize people into development value streams?

Organizing people around the DVS improves workflow and efficiency, accelerating time to market. This optimizes the flow of value to the customer across departments through suppliers, channels, and the whole system.

Value streams offer many benefits, as they:

• Enable long-lived, stable teams that focus on delivering value
• Help identify and visualize all the work necessary to produce solutions
• Reveal delays, bottlenecks, and handoffs
• Support smaller batches of work
• Enable knowledge growth and more continuous learning
• Allow the funding model to shift to value streams from traditional project budgets

How is a value stream measured to improve its flow?

Once identified, each value stream provides a measurable flow of value. This means value stream mapping [2,4] can be applied to measure and improve delivery times.

Figure 2 illustrates the value stream map of a typical feature as it moves from definition to production.

The flow metrics for the value stream offer strong evidence that substantial improvement is required. Only 5% of the flow time is value-added work time. The other 95% is spent waiting! Also, there is turbulence in the system. Only 35% of features flow through without having to be reworked at one or more steps, as represented by the % complete and accurate.

What is the relationship between development and operational value streams?

As Ward notes, [1] the purpose of development value streams is to make operational value streams—and the whole company—more profitable and efficient in delivering value. There are four common types of OVS: fulfillment, manufacturing, software products, and support. Each of these often leads to repeatable patterns for the DVS that support it. These are shared as examples below.

1. Fulfillment DVS pattern

The first pattern (Figure 3) is a consumer loan example. Patterns like this are common in insurance, banking, financial services, and related industries that offer complex, digitally-enabled products and services to consumers (B2C) and businesses (B2B).

A fulfillment OVS represents the steps to process a customer request, deliver a digitally-enabled product or service and receive payment. Examples include providing a consumer with an insurance product or fulfilling an eCommerce sales order (Figure 3).

In this case, the product is more virtual than tangible. The ‘loan product’ is a set of commitments, interfaces, applications, services, contracts, licenses, and other relationships that constitute the consumer product or service.

The customer interacts at points throughout their journey. Although customer access points are needed, they’re only the tip of the development iceberg. Most of the development happens in internal business systems, like those depicted in the commercial banking system.

Multiple development streams may be required to build and maintain these systems. For example, one development value stream supports the front-end loan origination services and credit scoring, while another builds the core banking services.

2. Manufacturing DVS pattern

Figure 4 shows a way to create a cyber-physical system. The passenger vehicle pattern highlights differences between the processes used to develop digital solutions and those for products that must be made so the customer can use them.

In this case, the delivered value is not the product but the specifications needed to manufacture and validate it. The focus is on the solution intent, the repository of design specifications, manufacturing procedures, the bills of materials, and so on.

In this context, the teams serve two types of customers: 1. The ultimate customer is the end-user of the manufactured product (the driver of the vehicle in this case). 2. The manufacturing personnel who use the specifications to build the product (illustrated with the blue ‘shop foreman’ icon).

Of course, the size and number of the DVS vary depending on the complexity of the solution. In some cases, thousands of people are designing the system (vehicles, aircraft, satellites, smartphones, for example). However, many manufactured products can also be developed using a single development value stream (drone, webcam, remote control, and so on).

The more complex case pictured above illustrates another common pattern in which some DVS directly support others. In this example, one DVS is devoted to building vehicle designers’ tools, which another DVS needs to design, simulate, and validate their products. Also pictured is a ‘digital twin,’ a replica of the product used to validate design assumptions. This twin is a common Lean-Agile strategy for building significant cyber-physical systems.

3. Software Products DVS pattern

Many software development and IT practitioners work in the Independent Software Vendor (ISV) industry, where vendors produce and market software products. This product segment includes the largest digital-native organizations and hundreds of thousands of companies that sell everything from IT services to hospital information systems, desktop software, gaming, and simple mobile apps.

Figure 5 illustrates a pattern for a significant organization that develops and supports a substantial software application.

This illustration shows that most of the development effort goes directly into the software solution. The customers (and various customer personas) are users of the system. Hundreds or even thousands of people may be directly involved in developing, deploying, and maintaining such systems.

But the system doesn’t sell itself, answer support calls, or collect revenue. The OVS is responsible for customer acquisition, internal operations, support, and more. As pictured, some software and IT practitioners support and maintain those internal systems. It’s also important to note that customers interact with the company throughout their buyer journey while using the application. As illustrated here, a DVS is devoted to supporting that functionality. It could be distributed to the other development ARTs for a more stream-aligned end-to-end approach. However, a common approach to the customer experience may warrant a separate development value stream.

4. Supporting DVS pattern

These are the internal and critical functions, as well as the people and processes that keep the company running. Common examples include the annual audit process, hiring and onboarding personnel, and many other significant, repeating workflows. Additionally, businesses engaged in logistics, supply chain, research, data mining, drug discovery, and so on have extensive and critical internal supporting value streams. Often, their activities happen earlier than those aimed at the end customer. Many of these supporting value streams create substantial demand for development.

Often, the DVS that builds, configures, and supports the systems the OVS needs to function can support multiple OVS.

Figure 6 illustrates an example of a single DVS that supports an ERP system used throughout the organization.

In this example, there is only an internal customer because this DVS supports an OVS internally. The customers for the DVS are the users, stakeholders, and employees who work in the OVS (indicated by the circled people icon).

Understanding this internal flow of value is as critical as understanding the external customer. The mindset, methods, and practices of customer centricity and design thinking apply equally to the teams on this DVS.

The four OVS patterns described earlier help define the DVS structure for optimal value delivery. Once initially identified, additional analysis is required to determine the DVS boundaries, people, solutions, and other deliverables. Figure 7 provides a Development Value Stream Canvas, a simple template that can capture and refine the emerging understanding.

---

References

[1] Ward, Allen C., and Durward K. Sobek II. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[2] Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.

[3] Thanks to SAFe Fellow Mark Richards for contributing to the Value Stream Canvas concept.