Why Value Trumps Flow When Managing Value Streams


Thank you for joining me here at my session with the VSM DevCon, and thanks to the SD Times for putting this on this year. I'm prepared to talk to you today about why I believe value trumps flow, when managing your value streams. Over the last few years I think we've spent most of our time really talking about the last mile of what I call value stream. That's automating code to operations and connecting your DevOps tool chain here. And I think we have eliminated, a lot of waste there, but we always seem to be focusing too much on flow there.

I think that's really good. But are customers really seeing the value of that? Do customers really see that you're moving so fast? And in that faster value stream DevOps flow are you really delivering more value to the customer? Or are you delivering such smaller sizes of things that it doesn't get to the customer that often? Or can your customers consume that value that often? So there's all kinds of questions that you have to ask when you start to automate your tool chain and look at things and do value stream optimization. So the question is, do customers see value from you being so efficient here or not? Or are you do delivering less value? So, I had some discussions about this.

I talked to some people in the industry that I know. And we talked a lot about a lot of different things. But what came up was I'm spending thousands of dollars on improving my devops flow, hundreds of thousands of dollars and sometimes millions, but I don't know if I'm delivering any more value to my customer. I still don't have the visibility that I need to see what we're delivering and see how far along I am with the initiatives I have. We're really great at building software, but I feel we're building the wrong software faster and we're not delivering value to the organization. And big theme I've gotten is not a lot of connection to business outcomes and making sure that I'm connecting and getting the outcomes I'm looking for with value stream management and DevOps tool chain. So that's why I still think that we need to look at this a little bit differently than just being all about flow.

Flow doesn't mean that you're going to deliver more or increase value to your customer. It just means you're going to be faster and I think we've made things really fast and we focus so much on flow that it may have been and could be to the expense of value. And value is a bunch of different things, but value to the customer is mostly what we're focused on. So I put a scenario together to frame up what I'm talking about, to get my point of view across. So, this is Carl here. He works for this bank.

Let's call it Big Bank, Big Bank had a goal of reducing time to market by 20%, and they went into a value stream initiative to improve flow. So, they were faster to market and so on. So they got a consultant, they went through the process. They did all of that. And, you know, what the outcome was, they totally achieved that 20% and actually got to 25% increase or decrease in cycle time to get to market quicker. They did a whole bunch of things but something started happening, people started complaining to Carl about how, you know, the user experience wasn't right and the customer target revenues didn't happen and a couple things just weren't going the right way. So what was going on is they were going really fast, but were they really getting anywhere in the market to their customers and delivering the things that were relevant and important to them. So we started working with them. We took a look at it.

We put some metrics in place. And one of the things we notice right away with flow distribution across their value stream is they've been introducing a lot of rework. A lot of defects are coming back. A lot of bugs are getting fixed. There's a lot support things that are getting into their development flow. So we peel back the onion a little bit more to understand what that consultant did for Carl. And what we realized is Carl actually did all the right things. When consulting he mapped the value stream. Here's an example of it and while mapping the value stream, of course, he noticed that it was 14 days to get through the design phase, on your request flow. He noticed that was 10 days in your workflow automation at the bottom, your code to production, to get through the testing phase. So by the recommendations that the consultant made to Carl, they actually improved that they improved it by five days in design.

They improved it by two days, as well, in this section of what they were working on. Now, they did a whole bunch of other things that help them get that reduction in cycle time. But at the same time, here's the things that they did to improve those. So what they did is they decided not to to do a formal UI spec at the design phase. They actually did something really informal and they allow the developer to fill in the gaps while coding, and at the same time, they also reduced human testing and they introduce some automated UI testing in their DevOps flow or their material flow. So they did these two things and it gave them that reduction in cycle time, their time to market. So what happened was it really worth it? Well, you know, yeah, they got that 25% lead time reduction and cycle time reduction that they needed. But by de-emphasizing those stages, they actually frustrated their customers more because the user experience wasn't what it was supposed to be.

Things got through and additional rework would happen because buttons weren't in the right way and that would be caught by the customers and re-work and enter into the system and that's introducing more waste by removing waste, right? Or value, and their score started to drop. So what's the moral of the story? What why did I go through that scenario? It was to emphasize, really this point that we've been talking about that by diluting, in the pursuit of flow for Carl's organization, Big Bank, they diluted the value to the customer. In the pursuit of flow, they introduced more risk, frustrated their customers. They introduced more work, rework coming into the system. So in the pursuit of flow, they actually became less efficient in the value that they were delivering. It had the wrong effect. So that's why I came back to this thing about value trumps flow. And whenever you're doing a software value stream optimization program, You got to keep this in mind. How am I allowing value to get through the system? If what I'm going to do is remove a step, a sequence, something that is providing value so that I can achieve greater flow, that may be a bigger issue. So, you know, one of the things we are talked about a lot is the word value, value, of course, is anything in your software delivery value stream that is related to bringing out business outcomes, whether that's a sequence, a step whether it's an actual feature going through the value stream to get delivered. All these things are valuable things that happen for a reason and understanding why they are, the value they bring, is what you need to do. But make sure when you're in the pursuit of flow.

You're not putting at risk, value. So applying the lean decision filter to value stream management is actually pretty straightforward. The lean decision filter itself was created by David Anderson, and he defined it in this way. It's mostly was defined for how to look at outside work, coming into the Kanban, and working through that. But I thinking that you can absolutely apply this to value stream optimization and improving flow and value through your value stream. So I know, I get it, right. We don't want to eliminate waste. We need to eliminate waste, right? Of course, we want to get rid of waste in our software delivery processes, but we don't want to do them in expense of flow because flow trumps eliminating waste. So we don't want to remove things that's going to make you go slower. Of course, you don’t want to remove a process or a step or something you're doing to slow you down effectively. But at the same time when trying to eliminate waste and improve flow, you definitely don't want that to affect value focus on maximizing value. Be willing to sacrifice flow for value. If something takes you a couple more steps, but you're delivering more value or what you're delivering has greater value, sacrifice flow. So I also always come back to remind everybody to this when I’m doing a speaking session, is automation is great. And you can learn to use the lean decision filter here to help you with that. But remember, value stream management is human. It takes to humans to analyze and look at these things.

It takes a human to go and say, hey, if I remove this step that I won't get consistency in my user experience downstream, and I could have this effect. So we really need to understand that those types of things are human and normally will remain human for some time. So, where are we now? What's going on? So when you think about it, we're still really focusing on removing flow or I'm sorry increasing flow through the value stream rather than improving value. You know, IT organizations today are always thinking about how do I get faster cycle times, faster releases, but I'm not releasing something of value every minute. If I can release a code to production every minute, am I really releasing anything? Because it takes a little bit longer than that to get enough stuff into a build to go out. So then you're just releasing what you just released a minute ago. So that speed, even though it's great. It's not bringing more value to your customer in that way. And I suggest that we change focusing so much on flow, and we start to focus on value. Value is very important, flow is very important, improving flow is very important as well. So, what does this start with? You got to be able to visualize. We did a value stream map example earlier. You have to see everything, how it's working together, visualize it, map it. Understand how information is flowing through your organization. And then look at the tools using, you know, once you understand your flow and what's going on, you can use tools to automate and map up but make sure you've measured and you know, where these things are all put together, feedback loops, understanding all of that before you take action in your value stream. So what's the key take away from what I've said today, you know, I've talked about value trumps flow.

I've talked about DevOps tool chain automation, things like that. What I'm trying to really say is: improving flow is good, but increasing value is much more important and I've got to say this statement that we came up with, don't sacrifice value at the altar of flow. If you can listen to this it will be a lot easier as you're trying to understand how to improve your value stream. And you know, I think that's a great statement: don't sacrifice value at the altar of flow. And I’m going to leave you with my value trumps flow.

Thank you so much for attending my session today. I really appreciate it. And enjoy the rest of the conference. There are some great companies here, and some of my good friends are here presenting as well. Thank you so much.

Ready to get started?

Explore the integrations, check out the features, or get in touch