Value Stream Thinking: The Next Level of DevOps

When people think about DevOps, they tend to go straight to automation—and that is part of it. But we need to think bigger. Rather than simply automating everything, we should be thinking about the value streams in our organizations. A team's automations, scale and ability to deliver are a waste if the result is features that are never used by customers. Asking simple questions about where value lies helps organizations visualize how they're doing, identify their specific challenges and understand what actions will actually move the needle.

DevOps is all about coordinating systems and improving flow. Unfortunately, a lot of people get stuck on the idea of DevOps as just the CI/CD pipeline and automation. This perspective leads us to miss places beyond coding and deployment where the value stream is clogged. We need to think of DevOps not as another silo but instead as a part of a larger stream of valuable activities. Value stream thinking allows us a broader view from which to craft better and more meaningful optimizations. 

A value stream is an easy way to look at a problem using different resolutions. Say we have a staging deployment bottleneck and our eight-member team gives us eight different reasons for its cause. The idea of the value stream helps us to zoom in and look at the steps at a finer level to determine where the real cause is within that bottleneck. A value stream map (AKA a current state map) that inspects the problem at different scales can draw out where waste is really occurring. This process of drawing the map together - with stakeholders across the organization - puts everyone on the same page, settling arguments before they occur by pushing leadership and development to share a common view.

With value stream mapping, teams can take a 12-month process down to three months, and three-month processes down to three weeks. By drawing the map, the teams identify where their big problems are.

Measurement doesn't have to be onerous; it depends on what and how you measure. I recommend you start simply with time. How long does it take to accomplish a step? How long does one resource have to wait on another?

For what to measure, we really want to look beyond CI/CD. I recommend using the DORA metrics: deployment frequency, mean lead time for changes, mean time to restore, and change failure rate. These four metrics tell us where in our process we need to pay attention. To these evidence-based metrics, value stream thinking adds a framework layer on top of the data to let us determine how to improve the opportunities the metrics unearthed. 

Let me present an example of how value stream thinking and measurement together can make a big impact: Say a client wanted to implement automated deployment and knew they had a bottleneck they needed to tackle. Before jumping in, we would map out their value stream and perhaps find not one but two bottlenecks, both of which were actually outside of automated deployment. We might find the real bottlenecks were in environment creation and acceptance testing, which took hours longer than the 15 minutes required for artifact deployment. By starting with a value stream map, we can save the client millions of dollars that would have been wasted “optimizing” for a problem that wasn’t there.

Value is a sticky, complex subject. Some say it measures effort, quality, cost or time, but there’s no agreement and likely never will be. Instead we should think in terms of what the customer finds valuable. Giving engineers an understanding of the value stream aligns goals and demonstrates how their work contributes to the bottom line. We want to make sure our finite resources are always put toward solutions that truly provide value

How do we figure out what’s truly valuable? It’s helpful to consider the end point: where are we aiming?  I like to start teams off with these questions: What is the value of each individual step or artifact in the value stream? And how are you adding value at each stage of that stream? These questions keep the team’s efforts aligned to the big question around outcome, but also highlight differentiation between - business, employee, and customer value.

Nothing in software is ever simple. As our systems become more sophisticated, their complexity also increases. Each process is its own small stream, with its own bottlenecks clogging up the flow. And each small stream has its own entry points and connection points with other streams in a larger "watershed.” 

Once you start using value stream thinking, you see applications of it everywhere. You start thinking about how a platform stream affects a web app stream, and how the web app stream affects your mobile app. All these smaller streams connect, so it’s so crucial to take time to visualize those interactions to see where a bottleneck for your platform team affects your other delivery teams, or how the approval process within your mobile app delays your marketing efforts. Figuring out how to make these issues visible is key to managing inherent complexity and maximizing the value you’re able to deliver.

If I had to pick just one message about using value streams in DevOps, it would be this: Start today, just where you are. Just look at what’s going on in your processes right now, because that's the easiest way to begin improving performance. Once you adopt this way of thinking, you'll see opportunities to reduce bottlenecks and enhance value everywhere.

For more examples on value stream thinking for every process in your organization, watch a related 30-minute episode of the Software Delivery Leadership Forum.