Software Delivery in Small Batches

[00:00:00] Hello and welcome. I'm your host Adam Hawkins. In each episode, I present a small batch with theory and practices behind building a high velocity software organization. Topics include dev ops, lean software architecture, continuous delivery, and conversations with industry leaders. Now let's begin today's episode.

[00:00:26] Hello again, everybody. And welcome back to small batch. Today is the inaugural episode for the voicemail listener request line. We had to listen to her call in and request an episode on value streams. So let's give that a listen.

[00:00:43] Hey, this is Steve. I work for visible value stream consulting and I love all the episodes that you've done so far. I'd love to see one specifically on value streams value stream thinking, mapping or management.

[00:00:58] That would all be great. All right. Thank you, Steve, for calling in with that request. If you'd like your topic covered on the show, then you can call in at plus +1 833-933-1912 and leave requests in a voicemails.

[00:01:15] Preference for episodes that goes to listen to requests. So call in and you just might get it. So thank you, Steve, for the suggestion on value streams, I realized that we have not yet discussed value streams yet on the podcast, but they are so fundamental to all the different topics in the work that we do as it relates to software deliver.

[00:01:39] So I reached out to Mick Kerstin from the flow framework and works at Tasktop. If he could connect me to somebody to talk to him, the topic, and he recommended that I speak with his friend, Carmen. Diardo, I'm really happy to welcome Carmen to the show. We had a great conversation on sort of all the different facets of value streams, what they are, why they're important, you know, value stream mapping architecture, as it relates to the flow framework, software delivery, all the kind of basic stuff that you just need to know.

[00:02:14] It's just the fundamentals. So let me read off Carmen's official bio here, part technical guru and part storyteller. Carmen is an award winning public speaker and published. His latest works, include a number of it. Revolution, forum papers, and the 2019 books standing on shoulders, a leader's guide to digital transformation drawing upon his vast and varied experience, including three patents in software engineering.

[00:02:41] Carmen is a senior VSM strategist at Tasktop helping software organizations to accelerate the flow of business value through the implementation of integrated delivery pipelines and pioneering the flow frame. Now, I just want to repeat one thing that really stuck with me from this conversation. And if you listen to the salt side Chronicles, you're probably know what I'm talking about, which is how Carmen framed the flow framework and the four types of work into two different categories, revenue protection, and revenue generation.

[00:03:18] It has really stuck with me because it just cuts to the core of what those different types of work are for and how to represent those in your value stream. And really how to think about the work that you do on a daily basis. It also makes it easy to see if the dial is going too far to one end of the spectrum for far too long, you know, working on revenue generation without considering revenue protection.

[00:03:46] You know, what's the point of generating revenue. If you can't maintain it. Anyway, I really enjoyed this conversation with Carmen. So now I gave you my conversation with Carmen. Biardo.

[00:04:01] Carmen welcome to small batches. How are you today? Good.

[00:04:04] Adam's great to be here and thanks for having me.

[00:04:08] Oh my pleasure. So today we will be talking about value streams. I had a listener request, an episode on the topic, and I realized that I hadn't really talked about value streams or value stream architecture or any of these sort of.

[00:04:25] Lower level topics that come up in every single and all the literature on like dev ops or full Feinberg and all this stuff. So I figured that it bring you on the show and kind of get introductory to immediate, to expert level discussion of value streams and why we care about them. How are they useful?

[00:04:46] So my first question to you is how do you define a value stream? It's sort of a vague topic. So to get started. How do we define value streams and what are they?

[00:04:57] Yeah, that's a great question. And one, one, we kinda get a lot. And so I always start by saying that a value stream starts and ends with a customer.

[00:05:06] It's really the set, the end to end set of activities performed to deliver value to that customer through a product or service. And I think sometimes people get hung up a little because they think of value streams and products as. Well, you know, if I'm in a company, these are things that we're selling and people were buying, but really everybody I'll say everybody in the company really has a team with a customer and a value stream.

[00:05:37] So I think one of the things, you know, as we talked through this is that concept of, you know, everybody actually. Is working in some way on activities to deliver value to something, to somebody. Right. And, and yet I don't think a lot of times that's the way people are conditioned to think about how they're doing their work.

[00:06:01] Do you see it more as like a smaller box? Like they think of themselves in a smaller box, whereas with the value stream, trying to convey the point that you're part of this much larger process.

[00:06:14] Yeah, I think it's, it's, it's interesting because you know, I've had conversations with customers or where, you know, different areas of a customer and we talk about, well, you know, who are your customers and what value do you provide?

[00:06:30] Hmm. Sometimes it's a little bit of crickets and, you know, I generally will try to say, well, you know, who would care if you weren't around? I mean, I might not say it exactly like that, but, but trying to bring out, obviously there is value to what you're doing. And obviously there are customers, you know, but get them into that mindset.

[00:06:50] Because again, if they're an internal team, which most. Value streams are internal. They just don't have that way of thinking about it. And then they don't think then that flows. Applies to them when really it does. And in many ways it's more important because if you don't have flow on those internal teams, that's, what's an enabling a lot of your external teams.

[00:07:11] So, and I don't want to get that a rabbit hole right now, but it's important that, you know, to get those concepts across to a lot of areas of the organization that aren't really thinking about.

[00:07:24] Right. So in my mind, the way that I think about this, and I'm not sure how you approach this, but, you know, I just think of a pipeline.

[00:07:33] So on one end you have. All of the inputs, this cause be like, whatever the work that you do could be, you know, bug fixes could be supporting internal team members. It could be customer support, it could be anything. And then on the right hand of this pipeline is all kinds of business results. This might be lower costs.

[00:07:54] This might be deploying a feature, fixing a bug, servicing the customer support, like sending an email. It could be any number of things, but I think that's kind of where. The challenges for some people and that it's vague in the sense of the inputs and the output. Like the inputs could be anything, but I think the outputs can, or more quantifiable incentives.

[00:08:16] Is it easier to define like the business value on the output as opposed to the input side? What do you think?

[00:08:24] Yeah, I think that's a good point is, is that, you know, you're, you're getting inputs from your costs from her and then providing them with a product or service and getting feedbacks as you can go through that continuous feedback loop.

[00:08:37] And I think a lot of times actually people struggle with. What I call the left-hand side of the value stream. And especially when you think about it and you think about agile and you think about dev ops, there's been a lot of emphasis on what I call code the clock. But it's really that upfront part of the value stream, where we estimate sometimes companies can spend half their time and half their money that is the least defined and the most nebulous and where, you know, if things aren't visible, you can't manage them.

[00:09:10] We kind of have a saying that either you manage your value stream or your value stream manages you. And that's where I think there's a lot of focus. It's probably. Most of the people that I work with, you know, their bottleneck, the thing that's stopping their flow is not really generally the middle of the value stream.

[00:09:30] We've kind of spent a lot of time optimizing that it's actually the ends and it's more likely to be the right hand side than it is the left hand. I mean, the left-hand side than it is the right hand side. Well,

[00:09:41] it sounds like what you're describing to me. The kind of the fuzzy front end problem. You'll talk about say I just did a, an episode on service level objectives, and we were talking about the hardest part about the SLS is actually defining the measurement because that's where it starts.

[00:09:58] Like that's the input to the value stream. The SLO defines, right? Like how do you measure all of that? What is that? And who are you actually measuring it for? Like once you have the left side of the value stream, the middle and the end become. But like, as you said, if you can't define it or visualize that, then how are you going to make any progress?

[00:10:20] Like even under the worst case you spend your time and energy trying to optimize the middle when you don't even know what the left hand side is. Right.

[00:10:27] Exactly. So a lot of times what we do start is with that work intake process, and we get them to think not just about one type of work, but all types of work.

[00:10:37] And so it's not just. You know, the, what I'll call features or enhancements to whatever you're doing, which is typically what people and customers think about the most. Right. I'm paying you, I'm investing in something I'm expecting some goodies back from that. And that's fine. I mean, that's what selling, generating new business, you know, whether it's, again, it's an internal or an external product.

[00:11:04] I could be an operations team or providing new platform as a service capabilities. That's what my customers, in this point are developers consuming that so they can produce some great product to sell. They want those goodies. That's what they're looking for, but then there's the other types of war. You know, that you also have to pay attention to, right.

[00:11:26] There's there's defects. Right. And where do they come from? Where do they start? Sometimes we, when we talk about defects, there's like three types of defects, right? There's production incidents or things that you're getting back from the field. There's things that you're, and I'm talking more about software, you know, the soft, probably your more traditional product delivery now, but then you have your like, defects that you find.

[00:11:53] In the release process and then there's defects or bugs or whatever nomenclature people were using that you find in an iteration where, or a scrum, where they may not even say that's a defect, but those are three different types of rework, if you will. And they have very different characteristics and they may have very different intakes.

[00:12:15] Right. The incident may come from a service management system of an incident or problem. The release defect may be in a quality management system like ALM or, or such where the re where you're doing quality release testing and any bugs. You find your. Your agile process, maybe in your agile management. So, so there's three different work intakes there, and that most people don't really think through.

[00:12:45] So that becomes an interesting conversation because they all have their different characteristics. They all have their different flows and they all have. Probably have different bottlenecks. They eventually may get back to, I got to fix something, which means I got to go back through my development process.

[00:13:00] But before you get there, they may have very different characteristics and how they're identified and analyzed and triaged before. That's the term. And

[00:13:10] I feel like when you, you mentioned these different intakes into this value stream, what kind of dancing around the edge of another conversation, which is value stream mapping.

[00:13:21] Right. So if you're thinking about, you know, I mentioned the model of evaluation as a pipeline, you know, inputs on the left outputs, on the right. That's a simplistic model. And that there's only one thing coming into the pipe, but in reality, The pipes are connected to many other pipes and they stuffed flows and money to move directions.

[00:13:39] And, you know, part of the, the challenge, like you said, is identifying all of these different inputs and where they come from and really is this just a segue into. Value stream mapping, like all these exercises of trying to visualize it and identify all of, all the different steps and inputs in this process, such that a participant in the value stream can see where they are, what their inputs are, what their outfits are like, where they may interact, who they may interact with, who might depend on them and all of these things.

[00:14:11] Right,

[00:14:12] right. So I had the opportunity at when I was working at nationwide. And my I worked a lot with Tom Pater and Mike oars, and he wrote a book on lean. It filled God, and we did a lot of value stream mapping. And sometimes there's a kind of this ying and yang between value, stream management and value stream mapping.

[00:14:33] And I believe they both have a role to play, you know, value stream mapping, let you get deeper into what are those steps of activities and interactions. And most importantly handoffs, because I think. May I, my Kirsten points out in his book, it's really a net one. Right. Yeah. I mean, he, he described to me once after a plane ride, you know, he was looking at the routes in the that you can see, you know, if you really want anything to do, sorry, Mac you grab, you, grab it on.

[00:15:04] And it shows all the Hobbs and everything. And it, I, I think it kind of hit him. That's really the way work flows through value streams, right? It can go to here to another team. You have dependencies. It's not just this linear view. I mean, I used to think that with my telecommunications background, I would think about it more like how we switch switch calls, right.

[00:15:24] And, you know, they work with not just point a to point B. There were hops and different things that you might have to go through. So it's really a network, but when you look at value stream mapping, you're really focused on. You know, instead of activities. And, and sometimes I would joke that it sounded more like, like wishes and dreams than reality.

[00:15:45] Like, is this really how things work or is this how we hope they work or wish they were? And that's not a knock on it. It's just was hard to always say, you know, is this the one path? Is this the happy path? Or are there other paths, you know, how long are things taking? Well, You know, a lot of discussion was hard sometimes to understand that.

[00:16:08] And then once you did it, was it sustainable or was it like a one-time activity? You learned something you could improve, but it was hard to sustain because it was such a human labor intensive activity. The thing I think when I first started talking to Mick was I said, well, I remember a conversation where I said, Mick, you could realize our value stream for us.

[00:16:31] And that was because. All the artifacts that represented the war, the stories, the epics, the bugs, the security bugs, all those things were actually in the tools that we're moving across our value stream. And if we could actually see those and measure those. Not only could we see where things were getting hung up, but as we made changes, we would have kind of a digital footprint if you will, of that work because we're taking it from the tools themselves and we're able to generate flow metrics full magic, or we'll be generating from those.

[00:17:10] And that's kind of where Forster ended up with his view of value stream management. They talk about, you know, people process technology, that map. Visualizes flow through software delivery pipelines. So what excited me was that you could actually start to get a view of this flow through this network now, based on the tooling that was being used of where things were flowing.

[00:17:36] But most importantly is Tom would Tom Peter would say, Carmen, why are we doing this? Well, it's because we want to see where things aren't flowing, where they're slowing down or stopping. So. Now, once you kind of isolate an area where you think things are, you know, you have a bottle of it. I think you can take a deeper dive with value stream mapping, right?

[00:17:56] The states in your tools may not be sufficient to show you. Exactly. It's kind of like, you know, you're looking at a traffic jam from above and you can see cars are slowing down here or there, but you might have to get on the ground and do a little more investigation. Talk to the people involved. They actually say, you know, why what's going on here?

[00:18:18] What happens at what time of day that causes all these things to occur? So, so I think value stream management allows actually value stream mapping in some ways to be done more effectively because it gives you kind of the map of where to take a deeper dive. And then once you make changes, you can then again, get those measurements right away and say, okay, Was this better?

[00:18:41] Was this worse? What happened here? What adjustments do I need to make? Sure.

[00:18:46] Okay. That makes sense. I want to dive a little bit deeper into sort of the beginner's approach to value stream map. So let's say that you come to an organization and they're just entering this pool of, you know, value streams and value stream management.

[00:19:04] And, you know, trying to think in this way, and they're working on the left and the right of this thing, and they say, okay, let's try to map this out. What does that process look like? And what are the desired outcomes from that?

[00:19:18] So when we started to work with a team, we have this concept to be either a value stream architecture diagram or, or a Vaseline canvas, which is kind of a lighter value stream map, if you will.

[00:19:30] And we'll say, you know, in our, in the flow framework that may created, we talk about four types of work, features, defects, risks, and death. And so we'll generally start with something like a feature and we'll just say, okay, first of all, We'll say where what's your work intake process, where do features first show themselves, right.

[00:19:53] And we'll talk about, well, you know, what tool do they show? Is it, what is the artifact? Are these epics, are these stories? Where do they come in? And then we'll essentially just say, okay, then what? Well, they may have a portfolio. We know what's your portfolio planning process. Is it all Microsoft? Is it all Excel?

[00:20:13] Is it spreadsheets? Are you actually using a tool? You know, a plan view or a JIRA line or something, you know, then what happens? Well, we do discovery. We break it down. We'll have a feature, then we'll have stories. Okay. Where do those stories go? Well, you know, they'll, they'll go into JIRA and, and then we'll have planning meetings.

[00:20:33] We may be, we're doing safe. Maybe we're doing two week iteration. You know, you ask a question, what do you have away storage, right. Or all the stories done by your team? Or do you have dependencies? Oh yeah. We have these things that go to other teams. Well, then what happens? I don't know. We don't know what happens.

[00:20:51] Those are the things that will always lady God. Okay. So write that down, right? Because. It's the handoffs. Right? I talk a lot about, it's not that people are waiting, it's work that way. Right. And then, you know, in a manufacturing plant, you can go to the fourth floor and you can look down and you can see inventory building up.

[00:21:10] Or like I said, you can see traffic jams. Where is the inventory in our software processes? It's hard to see that it's hard to see where work is waiting. Even if you go to Gamba, people will be busy. So, how do you know where work is waiting? So we sensually will walk through this process of, you know, what, what happens next?

[00:21:33] You know? Well, it we'll pull it into an iteration or using a pull model, you know, all the way through their CIC D to the point where it's only done. Right. But then there's always this question between done and done, done, done, and released. And change approval processes and whatever might come on the right-hand side.

[00:21:54] So essentially what we create out of that is a diagram of, you know, those artifacts and how they flow from in our world. We think of four phases, Ida, create release, and operate, and we'll do that for every, each one of the four types of work and essentially create. You know, a diagram of visual that will show the input, all the artifacts that are involved, the tools that they go through the states eventually we'll get into the states of those things and talk about which of these are active states and which of these are waiting stage.

[00:22:35] Right? So I have a state, you know, waiting for dev or waiting for a code review. Now, many times. If all you have is improv, you know, backlog in progress done that doesn't give you too much. Right? Right. So, you know, a lot of times we have to talk through how you can get more visibility because without that, you know, it's hard to shed some light on as, but, you know, again, we'll do that for features in defects first recent that are different kinds of conversations because many times.

[00:23:08] It's like, well, what's your work intake for rest

[00:23:14] and production now, you know about it or are you proactively finding these things? How does it happen?

[00:23:18] Right. So people will say, well, where do you security scans? We do static scans. We do dynamic stands. That's all great. What happens? Well, we run a report. Okay. Security manager looks at it. Okay. They schedule a meeting with the team.

[00:23:32] Okay. They begged the team to try to do this. I mean, there's usually a lot of opportunity when you talk about security into, you know, getting it into the backlog with sufficient priority to actually get it worked on because especially in a project model, project managers, all. Incentivized to take on more work like this in a product model.

[00:24:00] At least now you can start talking about, you have to keep your product healthy. It's like a healthy diet. You have to have, you know, yes. Features are the R w porn. You obviously have defects, which you hope you're managing with higher quality. So they've not consuming a lot of your capacity, but then you have to pay attention to risk or you will pay the price.

[00:24:22] Risk is what I call revenue protection features or revenue generation or value generation risks or value protection, defects, or value protection. So it doesn't do me any good to get customers. If you're going to lose 'em because you can't keep them happy.

[00:24:40] Wow. I actually, I really liked that the framing of it.

[00:24:44] Like they're all counted cause kind of a countermeasure to something happening. Right? You have the generation and the protection because you know, I've been in organizations where they have not done any work on the risks and then something happens where, you know, there's for want of a better term, some fire or some catastrophe or some new requirement that comes in that because none of these risks have been dealt with.

[00:25:11] Oh, what are you going to do? We can't do anything about this. And then what happens? You're like on the worst, on the worst case, maybe you can't do any work on features for an extremely long amount of time because you have all of this typical debt to pay back because you've never done anything to protect your ability to continually bring in revenue.

[00:25:31] And that's a kind of a segue into one of the reasons why I really enjoy the flow. The flow framework is visit, got the flow metrics and the business. And if you can frame the conversation. In terms of those business results, then I think you can talk to any of the stakeholders in the value stream, be it engineers, product managers, you know, executives, whatever, because hopefully they're all focused on the same thing regardless of how each individual person contributes to that.

[00:26:00] So thank you so much for sharing that perspective, but I want to bring it back to the beginning. When you mentioned going through the exercise of value stream mapping. One thing I'm curious on is when you go through these exercises, do you try to start this conversation with say a kind of a group of people across all the different departments or teams in the organization?

[00:26:27] Because you know that eventually it's going to spend, expand out to like other people who may not be part of that, or like, if you try to start there or if you say that, okay. Maybe only the engineering team is part of. Then, you know that it's going to expand out into marketing and all these other areas.

[00:26:44] I guess the question is for an organization or a team that wants to go through this exercise, who are the best people to involve in that initially?

[00:26:54] Yeah. That's a great question. So we try to, you know, try to start out with making a, it's kind of like an MVP. We try to make a minimal investment and see how far we can go with that.

[00:27:05] So, you know, sometimes it can be. We try to start with just a handful of people. You know, it could be a product and, you know, there's different roles in different organizations. It could be a product manager or product lead, a scrum master, a dev lead, you know, a, a tech lead, a set of people who basically understand as much as possible this end to end flow of work.

[00:27:31] And then we will bring in other people as needed. You know, to fill in the gaps, you know, if, if as needed, right? So we'll start out, you know, with only a handful of people and we'll go through an iterative process. And of course, you know, we now have a product where we can actually implement this is, you know, are the test on this product.

[00:27:54] So we're actually doing modeling and we'll we'll, you know, we'll say, okay, well, where did, where did these things reside? We'll bring in those artifacts and we'll model them. And it's interesting because even within an organization, you'll find a lot, you may find a lot of variability in to how they think about their value stream and the set of steps that they go through.

[00:28:18] Which is fine because we can accommodate that. We kind of sit above the fray, but it's just interesting hearing some of these conversations, some organizations, no matter who you talk to, you're going to hear almost the same story. Some organizations, every team is going to have a little different flavor, which is fine, but you have to, so you have to go through that with the team that you're actually working with, you know, to build out kind of that model of all those types of work.

[00:28:46] And then she, you know how you can then start to measure it and, and get them in the cadence of consuming these metrics and using it to drive. Improvements in their flow.

[00:28:58] So let's step back a little bit. So let's talk about what we've covered so far. So we've talked about value streams, the idea we've talked about value stream mapping and value stream management.

[00:29:10] And in my mind, I'm thinking, okay, so we have the goal. We define the value stream. We do this mapping, try to visualize it, understand how it all fits together, who participates in it, who does what, when all this type of stuff. That to me is actually the really hard problem of it all because, you know, if you can't visualize it, if you can't see.

[00:29:33] You know, you can't model it. If you can't model it, you can't measure it. If you can't measure it, you can't improve it and you can't assess it. You really can't do anything with it. So this is not a unique problem to value streams. You know, it's like all of the type of work that we do. It's always like, just figure out some way how to visualize it and measure it, and then you can start doing something.

[00:29:51] But that seems to be like where the, like the hard problem of it is, especially given that if we look at things like the flow framework and dev. You know, the book, the flow framework, sub subtitle, it's project product, but trying to get all of the members of the wider value stream. However, however big it is understanding that they are in fact part of this wider value stream and that we're trying to get this continuous flow through it such that we can focus on.

[00:30:25] The end results. And now we've sort of ladder up to the top tool where we can talk about the flow framework and the flow metrics. We've mentioned the four types of work. We've mentioned all of these things so far. It's almost impossible to have a conversation about value streams at this point, without mentioning those because of so important.

[00:30:43] So maybe you can just give a, you know, a short summary of like what the full metrics are and why the flow framework is important to this.

[00:30:54] Sure Adam. So, so, you know, the full framework is really based on really this concept of VSM, which has really evolved and been defined as its own practice over the last few years of, of utilizing.

[00:31:09] Again, the information in the pipeline itself in those tools that represent the flow of work, the stories, epics, defects, change, incidents, problems, all the things that may be relevant to those four types work. And so once you've modeled that and again into is an inner process, and we can talk more about dependencies and things.

[00:31:34] Maybe as we move forward, once you've modeled that you can start to look at what are the flow metrics, the flow metrics in the, in the flow of framework or. You know, flow load, which essentially is work in process progress. However you define your P and, you know, I, you know, one of the people that I've deployed your work was Dominica to grant that she actually helped, you know, that that generation protection was actually, I think I stole that from her, so I should give her credit for that.

[00:32:03] But you know, she talks a lot about. Too much whip and work in progress. So flow load is very important because it represents here's all the work you have in process, and we can talk more, but that is usually a surprise to people. Once we actually show it to them, flow velocity is how many things of each type you are completing within a time unit.

[00:32:26] So you could say in the last month we completed 20 features, 10 defects, two risk items, one day. So it's a measure of throughput or productivity flow time is how long it taught from. And I think you said it very adroitly when you want to start the clock to when you want to stop the clock, which we kind of leave up to the customer and we will coach to the pitfalls.

[00:32:52] Right. But the difference between lead time and flow time is you may have a request for something. A customer may have a request. They put on a queue, you may get hundreds of these. That you're never going to serve as the time starts when you actually say, okay, we're going to look at this item and we're going to start to do work and invest in getting it completed.

[00:33:11] And then it measures how long, you know, again, from that point in time to it's actually been delivered to the customer and can be realized its value can be realized for efficiency. You know, one of the things that in the modeling. When you're looking at these artifacts, like a story, and it's going through various states, it has active states and as wait states, because again, it's the work that's either active or waiting and flow efficiency is a measure of that.

[00:33:40] So if something is 50%, if you have a flow fish, do you have 50% for features? That means roughly half the time it's active and half the time. It's way now we know, because the robustness of the scheme is the most of this tool will inflate that number. If you look at lean manufacturing and you compare that to like the concept of utilization, you'll find many times a utilization of under 10% or under 5% in terms of inventory, moving through a plant or whatever we know it's going to be inflated somewhat, but it's still a measure of.

[00:34:15] Of work versus way that, that shine some light on things. And then finally flow distribution is kind of a separate metric in the sense that it's looking at the work that's completed and it's showing you what percentage of work has been completed. So in a way it's shining a light on how much of each type of work that you're investing in prioritizing and completing.

[00:34:40] And that's where you can kind of look at. Okay. Is this a healthy profile, right? Is there too much defects or there's not enough features. There's not enough investment in debt and there's really not a right or wrong because at a different point in the life cycle, you may decide to invest in different things.

[00:34:59] You may do a feature push and build up some debt and some defects, and then you have to spend some time, you know, in the next release, working that off. So. But if you're looking at a trend over time and you're seeing things like, you know, your feature capacity is dwindling, your defects are going up.

[00:35:17] There's no investment in debt. Your flow velocity is going down your float. Time's going up. Those are all a pattern of a death spiral or a dead spiral that, you know, can, can be catastrophic if you could, if you don't get your hands around to manage that. Oh

[00:35:36] yeah. All right, let's take a quick break from today's episode so I can tell you about my other software delivery resources.

[00:35:44] First I'm opening up my own software delivery dojo. My dojo is a four week program designed to level up your skills, building, deploying, and operating and production systems. Each week, participants will go through theoretical and practical exercises led by me designed to hone the skills needed for continuous delivery.

[00:36:03] I'm offering this dojo at an amazingly affordable price to small badges. Listeners spots are limited though. So I'll apply now as software delivery, dojo.com. Well, if you want something free instead, I've got you there to find links to my free email courses and eBooks on any show notes, page my courses and eBooks cover topics in much more depth than I can cover on the podcast.

[00:36:25] They're great on their own, or even as a useful compliment to topics covered on this. Find all of my free resources@smallbatches.fm. All right, let's get back into the episode. I mentioned this explicitly in the episode I did on the flow framework is the four types of work given that they're mutually exhaustive and exclusive that this covers everything that it gives you a nice sort of overview of exactly how you're allotting your resources.

[00:36:54] And part of the problem is. You know, avoiding the death spiral is being aware of the long-term effects of what you're choosing to work on. And given the four types of work, they make it easier, easier to at least see it, if you can measure it. And then as you say, there is no correct answer, but they're all, you know, it's a tension and a trade off between revenue generation revenue protection, like depending on where you are.

[00:37:22] In the particular, you know, the timeline of your organization and what are your short-term mid-term long-term goals, you know? And like, I look at the graphic of the flow framework and at the top, you know, you have the flow metrics on, on the left and the business results on the right, you know, and then the inputs are the four different types of work to me.

[00:37:42] This sort of fits the model of the simple pipe. Right. And puts on the left outputs on the right. But if you actually look inside of that, You know, there's a, there could be going every single, which way you look deeper, it's like networks and all of this, that, and that comes back to the importance of doing the value stream mapping.

[00:37:58] When you talked about a flow efficiency, if you're talking about handoffs and wait states and that, you know, the more. Different teams. You're going to hand things off to the more potential weight states you have. You're not waiting on people, but the work is waiting. So what we're trying to focus on as the flow items themselves, so you can take it from the top down to the flow framework and look down into your value stream network, right?

[00:38:21] Not the value stream itself, but the network and see where everything is actually happening. But you know, you have to first have that. Like understanding of the whole picture before you can actually get started with it. I think that's just where really the hard part of this whole thing is, is, you know, getting people aware of their place in the value stream network, and then that they are connected to these other people or other, other value streams and the types of things that they, they provide.

[00:38:53] So, How in your experience, do you help teams or individuals make the connection to the wider value stream may operate in?

[00:39:06] Yeah, that's a great question, Adam. So, so as I said, you know, a lot of times this is an iterative process. We talk about. You know, the stage is like, you know, as you start out learning to see, right, you just want us to be able to see what's going on and then you want to learn to improve based on that.

[00:39:22] And so, so we may start out. So, you know, a typical thing might be, you start out with a product value stream and it. It's two teams in there. They are doing, they're delivering some value direct to an external, to their external customers and they're doing their agile things and it all looks good and they have, they think everything's great.

[00:39:43] So, you know, you kind of do them all and you start to look at the flow metrics and then you'll say, well, You know, what's causing you not to be able to go faster. Right? So in your whole concept here is to use this information in your retros, but very specifically, ask questions around speed. What is keeping you from going faster?

[00:40:05] Because if you ask sometimes how can you go faster? People kind of think one way about that. But when you say something the other way, which says what's in your way of going fast or what barriers you experience, you tend to get kind of. Flow information. Right? Well, it's because you know, our change approval board, we can't get in there until every other week.

[00:40:30] And so work sits when it's done, but we can't get out because we can't do this. Or, you know, and this is where the dependencies can come up. So, so for example, working with his team, they have two, two pizza teams at all. Looks like a beautiful thing. And then you say, well, well, yeah, we have work that we're waiting for.

[00:40:50] Yeah. You see a state that's kind of long, but it's not really clearly defined. It's like ready for task. Okay. These are staying in this ready for test a long time. And there's a big pile up. We've seen 40, 50, 60 things, right. Features, defects, whatever, sitting there, you know? Yeah, yeah. That has there's there's this backend team and things have to go through there.

[00:41:16] And, you know, that's where we have to wait. Okay. Well maybe we should bring them in. You think it would be helpful to bring them in? Yeah, that would be great. So, so again, as long as one of the advantages of veggie management is if you know where the work is, you can, you can start to bring, bring their work into the whatever value stream view you're looking at.

[00:41:39] Sometimes. With a minimal contact with the once you've been working with an organization. Well, okay. Where's their work? Well, their work is in this JIRA and it's in here. Okay. It's in this container. Okay. We look at it. And now we're starting to see, not just this team's work, but everybody's work and what it looks like a little bottleneck with this team is actually a huge bottleneck because there's all these things that's getting caught up.

[00:42:06] And so a typical example that I had is, is showing this to various levels of leadership and you could see their eyes get big. And the one leader said, Yeah, that team, that backend team we've been ignoring for years, right? Because they're not the sexy thing. They're not, we're investing in. You know, that's not something, you know, having multiple test environments or mobile ways.

[00:42:33] They've that team's gotten too big. They almost needed like an, what I call an HOV lane. So higher priority work could go faster, like a faster current. They said they have a three-week really certification process. Well, there's all this work have to go through. It could some work be short-circuited can.

[00:42:49] So Marco fast. Then their eyes get big and they say, yeah, we have to invest there. It doesn't matter how much money I throw out these two mobile teams. That's not going to fix this problem. And, and then sometimes when you're looking at it, you also see that they've built up now months and months of work.

[00:43:11] On the intake side, based on their velocity, they might take them 3, 4, 5 months to work through that. So they have a bunch of people. I caught like making pizza boxes. They're making all these boxes, but the problem you already have enough work there. The problem is over here, you don't have enough people to deliver the pizzas.

[00:43:32] And the last thing you need to need really is, you know, more developed. Right. So the idea is law, you know, just hire more developers. That's the worst thing you could do right now, because you'll just create more backlog for this bottleneck on your right-hand side, your downstream side. That's your problem right now?

[00:43:50] So. It's a learning process and you, you know, you kind of show them and then you kind of go with it. Okay. Where let's have a conversation about this. Where, why is this state too long? What other teams are involved? Maybe it's performance testing. Oh, well we have a performance thing we have to go to. They have an SLA of 30 days.

[00:44:14] Oh, well, can we make that self-service maybe not, maybe not all the work, but 80, 90% of the time. You can make that self-service, you can get rid of that SLA. All right. And now it's not that you don't need a performance SMEEs you do, but they're more focused on the process and making performance as a service, if you will, or maybe getting involved with deep dives with performance issues, but they don't have to be in the execution path of every delivery that you do.

[00:44:46] So you just start to chip away and you kind of just follow the data and follow the flow. If you will, to see what is the next cause you're always going to have a bottleneck. It's a question again. Are you managing the bottleneck? Are you designing the bottleneck or is it managing you? And again, it comes all back to what you said at I, you, it has to start with visibility because if you can't see it, you can't manage it.

[00:45:09] Yeah.

[00:45:10] And you know, Carmen, this sounds. Mixed presentation at DevOps enterprise summit in Las Vegas. I think it was. CIO or CTO who took this to tech debt for a hat, something like that. And like, you know, if you, if you're looking at one thing and you think it's another, you can, and probably are making the wrong decision.

[00:45:29] And one of the aha moments for me when I was reading the, the book project product, and I was coming at this from, Hey, I'm an engineer. I'm working in the engineering department on building all this stuff. But for me, it was like, it wasn't a hot moment when. The principles that I had learned from like the dev ops handbook and thinking about just the value stream, insight engineering, it was a hot, I can take all of this.

[00:45:54] I can zoom out, put that whole structure on top of the whole organization, use the same sort of mental framework I have for thinking about my own little value stream and apply that globally across the whole organization. And then from that top down, like, as you said, looking at where the traffic gyms are.

[00:46:11] You could say, ah, actually here's the bottleneck. It doesn't matter if I go faster, if I'm still waiting on this other thing over here. And you know, your question that you mentioned is asking how we can go faster versus what's stopping us from going faster. This is always a problem in communication, right?

[00:46:29] Because if you ask these sort of leading questions, but it gets back to the theory of constraints and that if you're not addressing the bottleneck, then you're not actually doing anything. So. Actually framing, those types of questions is what are our bottlenecks what's inhibiting us or stopping us from moving faster are the better questions to ask, because then you can, if you have something like the full framework or your value stream mapped out, you can actually have some data for that to say, ah, yes, it's waiting here or this blocked up here as opposed to just making.

[00:47:00] You know, an unscientific hypothesis that, Hey, if we change this over here, like what we do, maybe we'll go faster. You know, it actually gets you focused on doing the right things, as opposed to just guessing about things. It really makes the whole process much more scientific, which I think should definitely excite some, you know, engineering minded, people like myself.

[00:47:22] Cause it takes a sort of nebulous concept, but actually really can make a concrete. Now, have you seen something like that before? Well, absolutely.

[00:47:30] I mean, you know, working at bell labs, you know, you kind of have, I mean, you know, Walter Shewhart started with bell labs. I think it's now 95 years ago. When bell app started and work with them, even when the whole concept of, you know, the plan do check act continuous improvement cycle and, and, you know, and you can talk about the Toyota and the

[00:47:51] Right. And it's gaining people into that level of thinking where. What is the data? What is your analysis? What is your day? Right. And then planning. I mean, what do you call them? Experiments, continuous improvement initiatives and, and Mick calls that. And a lot of people think of technical, Debra, really it's people process technology, but it could be anything that's an investment and making it go faster, it could be any of the dev ops practices.

[00:48:17] It could be refactoring, technical debt. It could be whatever it is, but then, you know, you want to run an experiment and experiment needs three things. You need to have a goal. You'd have an activity, but then you, most importantly, you need to wait to measure if it was successful or not. And sometimes people will do things and then argue if it worked well don't even, I coached teams don't even start.

[00:48:40] If you don't have a metric. Now, obviously the flow metrics, many times it could be the flow metric, but yeah, there are times you may run an experiment where, you know, you're, you're measuring it in a different way to see if it improves in any case it's going through. Plan do check, act loop, using data to drive you again in the check stage, you use the data and say, did it work?

[00:49:06] And then it's also doing, you know, which you alluded to, which is the systems thinking again, going back to Deming. So if a team, you know, the problem may be, I just described, maybe that's affecting other teams. Maybe it's a step. So now I can say, well, I can amplify the results of this, right? If we run this experiment, we don't have to change the whole organization.

[00:49:28] That can be a scary thing, right? If I go and say, well, we're going to do automated change approvals based on quality criteria that you know, the, I tell folks the change management folks, maybe I don't think so Caren, but if you say, look, we're going to run one experiment with one team, we put up guard rails.

[00:49:46] It's very controlled the businesses on board. And we'll treat us as experiment. Oh, it worked or this part of it worked or we can fine tune it. Now, is this a pattern we can take to the rest of the organization? Yes. And that's where then you're starting to apply. The data-driven continuous improvement, the systems thinking, and these stories then can drive the culture change in need to really make the difference in delivering business value more quickly.

[00:50:15] Yeah. Wow. I mean, listening to you and for the listener, they can see it, but I'm just nodding along because we start to pull on these threads and you look at it and you can keep going higher and higher up to, I think you have your article here, the age of. Value stream management and you described it as.

[00:50:34] Reaching the summit of data-driven and continuous improvement. And that if you can, you know, ladder up to all these things where you have the data, you have the feedback and you have the systems thinking though, you know, plan, check, act, do you know all this type of stuff? And you can say, Hey, how can I actually improve things in my organization?

[00:50:51] Not necessarily just like for myself and my team or whatever, but, you know, given a high enough place. And you are in the organization, you can say, how can I improve the whole thing and not just one small part of it. And, but now we're like right back to the beginning of, you know, where do you define your value streams and how do you think about that?

[00:51:08] But yeah, getting people at that level of thought, I think is the, is the challenge, but at least the, one of the goals here, you know?

[00:51:17] Yeah, exactly. And in a lot of times we'll coach teams is the fall, the dependencies, right? So start something. Okay. You know, we talk about VSM being kind of a compass on your journey.

[00:51:29] People will say, well, I'm not ready yet. Well, I think you always need accomplish, right? You're doing something you want to get better. You need to have a north star, right. North stars it's on around doing something. Yes, you can. All, there's a lot of great things to do. There's all dev ops handbook. They're safe.

[00:51:45] There's great things you can do. But your north star. Is accelerating the delivery and protection of business value. Well, you have to measure that you have to understand where to invest and then you have to, you know, take what you're learning from that and, and apply it across your organization. And you know, a lot of times we'll, we'll tell people just start small and then follow the dependencies, go where the data takes.

[00:52:09] You don't think you have to design this across your whole organization. You don't, you are going to learn so much just from doing this a few times. Then, you know, you can figure out how to adjust and adapt, and that can be very uncomfortable for leaders because they think they should already have the answer.

[00:52:27] Well, you can't have the answer until you actually run the experiments and get information. And then leadership can do that systems thinking to see, okay, how can I actually transform my organization based on that, I

[00:52:40] really liked that you brought up at here at the end about knowing the answers. I just finished reading the high velocity edge by Steven spear.

[00:52:48] And he mentioned that answers are known, they're discovered, right? You don't have that. You're not supposed to know them. That's the whole reason why you're doing this whole thing is you're trying to figure out the proper answers to these. By doing experiments and learning and figuring out you have to actually discover the best solution for your team, your business, your org.

[00:53:06] However you want to call that. So well, Carmen, it was my pleasure to speak to you and talk up to the summit of continuous improvement. Is there anything that you would like to leave the listeners with before we go?

[00:53:23] Sure. Well of course, you know I would love to talk more with feed people. If you want to visit tasktop.com, you can see what kind of badge do you manage.

[00:53:33] Services we provide and, you know, mixed book project, the product is obviously a great read. I also have a book with Jack Mar called standing on shoulders, a leader's guide to digital transformation, which has a lot of these concepts in Jack talks a lot about value stream mapping. We also talk about some of these concepts of value stream management in that book, so, and how to get started.

[00:53:57] So Adam, it's been great and. Thank you again. And I look forward to maybe having conversations with some of the listeners about how, you know, we could go on this journey together because I, I do think, yeah, it wasn't just kidding. I really do think this is quote, the age of VSM where companies are going to invest more in this capability to.

[00:54:21] To improve their business results. So...

[00:54:24] Well, Carmen, thank you so much for coming on the show and to listen to the links to his book and the full framework and everything will be listed on the show notes page at small batches dot RFM. And also since you listened to podcasts, there's also a podcast edition of his book.

[00:54:40] So you can get it in audio form and text. Well, thank you again, Carmen, for coming on the show and hope to talk to you again.

[00:54:47] Thanks Adam.

[00:54:49] So you've just finished another episode of small batches podcast on building a high performance software delivery organization. For more information, and to subscribe to this podcast, go to small batches dot FX.

[00:55:01] I hope to have you back again for the next episode. So until then, happy shipping,

[00:55:10] Like the sound of small batches? This episode was produced by pods worth media. That's pods worth.com.