The aim of development is, in fact, the creation of profitable operational value streams.
—Allen Ward [1]
Development Value Streams
Development value streams (DVS) are the sequence of activities needed to convert a business hypothesis into a digitally-enabled Solution. Examples include designing a medical device or geophysical satellite, or developing and deploying a software application, SaaS system, or an e-commerce web site.As described in Principle #10, Organizing around value, the value stream concept is a critical underpinning of Lean thinking and fundamental to SAFe. There are two types of value streams described in SAFe. Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service. This article describes development value streams (DVS), the sequence of activities teams use to develop and support the products used by operational value streams.
Systems and software developers, product managers, engineers, scientists, and IT practitioners all work in development value streams. That is where they define, build, and deploy the Solutions their Customers consume. These customers may be internal — people who are part of an Operational Value Stream. Or they may be external customers who directly consume the products and services the enterprise sells and supports.
Details
Development Value streams are the primary organizational model in SAFe. A SAFe portfolio is comprised of them, each dedicated to building and supporting a set of solutions (Figure 1).
For many practitioners in IT and internal development, these solutions may be internal to the business itself; their users/customers are the people within the enterprise who use that system to do their jobs. Others work directly on the products, services, or systems that are delivered to the external customer. Depending on the enterprise’s scope and the configuration of the development streams, many development value streams do some of both.
Value streams also provide the funding mechanism in the SAFe enterprise. Lean Budgets support them and empower the workers who make the day-to-day decisions that optimize economic value. This value is measured, in part, by the Key Performance Indicators (KPIs), which are established to evaluate how the value stream is performing against its role in achieving Enterprise strategy.
Why Organize People in Value Streams?
The reason to organize around value streams is simple: They improve workflow and accelerate time to market. They accomplish this by optimizing the flow of value to the customer across divisions and functional 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
- Identify and visualize all the work necessary to produce solutions
- Identify delays, bottlenecks, and handoffs
- Support smaller batch sizes of work
- Enable knowledge growth and more continuous learning
Indeed, when you start to understand their worth, it makes one wonder how enterprises ever got along without them. Yes, they were always there, but we didn’t see them. [2]
Defining Development Value Streams
Value streams contain all the activities, people, systems, and the flow of information and material necessary to deliver value. While operational value streams vary significantly depending on their purpose, the development value stream steps are fairly standard. Figure 2 illustrates the simplified anatomy of a development value stream.
The elements are as follows:
- The lead time is the time interval needed to move a feature from the date of the request to how it works in the user’s environment.
- The value stream is ‘triggered’ by a new feature request, though in reality, many new feature requests are moving through the value stream at the same time.
- The ‘steps’ are the activities needed to define, build, validate, and release that value in the solution’s context.
- The ‘bar’ between steps indicates the flow and material moving from one step to the next. It also implies the typical “handoffs” of information that occur as people in different steps add value to the process. (This is the home of the notorious ‘batch size’ problem, which is addressed throughout SAFe.)
- The ellipses (…) indicate the delays between these steps, typically the largest contributors to long lead times. Thus, decreasing delays is usually the fastest and most efficient way to reduce lead time.
The result is a new increment of the solution, which now contains the additional value these new features provide.
This is obviously an incredibly simplified mental model of what it takes to create innovative technical solutions in today’s digital enterprise. Still, it serves an important purpose: it identifies and analyzes all the activities necessary to deliver solutions and the time it takes to do so. As such:
Understanding and continuously optimizing development value streams may be the most crucial activity in a Lean enterprise.
But this takes far more analysis than the simple figure above. Indeed, that is the entire purpose of the Continuous Delivery Pipeline (described later in this article), which every Agile Release Train (ART) uses to deliver small increments of value to their customers.
Aligning Development with Operational Value Streams
The operational value stream article describes how value streams deliver the solutions and support the customer’s need. Indeed, as Ward notes, [1] the entire purpose of development value streams is to make operational value streams — and, thereby, the whole enterprise — more profitable and more efficient in delivering value.
Operational value streams typically fall into one of four categories:
- Fulfillment of digitally enabled products and services
- Manufacturing
- Software products
- Supporting value streams
These operational value streams serve very different purposes. So, it stands to reason that the design and outputs of each development value stream are driven by the type of operational value stream it supports. While there is no obvious limit or constraint to ways an enterprise can configure development value streams, specific patterns have emerged. The following sections illustrate some patterns for each of the four operational value stream types, followed by explanatory text.
Fulfillment Value Stream Pattern for Digitally-Enabled Product or Services
The first pattern (Figure 3) revisits the consumer loan example from above. Patterns like this one are fairly common in insurance, banking, financial services, and related industries that offer complex, digitally-enabled products and services to consumers (B2C) and businesses (B2B).
In this case, the product is more virtual than tangible, as 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 various points throughout their journey. Although critical, customer access points are only the tip of the development iceberg; most of the development happens on internal enterprise-class systems, like those depicted for the commercial banking system.
To build and maintain these systems, multiple development streams may be required. In the example, one development value stream supports the front-end loan origination services and credit scoring; another builds the core banking services.
Manufacturing Value Stream Pattern
Figure 4 illustrates a pattern for manufacturing a significant cyber-physical system; in this case, a passenger vehicle. This pattern shows some fundamental differences between the types of development streams that directly support digital solutions and those that support products that must be manufactured before use.
In this case, the delivered value is not the product itself but rather the specifications needed to manufacture and validate it. The focus is on Solution Intent, the repository of design specifications, manufacturing procedures, bills of materials, etc., needed to produce the device.
In this context, 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 the number of development value streams vary with the complexity of the solution being built. In some instances, thousands of people are involved in designing such a system (vehicle, aircraft, satellite, smartphone, etc.). But it’s also the case that many manufactured products can be designed and developed by a single development value stream (drone, webcam, remote control, etc.).
The more complex case pictured above illustrates another common sub-pattern, in which some development value streams support other development value streams directly. In this example, one is devoted to building the tools that the vehicle designers need to design, simulate, and validate their product.
Also pictured is a ‘digital twin,’ a replica of the product used to validate design assumptions. This is a common Lean-Agile strategy for building significant cyber-physical systems. It isn’t always practical to create and test the hundreds of physical prototypes that would otherwise be necessary to support incremental development.
Software Product Value Stream Pattern
The third pattern supports the development of software products. For context, perhaps as many as one-third of all software development and IT practitioners work in the Independent Software Vendor (ISV) industry, where vendors directly produce and market software products. This segment includes the largest digital-native companies and hundreds of thousands of enterprises that sell everything from IT services to hospital information systems, desktop software, gaming, and simple mobile apps. This may be the fastest growing industry segment. And although most have agile DNA, they still must organize their efforts for maximum operating efficiencies.
Figure 5 illustrates a pattern for a significant enterprise that develops and supports a substantial software application.
This illustration shows how the largest focus of development effort goes directly into the software solution. The customers (and various customer personas) are obvious as the users of the system. Perhaps 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 its own revenue. That responsibility belongs to the operational value stream dedicated to customer acquisition, internal operations, support, and more. As pictured, some software and IT practitioners are dedicated to supporting and maintaining those internal systems.
It’s also important to note that customers interact with the company throughout their buyer’s journey while using the application. As illustrated here, a development stream is devoted to supporting that functionality. It could be distributed to the other development Agile Release Trains (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. (For more on this, see Lean UX-and the SAFe Program Increment Life-cycle advanced topic).
Supporting Value Stream Pattern
The final type of operational value stream pattern serves ‘supporting’ value streams, the internal and critical functions, and the people and processes that keep the enterprise running. Common examples include the annual audit process, onboarding and supporting personnel, and many other significant, repeating workflows. Additionally, enterprises engaged in industries such as logistics, supply chain, research, data mining, drug discovery, etc., have extensive and critical internal supporting value streams, with activities that occur far earlier than those aimed at the end customer. Many such supporting value streams exist, and they create substantial demand for development.
Multiple operational value streams can often be supported by a single development value stream that builds, configures, and supports the systems the operational value streams need to function and share common information.
Figure 6 illustrates an example of a single development value stream that supports an ERP system used throughout the enterprise.
Figure 6 also displays another aspect of this analysis. Unlike the other patterns shown, the external customer does not appear here. That’s because in this case, the development stream supports an operational value stream that is internal to the enterprise. The customers for the development value streams (indicated by the circled person icon in the figure) are the users, stakeholders, and employees who work on the operational value streams.
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 development value stream.
Defining Development Value Streams
The patterns above help identify how to organize development value streams for optimal value delivery in the larger enterprise. Once initially identified, some additional analysis is required to define the boundaries, people, solutions, and other deliverables of each. Figure 7 provides a development value stream canvas, a simple template that can capture and refine the emerging understanding.
Figure 7. Development value stream canvas [3]
Realizing Development Value Streams with Agile Release Trains
As implied throughout this article, developing enterprise-class software and systems is a complex undertaking. Indeed, it may be the determining factor for a company’s success or failure in an increasingly digital world.
Modeling the flow of value is one way to address this complexity. However, understanding value flow is just part of a means to end; the larger purpose is to improve its value flow.
This takes more than modeling; it takes real people with specific responsibilities doing the hard work of defining, implementing, and supporting such systems. That is the work of Agile Release Trains, teams of Agile Teams, working in cooperation with other stakeholders who work to deliver tangible products and services to their customers.
Optimizing Development Value Streams
Finally, there is another significant benefit to value stream analysis. Each value stream provides an identifiable and measurable flow of value to a customer. As such, ‘value stream mapping’ [2,4] can be applied to measure and improve delivery velocity and quality systematically.
As teams and ARTs begin their DevOps journey, this can be an eye-opening experience. Figure 8 illustrates an example for a team doing their first mapping of a typical feature as it moves from definition to production.
From the data above, it’s clear there is substantial room for improvement. Only 5% of the lead time was value-added activity time. The other 95% was spent waiting. Also, there was substantial rework, as indicated by only 35% of the features making it through the process without revisiting prior activities.
Results like these drive ARTs to further invest in value stream mapping and automation via a Continuous Delivery Pipeline, as shown in Figure 9.
That is the work that turns enterprise development value streams into dependable, Agile engines, delivering innovation and value to the market in the shortest sustainable lead-time.
Learn More
[1] Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2014. [2] Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda, 20th-anniversary edition. 1998-2018. Lean Enterprise Institute. [3] Thanks to SAFe Fellow Mark Richards for contributing the Value Stream Canvas concept. [4] Martin, Karen, and Mike Osterling. Value Stream Mapping. McGraw Hill, 2014.
Last update: 3 January 2023
