Map your value stream: a live tutorial

Your program isn't short on effort. It's short on visibility. Everyone's working hard, every milestone is green, and the mission still isn't moving—that's the alignment trap, and the way out is continuous delivery.

Most GovTech leaders can't pinpoint where the critical constraints are because they aren't seeing the full picture.

That's what Value Stream Mapping gives you: a simple picture of how work really moves from request to production—every step, every wait, every handoff—so the delays hiding in plain sight become obvious. It's the fastest way to see where outcomes get stuck, and to put that problem in front of leadership in a single image.

In this Mission O/S Live, join Rise8's Product Management Enablement Lead Rob Monroe for a hands-on walkthrough. You'll learn some of the basics that help you get started with one of our powerful Mission O/S techniques—how to map your flow, read it, and pinpoint where work stalls—plus real examples of how we've used it.

Want to dive deeper? Rob Monroe and Steve Pereira are leading keynotes, fireside chats, and hands-on workshops at Prodacity, Rise8's three-day GovTech training event in Nashville, August 25–27.

Rob Monroe (00:30):

All right. Hey, welcome everybody. Happy Friday. I hope wherever you are dialing in from, you're having a really great day. And if not, hey, the weekend is ahead of us. So I'm really excited about this opportunity to get to talk to you today during Mission O/S Live about mapping your value stream and us taking a deep dive into a live tutorial. We're going to cover some basics. I know in a normal situation, we wouldn't move this quickly through this activity or these practices, but I think it's really helpful for us to just get some foundations in place and honestly, get some reps. Failing is learning. And if we can do something in a low cost, low fidelity way, that's always going to be better than us holding back and never trying in the first place. So I just want to, again, thank everyone for being here.

(01:15):

My name is Rob Monroe. I am a product management and transformation enablement lead here at Rise8. I've been with the company for just about four years and I've had an amazing time working with some of the best talent in gov tech, solving really gnarly problems. I got to start my journey here, gosh, in 22 where we were working with the Department of Veterans Affairs to achieve the first CATO and ongoing authorization in federal government history alongside castle run out of the Air Force. So I'm just really fortunate to have this opportunity to get to talk about a particular practice within Mission OS that I'm really passionate about as a fellow product manager. And I've been using this ever since my beginning days of my career back at Boeing, which is now over 10 years ago. So we're going to dive into this. I'm going to be sharing my screen and actually jumping into a Fig Jam board today.

(02:07):

I though that might be a little bit more fun than going through some slides. And yeah, just bear with me if it's a little jarring with the movement, but I'm going to do our best to have a really smooth transition through some of the topics and keep things moving along in this 30 to 45 minute segment. And if you have questions along the way, please submit them. We're going to do our best to try to answer them as they surface or at the tail end of this when we have time for that. I'd love to have some engagement if at all possible. So let's go ahead and dive on in. I am going to start from setting some just like basic principles and get some context around why this is so important to Mission OS inside of Rise Eight. And hopefully some of the things that we establish upfront are going to be really helpful to understanding how that actually shows up when we work with our customers, our stakeholders inside of our government environments.

(02:58):

So the objectives for today for mapping your value stream in a live tutorial, I'm hoping that by the end of this, you'll have a good understanding of how we've explained why current state value stream mapping is created, define the boundaries of a value stream, identify process blocks at the right elevation through which value flows or doesn't, and then trace both work and information through the system. That's going to be an interesting topic for most of us who deal with challenges when software doesn't do what we need it to do just to get our work done. And then of course, we want to build recognition where waiting, queuing, rework, handoffs, like where does waste show up? What does waste look like? How do you classify it? That's a really important topic that I think not many people actually spend enough time really digging into the specifics around identifying what types of waste are existing in our system, which can be really helpful for identifying the potential countermeasures or solutions that we address against those constraints.

(03:52):

And then of course we want to be able to take a stab at interpreting the map as evidence about system performance. So we'll talk about metrics. We'll take some steps back in looking at a case study that I'm going to bring from earlier this year where I facilitated a workshop with a customer from the Air Force. And we'll talk about some of the things that seem obvious on the surface and then some of the things that are nuanced and some of the things that are actually bigger problems or opportunities for constraints that we need to solve in order to unleash real value flow throughout the system. So with that in mind, let's go ahead and just get a couple of basics and some foundations in place. I'm going to drop in these nuggets of principles along the way. And I think hopefully it'll make it clear why that was the emphasis of the topic that we're covering.

(04:37):

So to kick things off, principle number one, first and foremost, we need to start with the mission and we need to work backwards from mission impact, not necessarily the processes that are going on within our daily lives or surrounding us. And why I think this is so important is because no matter what types of resources, activities or outputs that we spend gobs and gobs of hours and hours, I mean days, weeks, months, if you think about how long it can take to get through acquisition cycles, we need to understand that all the things on the left here, if I was to draw an imaginary line between the three on the left and the two on the right, everything up to this point is a means to an ultimate end. And that ultimate end is actually the mission impact that we're here to serve, whether it's serving civilians, operators or war fighters.

(05:23):

It's the actual results that we want to measure. These are the things that your senior leaders, your high ranking officials really actually care about understanding how funding is being utilized. Now, the gap between that, that I think most of us can oftentimes forget or maybe don't even know is we need to understand what is the outcome that's actually going to drive the actual mission impact. So we are doing the work, we are spending the resources, we are producing outputs, deliverables, right? That could be artifacts, it could be software, it could be a number of things so that we are actually able to drive human or system behavior. And that is what we actually define as an outcome to drive mission impact. So just to get some foundation of definitions under us, because it might come up again, and I don't want that to be jarring for anybody.

(06:17):

I think of outcomes and outputs in a very specific way and hopefully a very simple way. An outcome to me is a measurable change need of human or system behavior. You can think about that as direct or indirect actors or sometimes personas. Some of us in the audience might actually resonate more with those terms, but it's their behavior that drives or leads to a mission or business result. It's the thing that turns out when we inject something new into the world. The new thing could be software. It could be a new feature. It could be a security patch. It could be anything. Whereas the output is really just the stuff we build, the stuff we do and produce. Those are the features, the security patches, user documentation, whatever it is that's encompassing the work that we do to deliver something into the hands of operators, war fighters and civilians so that we can observe, again, how they behave with that and what changes with their behavior.

(07:17):

Couple more things here. Now we're going to actually kind of go from meta and get a little bit closer into what is actually the reason why we're here to talk about value stream mapping. Why value stream mapping and gov tech? I thought BSMs, albeit a part of the lean toolkit here, was really meant for manufacturing. It came from the Toyota production systems. All the things that Karen Martin and I had talked about in a previous Mission OS live stream event about a month or so ago. The thing is that operations in the government is actually ripe for an opportunity of understanding how do all of the things come together in order for us to achieve the mission, to improve the mission, to make it more efficient, more effective. And lo and behold, the actual work that we do behind the scenes to deliver software is a complicated system when you think about it, right?

(08:10):

From everything from acquisition to mission and operations and actually having software do what we needed to do. There's a lot of unknowns. There's a lot of things that can actually deviate from what we say is supposed to happen. And so this is a really great practice and activity that you can do to surface what is actually impeding our ability to achieve flow in delivering value to an intended customer. So with that, I want to now inject the next couple of principles. We want to always start by defining the mission thread from request to outcomes. And I say request to receipt here and the visual, just because it's a little bit easier for most of us to maybe go to some abstracted examples in our daily lives. We're used to that as consumers. We understand submitting a request or submitting an order and receiving some kind of good or service at the tail end of that.

(09:03):

But the reason for talking about this with a visual like using silos is principle number three. We want to follow the work, not the org chart. The intended purpose here is not for us to understand what's happening within our own sphere of control. We actually need to understand how value, how the thing that a customer needs depends upon is actually getting into their hands and affecting their life. And that just instantly means that we have to move outside with the broaden our thinking, our mindsets away from maybe how well we are working inside of our own individual departments and functions and think more broadly about this in order to optimize for flow. Now, sometimes this is actually a really great way to start to break apart our thinking, our framing around what is value stream mapping intended for versus maybe process mapping. We'll get a little bit more into the details of some examples of those as well.

(09:59):

But here at what I would consider like a 10,000, 30,000 foot view of the world, what we're really trying to understand is where does value actually break down? Where does flow stall? What could be potentially creating flow in terms of a constraint? I don't have to understand the details of what's going on when I need to have a strategic alignment across areas that I do not have span of control over and I'm trying to build consensus and influence for. We all want to raise the level of context up so that we can see where the problems are and then deploy the best talent we possibly have to solve those problems. And we can give them very clear objectives about the problem areas that are happening to the best of our knowledge and ability. Then we give our deployed units an easier time to actually focus in on what truly matters.

(10:51):

They understand the bigger picture. And so this is another opportunity to say value stream thinking is less about component efficiency. If I'm really down in the weeds of understanding how I do my work and how I handle my processes to the left and right of me, if I solve for that and I make that really effective, really efficient, well, that might be all well and good, but perhaps that doesn't solve the traffic problem. We really have to actually elevate ourselves to the system level efficiency to make sure that we're making the right bets and so that we're not operating in our silos causing other problems elsewhere. Or at least not understanding that we intentionally did that to see if we got some type of reaction from the system. So a couple more things to just kind of fill a little bit of context, fill a little bit of definition.

(11:39):

I've been really harping on mission impact and mission in terms of operations for civilians, war fighters, operators. I want to also just help everyone who maybe doesn't sit that close to your ultimate customer or your user community in that sense of real mission operations. Your software delivery value stream, something like a talent acquisition and hiring value stream, I would consider those to be enabling value streams. You still have suppliers, you still have people who need things. You still have a customer who needs things in terms of receiving the value from this. And so for anyone that's out here working in software acquisition or on a delivery team or a product delivery team, you have a value stream. You have customers, you have suppliers, and you have to understand how value flows in order for us to actually deliver software into fraud in a more effective and efficient way so that we can respond more quickly to what the mission needs are.

(12:39):

This is why we harp so much at Rizate on the ability to achieve continuous delivery and continuous authority to operate. So that's going to be actually the basis for where we're going to mostly focus our examples and tutorials around, primarily because I want to just beat the drum on why it's so important that we establish those capabilities and figure out how to help deliver better value to our intended users. So just some quick guidelines because many of us don't come from value stream mapping as a technique. Most of us probably come from things like process mapping. And that could come in the format of DDD, event storming, user journey mapping, service blueprinting, customer journey maps. There's a number of different tools in the world and they have their place in this world for what problem you're trying to solve and what you're trying to communicate.

(13:28):

The thing that I would help maybe offer here is some guidelines as to like, "Hey, when would I want to pull this out of my tool belt?" Is these three factors. So total lead time. We're really talking about, again, the things that have to be influenced at a very high strategic level that often take weeks to months, not things that we're controlling within our direct span of control that we probably equate to things that happen between minutes and days on average. The number of handoffs at a high level, there's a high level of involvement. It's not just my product team and the way that we think about our software development life cycle in our agile practices. We're really talking about getting outside of just product and engineering, talking to security, talking to privacy, talking to our acquisitions team, talking to our GRC and compliance teams, like the full gamut of what it takes to deliver the thing that is ultimately of value to our end customer.

(14:22):

And then the decision making authority, I kind of have already hinted at this before, but we're really talking about areas where we don't have the direct span of control. We have to influence up and out in order to get leadership to buy in that when we want to make this systemic change for our value stream, we need their involvement, we need their buy-in, and they have to be able to deploy the resources and the needs for us to go solve those problems. Whereas with process mapping, it's generally going to be held by those who are closest to or doing the actual work. It's where we've probably also standardized the work. And so we're trying to adjust the way that we are managing the work that we do today. So hopefully just a couple of guidelines because these are going to be popping up as generally questions that typically come up when I walk through the practice of value stream mapping.

(15:11):

And I'll try to, if I don't see any questions coming through, I'm going to also just pause myself and say, this is what I typically hear for a question when we get to this point. So there's a lot going on in terms of the number of objects and icons in this legend. It's not important that you memorize this. It's actually more important that we just take this step by step and you understand some of the basics and fundamentals so that you can feel confident that when you start trying to apply this in your context, it becomes a lot easier for you to reuse. So I mentioned that we're always trying to start from defining what is the mission that we're going after, right? What mission or business imperatives are we focusing on for this improvement cycle? What is the existing KPIs or improvement goals that we're focusing on for this improvement cycle?

(15:57):

And today what we're going to kind of walk through, because it's going to play into the case study that I'll cover at the end, is a software delivery value stream, current state for a funded program with an existing system. They already have a path to prod, but they don't have a continuous authority to operate. They're still operating in some capacity of what I would say is traditional practices and traditional approaches to delivering capabilities to the operator. So here, I'm going to actually inject the next set of principles, which is we want to map what actually happens. And if we unfortunately sometimes use this opportunity to sanitize and make things look better than what they really are under the hood, you're guaranteed to improve the wrong system because we're not actually working from the actual context of the current state. And so we might miss those opportunities of identifying what key constraints are keeping us back.

(16:50):

And then of course, mapping at the altitude where value flows. This is often an art more than a science, but that's why I tried to provide some of these guidelines along the way. And I'll kind of talk through some examples of those as we start to unfold this picture in front of us. So we want to understand where does the need start? What is the start to the story? What is the end to the story? Who is the ultimate supplier or who is the ultimate initiator into this value stream? And who is the end result? Who's receiving the end result? Who's the recipient of this? And so if we were outside of our context working in software delivery and we went to something like I'm ordering coffee or I'm buying a pizza, in today's world, you very well are likely the person who is initiating and receiving the good or the service at the end.

(17:42):

But in our context, what often probably happens more times than not is that we have some high ranking officials. We have high ranking stakeholders. We have a user community, sometimes user community proxy. And some of us are not fortunate enough to engage directly with our actual customers or user communities. Or sometimes there's external mandates. We have to meet certain policies that come in from different regulations and et cetera. And there are, what are the inputs that are provided? What is required from the initiators that actually kicks this thing off? And so for the most part, I think most of us would probably agree that, hey, this is generally formatted in some form of desired output and maybe operations context. Even those capability need statements, I think most of the time what we see in acquisition and contracts is that they're stated in an output based language or format.

(18:41):

And again, I kind of want to know who is going to be the ultimate end recipient. Who's the customer of this that's receiving the product or the service or good? And what are they actually receiving? How do I know that we can end this value stream at that point? And so in this context, which might be probably similar to most of everyone who's on the call, we're just going to go with mission operators. We could and should be more specific here if we were actually talking about a unique program instead of context, but for this basic tutorial, that's what we're going to go with. And what are we typically sending them? I kind of already mentioned this in some of those brief slides I showed. It could be a new feature. We could be optimizing existing functionality. It could be a security patch, et cetera.

(19:25):

But we can be extremely specific here depending upon what is the context of our value stream. And we have already just now established the fact that, hey, we now know that this is really going to be a process in which we're going to receive information. Information is going to be either pulled or pushed from our mission operators through our high ranking stakeholders, community proxies, et cetera. And so here we go. Now we're actually going to start talking about what is the initial process block, this process step that is going to unfold. So our first pass through the value stream, now that we've understood who we're actually working with and what they care about in terms of value is to actually start naming the first initial process block. And I'm going to approach this with an understanding or an assumption here that we're working in a program, I already mentioned the context above, but working in a program that has adopted scaled agile framework.

(20:34):

And so whether or not this matches exactly how you do this in the real world, I think that in principle, we're probably going to notice some patterns and things that feel very similar to what you all experience in your life if you are in a product delivery team or in a program that delivers software to operators. So if I was to just start filling this out, the intended purpose here is for me and a handful of other individuals working in a room to basically identify what is the activity? What's the process block in an action verb noun phrasing format? And the reason for this is we don't really need to get into the details of explaining what's going on. And honestly, if we can't explain it in a brief label or title, we might need to spend some time understanding whether or not we're operating at the right level.

(21:21):

That's just one example here where things could be going. Might need some refinement. So we're going to capture capability need. Maybe that sounds familiar for anyone who's heard of capability need statements or if that's typical language for you. And hey, in our world, our context, that's usually done by a portfolio team or portfolio leads.

(21:46):

Ignore this barriers to flow context that is also included here because we'll capture that later when we actually understand what's really going on with the entire system as a whole. And we know within our context that, hey, this is usually a team of three that is doing this. You could even argue that, hey, there's actually a fourth person that's involved, which would be the actual proxy or stakeholder that gets pulled into the conversations. So the whole point of this is just for us to name the activity in a very succinct way that generally everyone in the room can understand at a high level what's really going on, who might be involved. And then we would get into some details about what is the type of input, what type of work goes on inside of this process block at a high level and what does done look like?

(22:32):

What does the output look like that feeds into the next activity? And so we would repeat that. So maybe there's another step here specifically around evaluating alignment. Because hey, we have a lot of requests and demand all the time, but never enough resources. So we need to evaluate and we need to align on whether or not this is the most important thing for us to try to be solving at this time based upon those resource constraints. And this might actually be handled by a portfolio management team.

(23:08):

What I mean by this is maybe this is actually someone who handles the financials or who handles or is accountable for a different type of decision other than the original portfolio team I mentioned off to the left here. And so this is like the first opportunity for us to have a conversation about, hey, are we at the right elevation here in what we're talking about in terms of steps that need to be done? And so what I would say is what we are looking for in terms of how do I know when to actually create the next process block and define the boundaries of this supplier customer relationship is where is there a break in the timeline?

(23:54):

A break in the timeline. What I mean by this is where do we actually see that something is completed and it is ready and passed to the next group to be addressed or to add on to the work that needs to be done to ultimately deliver value to the intended customer? So where is there a handoff? Where does work stop? Because it has to go to someone else's queue or be received in some fashion by another group, another entity. So that's a really clear indication that that might be the right level that we want to or the right elevation where we want to establish the next activity and the owner of that activity. Sometimes what we'll see in value stream mapping is a series of activity steps like received or reviewed and approved. And if you notice that the same function or the same department is running those processes, you can oftentimes should, I would say, elevate that to just one activity block with one owner and the process of reviewing and approving and et cetera is all handled within one.

(24:58):

That's a gut check for like, "Hey, am I operating at the right elevation or not?" And so again, we would repeat this conversation of understanding at a high level what is going on. Generally speaking, how many individuals are involved with this. And the next thing that we can do is start to continue the conversation from here on what's the next break in the timeline. What is the next activity? Who's the next owner? And the whole point of this is to make sure that we have a shared understanding of how this actually works, that we have shared understanding of language, shared understanding of the processes that are going on. And oftentimes the messiness that happens in the middle is actually what's most valuable. Gaining that clarity first is actually going to be super critical for our ability to actually create the entire map and have really rich dialogue around identifying constraints and making critical strategic decisions.

(25:56):

And so in this shaping of Epic's step is predominantly done by product managers. And we only really have to have one product manager take care of that. Now I'm not going to bore everybody and watch paint dry and have Rob build this entire thing out, but I'm actually just going to skip forward over here and articulate that, hey, again, I would not be doing this in a vacuum by myself, but with a team of about 10 people we've built out now the critical steps, knowing exactly where work takes a break, where there's a break in the timeline and hands off to the next activity and activity owner. And we've got that well established storyline so far all the way out to deploying this capability and to mission operators. And so again, it's not about what's just happening inside of my silo or my span of control, my span of influence.

(26:47):

I'm actually looking across what are all the different entities, processes, tools that have to be used in order for us to deliver legit software to the hands of the operator. And so after that first pass, we now move into understanding what information systems are being used. We actually really want to understand and follow both the work and the information because what this starts to reveal sometimes is redundancy. Sometimes we have multiple systems that are feeding information to us or that we're pushing information out toward. And so there's really great conversations around why we do or don't have access to information or where we might be in a given activity block waiting for someone to approve our access to said information that was generated upstream. And so the whole intended purpose here, it gets a little messy. It's why I'm not going to build it out in real time.

(27:40):

But the intended purpose here is for us to understand how information systems are used and how data is or is not helping us in our journey of moving work, moving the unit of value towards our customer. So I'm going to take the next opportunity to kind of speed up the process just to show you, this is probably really clean compared to the case study we're about to see, but this probably wouldn't surprise us either. Capability needs statements being captured in some requirements, backlog requirement system, evaluating the alignment. Maybe we do some really cool prioritization practice inside of Excel because we like to create formulas. But the shaping of an Epic, understanding what controls are going to be necessary. We try to understand where these systems are being used in the process and where they're aiding us or not aiding us. And I've probably easily left out some connections between the systems involved in this hypothetical, but albeit I'm sure very relatable value stream for most folks who deliver software in the government.

(28:47):

But you can see some interesting things that are surfacing. We can see how certain systems that we would maybe expect to be integrated are not. We know that Jira and Confluence, as an example, comes from the Atlassian tool suite. And so they come with built in native integrations. And so that's not surprising. But hey, we have backlog systems and our controls systems not talking to each other. We have Figma hanging out here on its own that's only really being used late in the game by our designers to take all this context and take all these requirements and outputs from upstream parties to try to generate a thing that they've been told is what the users want, even though they're not actually engaging with users. We've got GitHub involved obviously from a changing configuration management system for our software, our builds, our automated test suites, promotions from lower to higher environments.

(29:48):

We understand that approval of our release, we have a really nifty automated GitHub action that's going to handle the release function here as well as Argo CD. I Again, the whole point of this is to try to understand how these systems are or are not enabling flow. A lot of times some of the queuing and some of the drag that we start to see inside of a value stream can be contributed to how we are or are not utilizing systems to their fullest potential or where we might be exacerbating problems by having too many redundant systems. So we might see that here in a second. I'm going to press forward into what would be the third phase or the third pass. Now that we understand how work and information flows through the system, we can now start to have conversations with those groups of individuals on how we would understand performance of this value stream.

(30:45):

So I'll make a couple of comments here before we start building this out. But another principle I want to inject into the conversation really quickly is many of us have probably heard this, but don't let perfect be the enemy of good enough. I'm going to say good enough because what I find very interesting and very hard for some individuals when we do value stream mapping is they quickly realize like, well, hey, we don't have precise or programmatic ways of measuring how this stuff works, or maybe we do in certain sections, but not all. And the thing that I want to offer here is that by and large, in a room full of 10 individuals, if you can generally agree or directionally agree to the statements made about processing time, lead time, and these really fundamental set of metrics that help us understand value flow, you're probably directionally correct enough to understand where the problems are.

(31:37):

And then there's decisions that can be made whether or not it's a meaningful investment to actually generate more precise or programmatic data. You can always take a side quest and go do that, do some research, pull some data, do some analysis or build it into your systems. That's a decision that can be made. But I just want to make sure that this is really well known that we do have opportunities to make really important strategic decisions, even if we don't have perfect data or perfect metrics in front of us. And I'm going to show you exactly how that happened with the case study. But before we actually start creating examples of what this performance looks like in this hypothetical software delivery value stream, let's make sure that we all are on the same page of what we mean by some of these metrics. And there are other metrics that you can include and your context may prompt you to want to include other metrics that are important to your value stream.

(32:32):

You certainly can do that. I would just argue that you don't have to have all of those metrics that gets kind of into this like don't let perfect be the enemy of good here. You can start with just these three fundamental basics and get very, very far in how you want to identify opportunities that strategically matter to improving your value stream. And so in this third pass with process time versus lead time, the key thing I really just want to point out here is actually the screen sticky. Processing time is calculated when we are touching, talking or thinking about the work as it's come in. And lead time is really just the total time between work received into my activity block versus when that work is passed to the next process, the next activity block, next department function. So most of us will probably very quickly understand that process time is usually often shorter than lead time.

(33:22):

And anytime that we can get those to come out to an activity ratio of one, you've pretty much optimize that system for or that activity to the fullest potential it possibly can be. And we'll see what that looks like or why that matters here in a second. The third metric that is showing up here is what I would call is percentage complete and accurate or percent CNA. And so I've mentioned a couple of times, we talk about these relationships or these activity blocks or process blocks as a customer and supplier relationship. And the reason for that is you actually don't assign your own complete inaccurate percentage here because, well, we're probably all a little bit biased in the work that we generate. So it's really actually your customer, the downstream activity owner or process owner providing feedback to you on what your percent CNA is.

(34:14):

And so in this case, what we're saying is that 20% of the time, process block two has to do some type of rework or correction or sends it back to process or activity owner one to redo the work essentially. So this becomes really, really important because nothing kills flow more than quality of work or understanding that the processes that are within that activity are taking up a lot of time. And so sometimes we can accept a little bit lower quality. I want to use that phrase I just mentioned or that statement I just made very loosely here in that we always want to try to improve quality because quality is the ultimate contributor towards flow here. And you will see that here with our case study example. And so in this hypothetical, again, we have mentioned value stream mapping is really beneficial for when we're talking at that high level strategic view of the world across departments functions.

(35:13):

And we know that these things often take a lot more time and they take a lot more time, energy and resource potentially to try to affect or change the value stream and how it behaves as well. But in this example, maybe it's one day of processing time and the lead time is somewhere in the order of eight days. And in the conversations that we're having, we might be asking ourselves, what really is the contributor for the extra seven days of lead time? And it could be because, well, the information has to be collected, dropped into a system. And then, oh, we actually don't look at that for a week because we have a standing meeting where we look at that. And so we have to account for the amount of time that it takes for when the work shows up to when the work leaves.

(35:57):

So it's not any fault of the humans involved. It's just the way that we've designed the work system at that point. But we need a day to actually pull that up, digest it, maybe refine it or have a follow up conversation and then it might be good to go. But what we have learned is that, hey, roughly 35% of the time, we're having to go back and actually get clarity. So in this case, the scenario might be I have a form where individuals are supplying capability needs and whatever context they have on hand. And what we're finding is that a lot of individuals are not filling that form out to the best quality or enough clarity that really helps us understand where this problem is even coming from. And so, hey, 35% of the time we have to go back and make some type of modification, gain some clarity, et cetera.

(36:48):

And so we would do that same conversation similar to how we were filling out the activity blocks. We just go down the line here, trying to understand at least relatively or directionally, how much process time versus lead time does each of these activities take and ideally get into some really good dialogue around how often work is being passed back or corrected or what have you. And that's really what's interesting about working in operations or what's interesting in working in organizations that are responsible for delivering software is so many nuances happen in between these process blocks. We have standard operating procedures, but let's be honest, we make exceptions. Sometimes you're making an exception because you have a relationship with somebody and you know it will take so much more time to throw this back and wait for it to come back until you make the correction yourself.

(37:41):

But the fact is anytime that you're actually having to pause and even think about doing that and affecting the change of the work that's been handed to you, that means that quality wasn't where it needed to be nonetheless. So just wanted to make it really clear kind of how that percent CNA comes about. And now we're going to move over to what is essentially this completed, albeit probably overly perfect current state map that has all of our activity blocks, owners, the actual time and quality metrics baked in. And we're able to actually do some totaling here. And so for our ability to ship a new capability to fraud, we know that it takes on average 44 days of processing time, actual hands-on, doing thinking, touching, et cetera. The lead time is pretty crazy. 238 days. Wow, that's shocking. But now we know. And we could laugh at that and we could say that's abysmal.

(38:46):

We could be upset about it. We can have whatever reaction you want to have to it, but now we know. And even if there were opportunities where we have made some assumptions, we can make some decisions on trying to chase down those assumptions and validate whether or not they were accurate. And then the rolling CNA here, I just want to point out that the way that you would calculate this, and that is pretty low, is to multiply the percentages of CNA across each of those activity blocks. I've gone about creating a value stream map that is very simplified in terms of a single straight shot. I don't get into the more complicated topics of branching and parallelized work. And then how does that affect the way that you measure or calculate these performance metrics? But I will mention them. You'll see how that played out here with the case study.

(39:36):

And then the activity ratio is really important. This is saying essentially that what, 82% of the time work is sitting idle somewhere.

(39:50):

That's pretty crazy. But I think actually when you do this type of practice and you get this out there on the table, it would probably surprise you how often that activity ratio is pretty low, to be quite honest. I think a lot of these things actually surprise people when they see it for the first time and it can open up some really good dialogue. Now that we understand, we've taken a step back on this current state map, we can really start to dive into the conversation of where have we identified different types of waste in the system? And there's a number of examples. Almost every single one of these is something that could easily show up on this current state map. And that's the reason why I didn't want to do it is because I though it would be a little too intense and take up a little too much time.

(40:35):

But this is an opportunity to say that there are eight different forms of waste that can show up inside of a system. And knowing what they are, how to recognize them and where they're happening is really, really critical for not only being able to say what type of waste we're dealing with, but also helping with guiding our decision making on how we might want to solve for that. Okay. I am seeing that there are no questions yet surfaced off to the chat over here. So I am going to pop down and kind of start to round out the conversation with the case study. And I'm going to introduce one more principle here, which is choose learning over looking right. That might have been obvious when we were going through the tutorial that this is about learning. This about clarity and visualizing things and understanding them before we try to improve them.

(41:28):

But I want to talk about this principle in a different way. I think oftentimes when we have an elevated view of the world for the value stream that we are trying to affect, it can be really, really easy for members of different organizations to have opinions about where the problems already are. And they already know that the issue has to do with so-and-so who's not pulling their weight inside of engineering or within products. And you can kind of sometimes get the sense that there might be some blaming or turf warring going on inside of organizations when you do this activity. And I would just say this is actually, I call it principle aid, but it's something I would want to introduce very early in the conversation with a mapping team who's going to go through this, is that we're really not here to place blame.

(42:20):

We're really here to raise a level of context and clarity across everyone that's involved so that we make the right decisions and that we're confident in those decisions, especially with it means that we might need to pull resources from other locations in the organization. And so in this particular situation, we did have a member of this team believe that they knew where the problem was and that it was on the engineering development side of the house. But I want to take you through this case study. It's a pretty complex map. We don't need to know the exact level of details here, but what I want to kind of point out is some similarities to what we pointed that we saw in our tutorial just a second ago. We have field operators who are funneling in information to our ultimate customer. The actual field operators, or I'm sorry, the actual field maintenance teams within Air Force that are trying to identify capability needs for the software platform that's being developed and so that they can help prioritize that, shape it and meet the needs of the actual field operators with the software that we're going to ship.

(43:29):

The interesting thing here that you'll probably note in terms of some similarities is like, hey, we have quite a few systems that we probably would maybe assume would be integrated. There are some that are actually fairly well integrated and set up for a good information flow in terms of how we're leveraging GitLab with Bigma, Lucid. We've got some duplications of things and we'll come back to that here in a second.

(43:52):

We have a number of steps. If you notice that our capabilities needs being captured, we're submitting requests, we're approving them, we're prioritizing them, we're refining them, we're decomposing them. This is another program who has adopted the practices of Scaled Agile framework. They have set up a series of working design systems to be able to funnel in information, utilize a high degree number of individuals to help try to break down, synthesize and get that context into something that can be executable. And so the pattern here that you're seeing is that the customer is actually directly involved in the actual process of delivering software, which may or may not be similar to other organizations, but we actually, quick pause from the story. We brought the customer into the room to work with us on this because we learned that they had direct involvement in the actual process of delivering software.

(44:54):

You may or may not choose to do that because you want to be able to have a consistent conversation without any type of repercussions to the realities of how things work. But I think when your customer is directly involved, there is an opportunity to help them understand how their role, their work, their quality of work is actually helping or hurting flow of value throughout the system. And like I said, I'm not going to go into extreme detail of what goes on in these steps. I will point out that this is an example of where we would have branching where there is 80% of the time work that needs to go through a more rigid security risk assessment process versus 20% of the time where we're making maybe just like system optimization changes, low level risk changes. And that's the agreement and that's the way that the work design system works over here in this organization.

(45:47):

And so you'll see a couple of those situations where we have branching or we have parallelized work going on. And again, it's not about what's actually happening on this map. It's actually the things that are going on in between the map. And I want to come back to that after I point out the actual end result here. So when we actually mapped this all out and got agreement on where we were, we saw that there was a process time of 119 days, lead time of 233 days, and a rolling CNA of 0%. And we also realized that the activity ratio is actually not terribly bad in this situation. So the real question that we had surfaced in two different areas. Why are we having such low quality in terms of the work that's flowing through this system? What is causing the red line kickbacks or pushbacks to upstream activity blocks?

(46:41):

And why is that happening even though we have so much rigor in terms of what's happening with capabilities being captured, refined, groomed, et cetera? So we took a look at this because ultimately everything comes back to this one particular space where we have a large amount of queuing going on. And despite the amount of time that's invested here to refine the requirements, to make sure we're clear on what the outputs are, to make sure that we understand what the operator's needs are, the fact is that that context is passing through a number of activity block owners and a number of hands before it actually ends up with the team that needs to do the work. And they're a bit shielded from actually engaging directly with the user community and the stakeholders themselves. And so by the time that we're finally working through all of these tickets and the context that's coming at us, we find out really late in the game when we're doing UAT with the customer that, hey, we're actually not addressing the actual needs in a way that's going to be meaningfully applicable to what our customer has asked for.

(47:51):

So that was the first thing is that even though we've built all this rigor and even though that we've probably built up these activity steps because of past pain, more planning isn't getting us to where we need to be. And that's because the work design, the system that we've put in place isn't allowing for us to continuously learn in a way that makes us efficient and effective. On top of that, you have systems that monitor or manage the life cycle of the work that's going on. And so these systems, because they're not integrated, we're now duplicating context that becomes stale as the lead time grows. And so the context that we're referring to can oftentimes change without us knowing or becomes just stale context because by the time we get to addressing this problem 30, 60, 90 days from now, that problem and the realities of that problem have changed for our operators.

(48:43):

So honestly, I think that's a very typical challenge that most programs, most government teams face in the way that we have work design here. And so I think that that's a really important thing to take away is that there is an opportunity for us to achieve continuous delivery. And by doing so, getting that capability in place allows us and affords us the opportunity to deliver higher impact, more mission impact at higher rates, and obviously then gives us the ability to learn faster when we get to prod. And the last thing that I'm going to mention here is that this program didn't have too bad of a design system in terms of how they partnered with external groups like security and their deployment services. They had reasonable lead time asks. They had reasonable turnaround times. Yes, we want those to be shorter. Yes, we have patterns for how we make that faster, more effective.

(49:39):

We embed those individuals inside of teams, but it wasn't the biggest pain. The biggest pain was this assumption that we could define and refine to the nth degree what we wanted to have built and that it would live through this delivery system, through this value stream all the way to the end. And the final aha moment that actually surfaced in the room without us having to get into the details of convincing the customer that this was an issue was that their motivation was to deliver this capability to Prad as quickly as possible and then deal with what was the ramifications of anything that was missed through support processes. So day two operations was the way that we would understand whether or not our software worked. I think there's a huge opportunity for most organizations to think about capability need statements and think about value streams in the way of delivering software to a production environment by starting from what is the outcome we want to achieve?

(50:41):

What is the impact that we believe is going to be generated if that change in behavior occurs? And that then actually is really critical for teams to start thinking about, well, how would I validate this? How would I measure this? How would I know that that is an actual behavior change that has occurred? And we could then have a better design working system for how we want to communicate what's coming to our user community, how we precisely validate that that is or isn't happening either explicitly or implicitly. And we use that feedback loop as a way to speed up the process of figuring out what's the next problem to solve. There's a lot of really great opportunities that came from this two-day conversation. And I think maybe this does or doesn't surprise folks on the call today. Maybe the world or organization or working system that you work in is more painful, less painful.

(51:37):

I just want to point out that this is very similar to the tutorial I gave. This is an existing system with an existing path to prod with funding. And so if you can imagine a world where we're actually trying to launch a brand new system that requires new funding, that requires a path to prod to be confirmed, this idea of an extended value stream all the way out to how acquisition actually affects this, it starts to really break our minds a little bit. I think the stat I normally hear on average acquisition time is around 18 months. So to think about a new system being developed probably takes far longer than what this working design system demonstrates with an existing one and existing path to prod, but then tack on acquisition time. And I think we now see that there's a clear problem, a clear opportunity for us to do something different in government.

(52:29):

I just wanted to highlight that. I know that we're pretty far over time, but I'm going to go ahead and kind of hammer through a couple of things here. So when we had the opportunity to identify where the waste was identified, what those constraints were inside of the system, we have an opportunity to turn that into what is the desired outcome? What is the desired or ideal behavior in that target state that we're aiming for? And so if you notice between, I know it's a little hard to read the FigJam sticky notes versus the one off to the right here, but if you recognize what's going on, we're not actually depicting the output. We're not actually depicting the thing that needs to be built. We're actually identifying what is the change in behavior? What is the outcome we want at a very high level, a systematic level for this value stream?

(53:19):

And how would we be able to measure in the format of key results or some other format of metrics, whether or not we've achieved that with the things that we're about to introduce into this target state? And so a thing that I want to articulate here for anyone who is on the call that might be from more of an acquisition background or acquisitions team and somebody who might be like a mission owner is that you have a really great opportunity here to shape the way that your current incumbent or a new contractor coming in can solve problems for you and can really prove whether or not they are the right team to deliver on that by articulating what is the actual impact we want to achieve as well as the change in behaviors. And even though I don't know how that system really behaves at a low level, we talked about process maps and other techniques where we can really get into root cause analysis.

(54:10):

I actually have articulated exactly how I want to measure success in an objectified way and full of assumptions around how that system actually behaves today so that when teams start to make those decisions and lean into a target state and run experiments, then we actually can tell whether or not those bets are working and panned out. And we can have the conversation then at that point whether or not the desired solution was the right one to begin with. And so I'll leave you here not walking through what the target state ended up looking like or which of these opportunities or Kaizen bursts were identified for the first round of experiments. But I will say that the conversations led to what we believed would be a reality change for us in this value stream if we could achieve the target state the way that we were thinking about it.

(55:00):

And so really great performance improvement opportunities came from this conversation. And it was a relatively small team and a relatively small amount of time compared to the life cycle of traditional acquisition and getting this wrong at the tail end. But yeah, I'm going to flip from Big Jam and take a look to see if there's any questions. I know we went a little bit long today, but I hope it was valuable. And the last thing I'll say is if you found this valuable, if you want to go deeper, if you really want to get your hands dirty with this, we do plan on doing several different type of mapping activities or mapping workshops at Predacity 2026 this year, the week of August 24th during our workshops series. It's on Thursday, August 27th in Nashville. So I hope to see a lot of you there and we can talk more about the details of what really happened in this case study as well as getting your hands dirty with these techniques as well.

(55:58):

Hope to see you there. And I'll take a look now to see if there's any questions that have surfaced. Okay. I'm not seeing any questions. I'm a little bummed by that, but I know it's Friday and I'm holding everyone up from having an awesome weekend. So I thank you again for your time and look forward to the next one. Take care.

‍