You are here

You are here

The age of the value stream: What your software team needs to know

Carmen DeArdo Senior Value Stream Management Strategist, Tasktop Technologies

Agile and DevOps have defined the last two decades in software delivery. Value stream management (VSM) will define the next one.

Even as recently as 2000, there was little information about agile and few 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 20 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. Here's why, and what your software team needs to know.

DevOps is part of a bigger picture

Agile sped up development to accelerate value delivery, while DevOps removed the bottlenecks 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 they are insufficient to remain competitive, given the breakneck speed of tech developments.

You must consider the end-to-end flow of all the software delivery work that creates and protects business value. After all, most organizations spend half their time and half the budgeted money 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.

What VSM helps you do

VSM in software delivery is a progressively maturing practice that takes a systematic approach to measure and improving end-to-end flow. It helps 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, Mik Kersten helps technology leaders articulate that by defining four flow items that someone is willing to exchange for an economic unit.

This data is abstracted from complex software delivery tool chains that enterprises use to manage the complex flow of work. Flow items deliver:


  • Features: New business value

  • Fewer defects: Quality

  • Risk management: Security, governance, compliance

  • Technical debt reduction: Removals of impediments to 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, vice president of cloud architecture strategy at 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 rise 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 you understand your current state.

They allow 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 members of the leadership team, who are often balancing resources and budgets across a portfolio. Where will those budgets produce the highest ROI in terms of improved flow?

Here are a few metrics that will help you measure this:

  • Flow velocity gauges whether value delivery is accelerating. It is the number of flow items of each type completed over a particular period of time, allowing you to measure throughput.
  • Flow time can identify when time-to-value is getting longer. It measures the time it takes for flow items to go from "work start" to "work complete," including both active and wait times. This allows you to measure time-to-market, to ensure your throughput 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. It is the ratio of active time versus wait time out of the total flow time.
  • Flow load monitors over- and under-utilization of value streams, which can lead to reduced productivity. It measures the number of flow items currently in progress (active or waiting) within a particular value stream.

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.

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—for instance, via a commitment to a plan item or objective. It does not stop until running software has been delivered.

As such, these measurements avoid the pitfalls associated with measuring just the cycle time of development or the time from code commit to code deploy, which can be an order of magnitude shorter than the bottlenecks upstream of development.

Using these value stream metrics, we can glean insights to create a culture based on data-driven continuous improvement.

Reach the summit of data-driven continuous improvement

Many teams appear mature in their use of agile and DevOps practices but are not mature when it comes to the cultural side of implementing continuous improvement.

First, how are your 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 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 ability to look at these problems differently. You need to create a continuous feedback loop between IT and the business, to supercharge market response and adaptability to compete with the giants of the digital age.

Keep learning

Read more articles about: Enterprise ITDigital Transformation