If Agile and DevOps defined the last two decades in software delivery, value stream management (VSM) will surely define this one. At the turn of this century, you would find little information on Agile or jobs calling for expertise in that area. Ten years ago, the same was true for DevOps. Today a similar situation exists if you search for VSM. While many careers have been built around Agile and DevOps over the past twenty years, it has not been enough to help enterprises truly compete in the increasingly digital world. VSM is fundamentally different because it looks holistically from ideation to delivery and will deliver on the promises that Agile and DevOps could never fulfill.

DevOps is part of a bigger picture
Agile sped up development to accelerate value delivery, while DevOps removed the bottleneck between development and operations for further gains. Yet that’s only part of the value stream. 

Being good at CI/CD and code to cloud are necessary, but insufficient to remain competitive against the breakneck speeds of the tech oligopoly. We must consider the end-to-end flow of all the software delivery work that creates, and protects, business value — after all, for most organizations, half their time and half the money gets spent before a card ever gets to a development team’s backlog. That’s why VSM is vital: It doesn’t just focus on accelerating one silo, it focuses on accelerating the whole system.

VSM: The whole picture
VSM in software delivery is a progressively maturing practice that takes a systematic approach to measure and improving end-to-end flow to help organizations to:

  • Shorten time-to-market
  • Increase throughput
  • Improve product quality
  • Optimize for business outcomes, such as increased revenue and customer retention

Accelerating value work requires an understanding of what value is. In Project to Product, Dr. Mik Kersten helped technology leaders articulate that by defining four flow item types. This data is abstracted from complex software delivery toolchains that enterprises use to manage the complex flow of work: Features, Defects, Risks and Debts. Features deliver new business value, Defects are removed for quality, Risks are avoided through security, governance and compliance; and Debts are removed as to no longer impede future delivery.

An organization’s focus must be on prioritizing, optimizing, and balancing the flow of these items across your software portfolio. For that, you need the right type of measurement — as Adrian Cockcroft, VP of Cloud Architecture Strategy of Amazon Web Services puts it in Cloud For CEOs: “The most critical metric is how long it takes for an innovative idea to reach a customer. If it takes your company months, how can you compete with an organization that delivers in days?”

New practices require new measures
Unlike discipline metrics that focus on activities in a specific area of the value stream (such as DORA and DevOps), VSM requires end-to-end metrics that levitate above all practices and processes to focus on the flow of business value. 

These metrics need to measure the rate of business value delivery for software products through the lens of your customers (whether internal or external) to help enable you to understand your current state. They enable you to determine where work is flowing, and more importantly, where it isn’t. They provide shared visibility into business and development metrics for everyone involved in the value stream. That includes leadership, who are often balancing resources and budgets across a portfolio. Where will those budgets produce the highest ROI in terms of improved flow?

  • Flow Velocity gauges whether value delivery is accelerating. Flow Velocity is the number of Flow Items of each type completed over a particular period of time. This allows us to measure throughput.
  • Flow Time can identify when Time to Value is getting longer. Flow Time measures the time it takes for Flow Items to go from ‘work start’ to ‘work complete’, including both active and wait times. This allows us to measure time-to-market for the throughput that we are after to ensure that it is fast enough for the short feedback cycles needed when dealing with uncertainty. 
  • Flow Efficiency can identify when waste is increasing or decreasing in your processes. Flow Efficiency is the ratio of active time vs. wait time out of the total Flow Time.
  • Flow Load monitors over and under-utilization of value streams, which can lead to reduced productivity. Flow Load measures the number of Flow Items currently in progress (active or waiting) within a particular value stream.

Each of these is based on end-to-end flow through a value stream. For example, the Flow Time clock starts when work is started, (e.g. via a commitment to a plan item or objective). It does not stop until running software has been delivered. As such, these avoid the pitfalls associated with measuring just the cycle time of development, or code-commit to code-deploy time, which can be an order of magnitude shorter than the bottlenecks upstream of development. Flow Time provides a customer and business-centric measure of time to market, and Flow Velocity does the same for throughput. Flow Efficiency measures how effective investment turns into value, and Flow Load is an early warning indicator of overloaded value streams declining due to too much work-in-progress (WIP). Using these value stream metrics, we can glean insights to create a culture based on data-driven continuous improvement. 

Reaching the summit of data-driven continuous improvement
Many teams appear mature in the application of Agile and DevOps practices but are not very mature when it comes to the cultural side of implementing continuous improvement.

First, how are teams measuring maturity? Is the goal to do DevOps well? Are you measuring outcomes or are you simply measuring activities? The goal is not to implement all of the DevOps practices—it is to accelerate the delivery and protection of business value. Maybe you don’t need to put all DevOps practices into play. Maybe different teams need different practices. It’s a mistake to simply say, “We’re going to implement this practice or that one.” without having a measure of what it can provide from the perspective of the business. 

You’ve got to know what the business needs first—what is the problem?  What will unlock the flow of business value?  The Age of VSM is about measuring what matters in terms of business results. This provides the capability to look at these problems differently in order to create a continuous feedback loop between IT and the business to supercharge market response and adaptability to compete with giants of the digital age.