Value Streams

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts Peter Maddison and Dave Sharrock. How are you today, Dave?

Peter, I'm doing excellent. It sounds like you just got back from a vacation. I've not heard you're so full of energy for quite a while. How's it going?

It's going good. And I did just get back from a vacation, and I do have a bit more energy than usual, although we are recording this at the end of the week as usual. So it's been busy, as it so often is. So what's on the agenda for today?

Well, I I kind of wanted us to revisit or open up the Pandora's box that is value streams. We're seeing a lot of that, certainly in conversations that we have with clients, customers, uh, and so on, but also just in the in the community where everybody's latching on to this concept of a value stream. So maybe let's uh use today's chat to uncover what we mean by a value stream or how we create them, how we visualize them.

Yeah, that's uh it's a it's an interesting topic, and I I've seen the same, and uh even the conversation around uh value streams being the evolution from we've gone through Agile that had its 10 years, now we had DevOps had its 10 years, now we're having value streams as the next evolution and value streams and flow and how we look at organization design all based on value streams, all of these kind of things. So they're definitely it's coming up more in conversations. It's something that people are looking for. They're looking at how do I take this uh this model and I and apply it and understand it and and use it to help me solve problems in in my context in my organization.

Well, I think it's a little bit more like flares coming back into fashion. This is value streams started with lean, right? So, but let's let's focus on the the flares of the moment, if you like. So um I I see value streams as a natural. If I take a laddered approach to you know agility and then DevOps and then value streams, it's a natural consequence.

Yes.

If I start with the concept of a cross-functional team, why does Agile recommend cross-functional teams? Well, the purpose of that cross-functional team is to select a group of individuals who have the skills necessary to get something out of the door within a, let's call it a sprint if we're using Scrum as the framework. So that cross-functional team is all about eliminating or greatly reducing dependencies to get the work done. Q, our conversation of value streams being a very, you know, we've just scaled things up to look at an organization, but the principles are still the same. How do we bucket together the individual, the skills that we need, the practices that we need in order to deliver value at the end of a value stream with as few dependencies outside of that value stream as possible? What would you add to that?

And I think this, yeah, I think this ties nicely into a lot of the conversations we've been having around business agility and a lot of the that also is something that's coming to the forefront. This understanding that uh you you can't uh just have this isolated space where we we do agile in IT and we don't do it anywhere else, and we can we don't we have uh we need to have a take a broader picture. Uh even within within IT to deliver a large complex system, we need to align across multiple teams and multiple groups and understand what the overall system that's required to deliver value is and understand where are the impediments, where are the dependencies, where can we start to optimize and and see are we are we properly aligned? And value streams is a is a useful frame that we can use for that.

Well, I I always think of these as containers. If I look at a value stream, I'm delivering something to an end user, a customer. That's the value that we're going to to kind of get out of the door. And there's a lot more than just the digital product element that we often focus on in that sort of agile and DevOps space. There is customer service supporting it, there's some sort of sales marketing engine around it. There's there's many other different aspects, whether it's training or onboarding or whatever it might be. And it gets more complicated if you start then rolling in, well, if I have this product or service, I need something else as well. And so we start, you know, creating baskets of value that go out to different customers and so on. But if I just take a moment to focus on that value stream as a whole, what's the benefit? Why should an organization start cleaning off their whiteboards and scratching their heads about how to structure value streams in their organization? What's the value benefit they're going to see?

Well, for me, I think one of the key pieces of this is they already have value streams. There's already, presuming that they're a profitable organization that actually delivers value to the outside of the organization, they presumably have a stream of value being generated within the organization. They already have a value stream. The reason to wipe off the whiteboard and to start to look at this from this perspective is that now we can start to see, well, what does it actually take us, take for us to deliver that value? What are the various steps that we go through? Who has to be involved? How long does it take us to do that? Where are we running into roadblocks? Where are the problems that we're having? And that's when we can start to understand and say, okay, so how can we go about organizing ourselves to eliminate some of these dependencies? Or where could we introduce a change in the way that uh we're doing things so that it would help us be get better at delivering value to our customers?

Well, and I if I just pick up, you know, the benefit of that, of course, is we're working in an environment now, most of the organizations that we're thinking of here are in an environment where speed, like customers' expectations are fleeting, they change really quickly. So, in order to be relevant to customers, we need to be able to respond. We need to be able to get things in their hands that they value, that is useful to them pretty fast. And so, in an organization where we may have multiple value streams and we're sharing resources or capabilities, tooling and so on across these different value streams, if speed isn't of the essence, we can handle those dependencies and it's just part of the way we've always worked. I think functional structures in IT organizations a decade ago. The reason for the change is that that functional approach, though optimized on the function, was not optimized for speed of delivery. And the same is true around the value streams. We're needing to be able to be more reactive, more responsive to customer needs. And I think that introduces a couple of things. We the value stream isn't simply mapping out how we get value to our end users or customers. We need a feedback loop that brings that customer's kind of experience back into the value stream. And that's something that sometimes people forget. We think it's all about that value, like a value stream mapping exercise, but without bringing a loop back to the beginning of the value stream. Yes, precisely.

I mean, and in some ways, this is this is uh DevOps 101 was bringing a lot of these concepts in out of lean. Uh if you go back like a decade or more, they were uh they were talking about exactly this. It's the you you make you make the work visible, you uh you understand the the system and you create those feedback loops and then you continually improve. And that's kind of the going way back to the things like the Phoenix project or other models like that, where we're we're talking about uh those aspects. And uh so to the your first comment, which is around uh value streams somewhat being a little like flares and being back in fashion, uh this isn't some of this isn't very much isn't really new. It's more that uh we're seeing and maturing to the point where we can see how we can apply this to our organizations and how to use this in a valuable way so that we can uh start to uh make improvements.

Um, but I also I I think it is it's like anything that comes back into fashion, it comes back in, but it's also been improved on and built on top of. And I think that's something that we've got to remember too. One one piece that comes into that is this whole part about customer. The the and of course it's been involved all the time, but we're now in a space where we can get feedback from customers rapidly, and we can incorporate that feedback into some of the ideas that we're delivering and working on very, very rapidly. So, how does that happen? That's certainly part of the purpose of the value stream. I think there are other couple of other things that we need in a value stream as well. Um, one of them is some sort of control over financing, and by that I don't I mean a value stream is typically funded as an entity in itself, a container in itself, but it's also how that funding is spent across the value stream has to be owned within the value stream because that customer feedback loop is going to drive a change to the original plan. My 2022 plan that I had ready for January 1 is morphing and changing and being tweaked as we move through the year. That funding decision about where the funds are being spent or invested, that product ownership mindset has to be within the value stream as well. Um, and I'm just gonna add one quick other thing and then ask you to kind of chip in or clean up the mess that I've made. But the other one is priority, is understanding how to make those spending decisions, where to spend time and energy. And so priorities come in within a value stream, even though we sometimes think, no, this value stream is its own priority, even within that value stream, there will be priorities that you have to continually trade off against. And of course, those between value streams as well, we're going to have priorities that we have to trade off against.

Yeah, very, very much so. Uh and I if I if I think back and think about some of the pieces that I would I would pull out of this discussion, I think one of the one of the main ones is, I mean, it is what's old is new again, but we're bringing with it a number of improvements and and understanding that you already have value streams. You they already exist in your organization. It's not that we'd you'd be coming in to create something new, but you're understanding how your organization does things. You're understanding this so that you can learn how to improve and you can know where to focus, where to put your money, how to where to prioritize by identifying the value streams, organizing around them so that you can uh optimize your organization to be able to deliver more effectively and and faster and respond to your customers in a in a better fashion. And so that I mean that's that's how I would kind of sum all of this up in uh one. Is there anything you would add to that?

Not at all. I think you've nailed it there. Like I I I actually think recognizing that value streams are already there means that having white cleaned off our whiteboard, our first start activity is map what we already know about and then start emerging or changing, guiding the the restructuring from there. Brilliant point.

Yep. Start small and it's always good.

Okay.

Well, with that, I'd like to thank you as always, Dave. It's uh it's always a pleasure. And uh if anybody wants to reach out to us, they uh can at feedback at definitely maybeagile.com. And uh until next time, thank you. Looking forward to it. Thanks again, Pete. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.