Value Streams Definition and Guide

The definition of the value stream easiest to relate to is the manufacturing value stream. The value stream represents the set of activities to be performed to deliver an item of value to the customer. The manufacturing value stream produces a physical product. The customer and market forces assign a monetary value to the product. Value exchange occurs when a customer exchanges cash for a product.

Manufacturing Value Stream

With physical products, the process for creating the product and the process for the exchange of value is visible and relatively straightforward. In a manufacturing value stream, the activities to create a product from raw materials or a set of parts to the manufactured product are linear and visible.

Although manufacturing value streams can get very sophisticated, the flow of work and the steps to get to the finished product are visible. The questions of what is the capacity of a production line, where are the bottlenecks and what to do about them are easier to grasp and understand.

The other reason the manufacturing value stream is more relatable is that product design and production are discrete and separate activities. The value exchange process is also relatively straightforward. The customer buys the product, and the business gets the money. Output and value for both the customer and business are correlated.

Software Delivery Value Stream

However, unlike the manufacturing value stream, the work to create the product and the product it delivers isn’t visible in the software delivery value stream.
In addition, software development, delivery and operations are not discrete sets of activities that happen in isolation; instead, they occur in close proximity, especially with agile & DevOps ways of working.

Illustration of software delivery value stream: Invisible workflow and product delivery flow Ref: VSM Guide – Value Stream Management Roles & Process | Tasktop

In the software delivery value stream, the work to create the product isn’t readily visible, nor are the different product development stages visible to the naked eye.

In the digital age, where software is continuously produced and consumed, how value is created and exchanged is different.

Figure: Escaping the build trap, How effective product management creates real value, Mellissa Perri

The value exchange is realized i.e. business realizes value when customers realize value. To elaborate, when a digital product or service solves the customers’ problems and fulfills their needs and wants.

The key takeaway from the above picture and from Mellissa Perri’s book title, “Escaping the build trap, How effective product management creates real value,” with digital products and services, is output. This means more features don’t equal more value for the business or customers. Only when a business’s digital products deliver the right outcomes is value realized.

For digital products and services, the software delivery and the way value is realized by the business. Meanwhile, the customer is based on an infinite feedback loop of development, delivery and operations, both technology operations and business operations, as illustrated below. Hence, business strategy is constantly refined and adapted based on customer feedback on the business’s digital products and services.

Figure: Escaping the build trap, How effective product management creates real value, Mellissa Perri, For digital products and services, value delivery and value exchange are conjoined.

Although the software delivery value streams can benefit from the work done to optimize the flow of value through manufacturing value streams, there are critical differences between them. The fundamental differences between the two value streams in how value is delivered and realized mean we can’t reuse the manufacturing value stream metrics for software value streams. Value stream management for software value streams (digital products value streams) requires a new set of metrics that cover both the business (value exchange) and technology (value delivery) portions of the value stream.

Therefore, building upon the existing metrics that measure value in software value streams is necessary. Team velocity is one of the earliest agile metrics. It uses team velocity as a proxy for value delivery. While useful, it represents only a fragment of the value stream. The DORA metrics (lead time for changes, deployment frequency, mean time to recover and change failure rate) cover the last mile of software delivery. They measure the ability of the IT function of an organization to get code and change delivered rapidly and safely into production and, by extension, into the hands of the customers.

Agile and DORA metrics are useful and provide valuable feedback for improving the IT function and the technology portion of the value stream. However, in the current digital age, where every business that operates at scale is a technology business, the need to measure the effectiveness of the end-to-end digital product value stream becomes critical. The gap between business and technology must be bridged through a common language, and businesses should be able to measure value in business terms and not just technical terms.
Flow metrics, proposed by Dr. Mik Kersten in the book “Project to Product, How to survive and thrive in the age of digital disruption with the flow framework.” provide a way of measuring the effectiveness of the end-to-end digital product value stream. They provide the vocabulary for a shared language between business and technology and the ability to measure the end-to-end digital product value stream – from intent to creating value to the exchange of value.

Due to the intangible nature of software and the complexity of software work, the flow of work and of value aren’t visible in a digital product value stream. The flow items in the table below define the four items of value and represent all the items of value (mutually exclusive and collectively exhaustive) that can flow through the digital product value stream.

Reference: Flow Items, Project to Product, Mik Kersten, How to survive and thrive in the age of digital disruption with the flow framework

Flow Framework

The Flow framework and the flow metrics provide a basis for measuring the effectiveness of digital product value streams in delivering the right outcomes so the business and the customer realize value. Here are the five flow metrics along with their description

• Flow distribution: The portion of each flow item – features, defects, risks and debts – within a value stream
• Flow Velocity: Number of flow items done in a given time
• Flow time: Elapsed time between entry of flow item into the value stream and its release and consumption
• Flow load: Number of flow items with a flow state of active or waiting (i.e., work in progress)
• Flow efficiency: The proportion of time flow items that are actively worked on to the total time elapsed

When combined with business planning tools (such as project and product portfolio management, Objectives and key results), these metrics can provide a common language spanning the business and technology portion of the digital products value stream. So, instead of business measuring value delivery in terms of projects completed on time, on budget and within scope, and Agile & DevOps teams measuring value delivery in terms of team velocity and release frequency, business and technology can build a common language based on flow metrics and drive the right customer and business outcomes with OKRs. A common language focused on delivering outcomes through digital product value streams is a powerful way of surviving and thriving in the age of digital disruption.

Topics Discussed in ELF

1. The uniqueness of software value streams and how to define and make the flow of value and exchange of value visible for digital products and services
2. The digital natives and the tech giants don’t have a separate language for business and technology portions of the value stream. A common language enables them to drive technology-powered business strategies to innovate and disrupt existing product categories and businesses. How can incumbents build such a common language?
3. Doing DevOps well required breaking down silos within IT and a massive cultural transformation. Breaking down silos between business and technology will require a similar, if not more extensive cultural transformation. What leaders and cultural transformation are needed for the next evolution of DevOps- BizDevOps?