Helen Beal, DevOps and Ways of Working coach, Chief Ambassador at DevOps Institute and an ambassador for the Continuous Delivery Foundation, jumped right into discussing value stream management (VSM) and flow metrics. Value stream management overall provides metrics around how we get from having an idea to having a product in the customer’s hands—and beyond. It helps visualize the tools, processes, and people involved through the whole lifecycle of the product.
Value Stream Metrics and Flow Metrics
Let’s start by looking at what the research says.
If you look at a Gartner white paper from October 2020, you’ll see that organizations must focus on value streams to maximize flow and drive innovation.
Another report in August talked again about value stream metrics. When looking at value stream metrics, you can see a series of practices or a platform to support the practices. We can break this down into strengths and weaknesses.
On the strengths side, the DevOps tool chain improves end-to-end visibility and enhances data-driven conversations. Why is this important? It’s because we want to move away from opinions when building our products and features and instead move to evidence-based decisions. We also want to focus on improvements and collaborative ownership. Ownership has cultural implications around blamelessness and embracing failure.
Value stream management gives us data so that you as a team can make decisions together.
As for weaknesses in value stream management, at the current time, we lack metric standardization and guidance. We also have little integration and great potential for misuse.
Let’s look a little closer at the potential for misuse.
As we know, in DevOps we want to get away from “command and control” and move to autonomous teams. But for organizations that are not yet enlightened, there’s the potential for misuse as they try to stick with command and control.
For example, teams can start gathering DORA metrics. These metrics include deployment frequency (DF), mean lead time for changes (MLT), mean time to recover (MTTR) and change failure rate (CFR). These useful metrics can be misused, and people can use these platforms to beat teams over the head instead of using the metrics to empower teams to own the improvement process.
In the State of Agile report, value stream management is described as a combination of people, processes, and technology.
This shows that people are interested in, planning, or implementing value stream management. That’s great.
The question is whether they’re using a vendor platform or if they’re using home-grown tools or Excel.
Another report from Research In Action emphasizes that VSM is a must-do, not a nice-to-do—the adoption is critical. And Forrester also reports the need for value stream management tools.
The reports supporting this go on, proving a fairly universal consensus.
DevOps Toolchains and Value Stream Management
Now let’s build a toolchain.
Some teams build toolchains organically. Some plan them out through architectural planning.
We can start with a repository like JFrog or Nexus, then move to version control. CI/CD tools allow teams to commit and deploy daily, where we need to use unit and integration testing to help ensure quality.
Next we want to add some security, as well as service desk tickets, logging, AI Ops, and feedback tools like Splunk or Grafana.
But why are there so many tools and vendors? For now, it is what it is. There’s a lot going on here. And we’re not done: we still need to add in our collaboration tools in our toolchain as well.
Overarching all of that, we need our value stream management tool so we can start measuring things like flow and find where you have constraints and delays. And at the DevOps Institute, they’ve been talking about DevOps dashboards.
For now, many tools screen scrape the existing value chain, but the future is integration across all the tools we use.
Now that we know what the toolchain looks like, how do we measure value?
We want to measure how fast we’re able to deliver outcomes to our customers. And value stream management can help us understand what those value outcomes really are, as well as what to do next.
Many value terms have entered this space.
This covers the business, customer, and organization. For example, you’ll find many terms for our product teams: feature teams, value stream teams, and more.
So imagine you’re on a team with a big customer focus. You can talk about different types of value, but this team will focus on business and customer value.
From the business side, you can look at profit, revenue, and net promoter scores. The interesting thing here is that leadership can start to look at the team’s P&L and operations. These values don’t matter as much to every company. For example, basket size matters to some retailers more than others.
With net promoter scores (NPS), you’ll know how often your customers will recommend your service. And though it’s an interesting metric, it doesn’t have a direct impact on the bottom line and has been treated with skepticism by some. It’s a good indicator, but it doesn’t always tie to more business. Alternatively, referrals are a direct link to the P&L
Let’s move to the customer side, figuring out ways to measure and improve on their satisfaction.
First, you can get direct feedback. Getting feedback has been growing in popularity, and teams are using this extensively. If you get feedback from your customer, you’ll have answers to questions like, “What features do you like?” and, “What do you think of the product?”
And then you can move to the customer experience and start using value stream management to determine the customer journey time. Again we’re moving towards data-based decisions.
Value stream mapping helps tie this all together and lets you visualize the whole value stream. It assists in seeing the entire flow of how you get value to your customers.
Closing Out With the Value Cycle
Finally, let’s consider the value cycle. We should be using metrics across the value chain. From the ideas, user stories, code artifacts, and more, we can look at how the value stream can be improved and how you can improve on your DevOps practices.
This session was summarized by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.