Key Takeaways from Continuous Discussions (#c9d9) Episode 63 – Value Stream Mapping and DevOps

Written by: Electric Bee
1 min read
Stay connected

In a recent Continuous Discussions (#c9d9) video podcast expert panelists discussed Value Stream mapping and DevOps. Our expert panel included: Andi Mann , Chief Technology Advocate at Splunk; Marc Priolo , Configuration Manager, Urban Science; Mark Dalton , CEO at AutoDeploy; and, our very own Anders Wallgren and Sam Fell . During the episode, the panelists discussed what is Value Stream Mapping and how it relates to DevOps, best practices for Value Stream Mapping, how it can help scale your DevOps adoption, and more. Continue reading for their best practices and insights.

What Is a Value Stream And Why Are People Using It?

Mann  emphasizes the importance of Value Stream Maps in complex environments: “I think Value Stream Maps are really important. Especially when you get complex environments and complex delivery mechanisms. Seeing where value is being added in the delivery pipeline is really important to understand how fast you're going, how much value you're adding, whether you're doing the right things at the right time, whether you're finding gaps in the process, etc. I find that when I work with customers who are in the early stages of a transformation to Continuous, to DevOps, to whatever it is, that doing that baseline mapping exercise up front gives them a starting point. I think it's really valuable.”

Dalton discusses the differences between complexity and complicated: “There's a difference between complexity and something that is complicated. With Value Stream Mapping, what we found is that it really unravels that notion of complexity versus what's complicated. It's able to put those things into very clear delineated buckets where people understand the traditional model of eliminate waste. What we're seeing is people can think about things in new ways to find new areas where we can create value.”

Make sure that what you are doing adds value, explains Wallgren : “If we could shift the source code to customers and deliver value that way, that would be awesome but we have to compile it, and link it, and all kinds of other things. That's a dumb example of what is part of the Value Stream but that's what you have to think about. Every time you do something to the Value Stream it better be something that moves it further to the customer or adds value. If it just takes time and doesn't add value, stop doing it.”

Priolo gives his insight into the advantage of Value Streams: “I think the real advantage of Value Stream Mapping is it allows you to look at your legacy processes and identify what is really needed to be done versus, ‘We've always done it that way so let's just continue doing it that way.’”

DevOps and Value Stream Mapping: What, Who, Why, How?

Value Streams provide useful frameworks, suggests Wallgren : “When you focus on things like Value Stream Mapping it gives you a framework around which to make decisions and measurements and judgments about what to do and what not to do. If you do it right, it becomes a little bit more objective rather than subjective. If you find the right measurements it can become very objective and I think that's always valued.”

Be flexible in your processes, advises Dalton : “First of all, I think you need to have processes that are really flexible. Some customers have this mapped out very well and it's just plug it in with the software and let it go. Other customers need that little bit of help in terms of thinking about documenting their processes and putting all of these things together. But, what it really does is it helps people understand the entire process and who's involved at every step, why they're involved, why it's important that their involved. So you create a broad document that everyone can work off of and then from that document we then actually create personas of people that are involved.”

You will never full perfect your Value Stream, it’s a continuous improvement project, says Priolo : “Value Stream Mapping is and evolutionary process. You're never going to get it perfect the first time. For me, that's a lesson that took me many a years to learn: you're never going to get perfection. All you're going to do is get good enough, which for me, means that's not Version 1. After that you're going to keep revising it. In almost pretty much any industry, you can't settle with what you have. You have to keep on evolving, you have to keep on adjusting it, and you have to keep on moving. Sometimes you even have to destroy and rebuild it. When we do the Value Stream Mapping and it's good enough to get you going, we start using it, we get the feedback and then we tweak it.”

If Value Stream Mapping is done right, it can have a positive effect on your culture, according to Mann : “Why do people go for Continuous Delivery? Why do people go for DevOps? The big reason I hear is cycle time. The time it takes me to get from an idea to a customer. If I'm putting some software in front of the customer, in front of an end user internally as well, this cycle time is such an important metric. Measurement is one of the core foundations of DevOps. Our friends John Willis and Damon Edwards talk about CAMS (the Culture Automation Measurement and Sharing). Well, the Value Stream Map is the measurement stuff and if you do it right, it's the sharing stuff as well. And if you do that right then you start to change culture as well.”

Fell stresses the importance of data and metrics: “If you can take a data-driven approach to it and say, ‘I know what segment of the product needs to be tested because that's all that was changed,’ you can then actually optimize that and that's where the idea of having pipeline engineers or release engineers comes in. The engineering aspect of it is to be able to treat your pipeline like a product, where the idea is you just start with an MVP and then you incrementally improve it and make it better based on data that you're pulling in from whatever tools you have or from information you're getting from your colleagues or your end users. Using that to incrementally improve that overall process, that's an extremely powerful habit.”

Let humans do what they do best, and automate the rest, advises Priolo : “I'm pro-human in letting humans be productive, letting them do what humans excel at. Doing redundant things is not a good use of human time. Humans are much more valuable than that and the whole thing about the Value Stream Mapping is identifying that. How much time we're wasting our human resources on doing things when we can have it offset by some kind of automation.”

Communication is key to a successful Value Stream, states Dalton : “Sure, you have that box and you're having data-driven decisions, but you have to have communication processes in place - whether they are built into the software or whether they are a part of you processes. That's something that we really strongly advocate for all of our customers. Absolutely at every stop of the process make sure that you have communication process stuff going on.”

More on the importance of metrics from Wallgren : “Just because there's a box on the screen that says, ‘We add value here’ doesn’t mean you are. Are you actually adding the value? How do you measure that? If we're spending an hour on something, are we actually getting the value out of that or do we need to spend two hours on it? Or do we need to run it on this many machines to actually prove that it works? But I think oftentimes, you have to be careful not to just stop when you put the box into the software pipeline and say, ‘We do this. We add value here.’ How do you know you're adding the value there? How do you measure that? How do you know? Those kinds of things are pretty important, too.”

Mann reminds us to not base our decisions on feeling: “I'm really big at the moment on data-driven decisions. Especially in the software delivery industry there's a lot of, ‘Oh, I feel that's okay. I think we're alright to release. We've probably done enough testing.’ There's a whole lot of these value judgments and if we can take that away we get to a point of repeatability and we get to where we're continually doing the right things, doing them faster and better because we're using data to make those decisions.”

Value Stream Mapping: How to Do It?

Documenting your processes is a key to success, explains Dalton : “We've seen customers with literally 35 environments that they want to deploy to every two hours. That's maybe not a realistic goal that you should be shooting for, so we try to rationalize that. I want to stress the importance of documenting current processes. Documenting current processes is so critical in terms of advancing the conversation. Back to what Marc was saying earlier about Version 1 as you're starting point. Once you get to that point, things may change and if you need to make changes then you have this flexible profit that you're operating off of. That's how we dimensioned it from a software standpoint. It's an end-to-end process that we've delivered to our customers because we don't want to just hand them code and say, ‘Here you go. Install it. Good luck.’”

Wallgren on the importance of automation: “I say this all the time, ‘Automation is auditing.’ Automation requires you to model something in the real world inside of a system, and requires you to have some fundamental understanding of the process. It may well be that in the process of automating your crappy process you make it better as part of that translation just by itself. Or, at least you now have an artifact and you can start to poke around and make better and edit as opposed to create from scratch and I think that's, you know, that's really important.”

Mann speaks further on the value of numbers: “One of the things I'm doing with Splunk is using the input from multiple systems in the development lifecycle to get the data on exactly how long it takes. Get inputs from your planning system, from the code repository, who's checking in, who's checking out, from testing tools, and from the release automation systems as well. To understand from a data-driven perspective, collect that data automatically, correlate it by release, by team, by application, by location depending on where your Value Stream is, where you want to focus. Then you've got this data-driven value map of what's taking how long and you can keep running that for days, for weeks, for months. You can see these numbers trend down or if you're doing it wrong, trend up.”

Priolo advises to ask what it really means to add value: “It's usually not that the team wants to be more efficient, it’s something that they're dealing with that they want to be more efficient at, like a deployment model. They want that deployment model to be more efficient which is where the conversation starts. Once they say, ‘We need to go faster,’ then you ask, ‘What does it mean to be faster?’ Then you start doing the Value Stream and figure out what points in there are candidates for optimization, for being replaced with an automated fashion. This is really where the Value Stream kicks in. Anytime you have a human point, it might not be that it takes the human long to do it, it just takes long for the human to be in a position to do it.”

Scaling DevOps with Value Stream Mapping

Mann reminds us that Value Streams came from big manufacturing: “I think it's clear that Value Stream Mapping scales because it came from some of the biggest organizations in the world - it came from big manufacturers. It clearly scales conceptually. In the manufacturing plants, they would have one pipeline, one production line at a time. The modern software development world is not like that as we know. Certainly, this is where potentially your manual models and sticky notes on a whiteboard sort of fall down because you don't have multiple dimensions to work on. You have to work in this 2D space and in large organizations scaling that sort of thing is not two dimensional, it's like infinite dimensional geometry.”

Priolo empathizes the importance of working with one or minimal Value Streams to have everyone working towards the same goal: “When teams work independent of each other they feel that their processes are unique and that nobody else does it the same way. Then what happens is when we go along this process it's like either I can create one model that everybody uses or I can create a few hundred models which I have to maintain myself. Out of selfishness, I decide to go with the one model approach. And the nice thing about it is you really do find going through the one model approach that a lot of teams’ uniqueness are negligible or can be consumed with slight variances to the overall model. There's not going to be 100 one Value Stream that's going to be used across the board, but at the same time, I got it down to three or four Value Streams that could be used in almost every type of scenario. That's much better than creating hundreds of Value Streams one unique for each one of our team's.”

Value comes from creating new opportunities, says Dalton : “We've been able to roll out for a wholesale distributor a process for the entire North American installation, which then they map. We did it all, installed our software, and did all the Value Stream Mapping. They then went and rolled it out globally. It comes down to delivering on outcomes - cycle time has improved, waste has reduced. That's all really important, but how are you adding new value? For us it was moving it over into different geographic regions. So, it's about creating these new opportunities for value for organizations.”

Some final words from Wallgren : “I think our processes as humans have a lot more in common than there are differences. There's value in recognizing that, and at the same time allowing for the important variances to be sustained going forward. Kumbaya.”  

Watch the full episode:

Want more Continuous Discussions (#c9d9)?

We hold our #c9d9 podcast every other Tuesday at 10 a.m. PST. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.

All Blog Articles

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.

Related Content

Advanced Deployment Strategies with Argo Rollouts

Blog
6 min read

YAML Declarative DSL Preview for CD/RO

Blog
6 min read

What Is Continuous Deployment? A Complete Explanation

Blog
6 min read

YAML Tutorial: Everything You Need to Get Started in Minutes

Blog
8 min read

Let's Get Back to Coding! 5 Approaches to Solving Pipeline Bottlenecks

Blog
12 min read

Integrating DevOps value into business goals

Blog
3 min read
Capabilities
Resources
Why CloudBees
© 2023 CloudBees, Inc., CloudBees® and the Infinity logo® are registered trademarks of CloudBees, Inc. in the United States and may be registered in other countries. Other products or brand names may be trademarks or registered trademarks of CloudBees, Inc. or their respective holders.
Privacy PolicyTerms of ServiceCloudBees Vulnerability Reporting