Quantifying the Opportunity – Value Stream Mapping for Agile Organizations

Marcus Grimm:
Thank you so much for joining us for today’s program, which is Value Stream Mapping for Agile Organizations. My name is Marcus Grimm with Ascendle.

I am thrilled to have all of you on this program. This has been a super fun one for the team to work on. Many of you have attended previous webinars from Ascendle. As always, we’re running a live Q&A here.

And if you miss anything in today’s presentation, we will email you a link to this webinar recording, along with a slide deck, as well as a copy of a template that we’re going to be discussing with you today.

I do want to take just a minute to introduce you to Ascendle. For those of you that don’t know, Ascendle is a leader in custom software development. We partner with companies as their full-service development team to create mobile and web applications to drive their business goals. We offer web app and platform development, along with product strategy and product design. And we are fortunate to do this with some of the world’s top brands. So we’re super thrilled to be working with those brands, many of whom are on the call today.

Let’s take a look at this agenda here. We’re going to be talking about some introductions today. Make sure you’re aware of who these experts are on the call.

We’ll be talking about the purpose why in the world do you even do value stream mapping? And how do agile organizations work with value stream marketing, in particular, in context with Scrum, which many of you are absolutely familiar with as well. Then we’ll get into the nitty-gritty of it. How do we actually build a value stream? How do we analyze a value stream? How do we optimize a value stream? And finally, at the end of all that, it’s questions and answers. And that last question came in, will a recording be shared? Absolutely. If you missed that one, you’ll get the slides, you’ll get the recording. And you know what? We’ll also give you the template that the Essential team uses when they do value stream mapping is all there is a lot to pack into this program. We only have about an hour. So I really hope you have all hacked a lunch pail for this one.

If we take a look at this on our panel here. Leading off this panel, a lot of you know her. Susannah Parnin-Mitchell, she’s a product lead here for Ascendle. At Ascendle, she works with clients to strategize, evaluate, align, and manage complex software builds via the proven agile process.

All right, let’s take a look at who else is on this panel. Hey, unless you came to our last webinar, you don’t know this guy. Matt Studley joined Assemble last year as a ScrumMaster. On LinkedIn, he refers to himself as a team multiplier that hones a mix of technical and leadership skills to bring out the best in people organizations.

We came out of our last webinar and we talked about how to do agile assessments on your team, but it was very focused in on that actual Scrum process. And coming out of our last webinar, I said to Matt, “Hey, Matt, we’re doing all this, right? Does that mean we’re hitting on all cylinders? We’re shipping software as fast as possible?” And he said “No, because if we want to be truly agile organizations, we need to look beyond Scrum to optimize our business”. So here’s a simple question, Matt. Why is that the case?

Matt Studley:
When you have the Scrum framework implemented into your development teams, your development team is only a small portion of your business, right? So there’s activities that happen before it gets to your development team and after it gets to your development team. If the middle of your process is fast using Scrum, but the beginning and end are slow, the net result is that you’re still going to be slow. Or slower than you want to be. So if we want to be truly agile and get the quality that was promised. What we’d like to do is look at the entire flow of work from start to finish.

Marcus Grimm:
That’s a great answer. So we’ll be talking about a lot of things today that are outside of Scrum, which is super exciting. Now, Susannah, when we talk about value stream mapping or Scrum or any process improvements, we always tend to focus on different things. Different gotchas that we’re looking for in the organization. Talk to me about what we’re looking for when we do any types of assessments like this.

Susannah Parnin-Matchell:
We’re always on the lookout for the seven primary types of waste. When we’re talking about Scrum, as you were mentioning, we tend to focus really hard on things like extra features or partial work. Both of those types of wastes are things that disciplined agile teams are just constantly on the lookout for. But for value stream mapping, we’re actually zeroing in on two other types of waste, namely wait time prior to starting work, and then any failures that might send us back a step or send us back multiple steps.

Marcus Grimm:
Now, before we move on here, Susannah, let’s talk about wait time a little bit, because it is a word that has a negative connotation. Is all wait bad, Susannah?

Susannah Parnin-Matchell:
That’s a really good point. No, not all wait is bad. Sometimes wait time is just an expected part or a purposeful part of a process. You might be bundling multiple things before tackling it, or you might be wanting to protect a certain amount of time before you get to something again. This can all be valid in your various processes. I have an example a little later on that I can point out one instance of this, but the point here that I think we’re trying to make is that wait time in isolation is not inherently bad. But coupled with some of the other gotcha’s that we’ll be looking out for, it can be an indicator of problems.

Marcus Grimm:
So today we’re going to be looking for wait time and failures within our organization, and we’re going to learn how to identify those now. So we’ve talked about what we’re looking for, and we’re going to talk now about how to build a value stream. Matt, probably before we start building one, we should actually define it. How do you tell people what a value stream is and where it fits in?

Matt Studley:
A value stream map is basically where we go from is from idea to in the customer’s hands. So we really want to go from when we first understand that the business needs to do something right at the very beginning and then walk it all the way through, follow the work all the way through all of the steps, through the organization, across all of the different departments, across all the different areas of the business until it’s back into the customer’s hands.

Marcus Grimm:
Now, so we know what we’re looking for. We know what the definition is. One more thing, and then I promise we can get started on building a value stream, which is why we’re all here, which is we need to take a look at some of those house rules because some of the things that we do within value stream mapping are a little bit different than some of us might be used to in our organizations. So, Matt, you’ve got six house rules that we need to be aware of before we do this within our own organization. Walk us through the first three, please.

Matt Studley:
Essentially, there’s a lot of different material on value stream maps if you go out into Google and look for it. There’s a lot of ones that are pretty descriptive and others that are more intent. What I found is that if your businesses and your organizations reality breaks a rule, go with reality. Because the whole point of this is what is going on right now. When you’re looking through and you’re following a piece of work through and you might ask yourself, like, how long does this take? Or why is this waiting? A lot of times it will come up as it depends. And that’s expected. So part of value stream should account for the variability in it and that’s actually part of what you can look at is how variable the work is. Speaking of the work following the work, we’re not following people. We’re following a piece of work. One unit of work, one valuable thing. As it travels all the way through, it can get bogged up with other valuable things. It can get broken down into an individual story through a Scrum team, and then it can get bundled back again and then move all the way through into the lease somehow. But it’s important to follow that one piece.

Now, what we’ve got here is when we say nobody isn’t working. So when we talk about wait, some other people call it waste time. And people can get defensive about that because they think that it applies, that they’re not working, especially if there’s a really long wait period in front of a stage in the work where there’s one person that might be doing that work, they may get defensive about it. And it’s not that they’re not working. They’re working on other pieces that are moving through. Things are sitting in a line waiting. So it’s never about somebody not working. A long wait time does not mean people aren’t working. Avoid anchoring and other cognitive biases. So when you have a value stream map, it’s important to have representation from your entire business so that you can get it from the horse’s mouth, basically, of exactly what’s going on. This means that there will probably be individual contributors and managers in the same room. And what can happen is if the manager says, oh, well, this is just one step.

The person who’s the individual contributor who says, oh, this is actually three steps may not say anything because their manager just did what’s called anchoring. You do want to watch out for that. And make sure that everybody in the room is safe to speak up so that you can get to reality? And finally, this isn’t a small undertaking. These dicey maps take a good amount of time to get put together from a lot of different people, and it’s continuous, which we’ll get into. So I realize that this is going to take some work to do, but the return on investment is worth it ten times over.

Marcus Grimm:
That’s very well said. Okay, so we know what we’re looking for. We’re looking for waste. We know we’re going to be looking for failures as well. And we also understand that this is a pretty big project. So the question becomes, if you take a look at that picture there, it’s an elephant. How do we all eat an elephant? Well, it’s simply one bite at a time. We’re going to go through a step by step process of exactly what that looks like here. So what is, in fact, the first step of creating that value stream?

Matt Studley:
Essentially, what we’ve got here is when you are first getting everyone together, it really helps to frame what you’re looking at. So what’s our goal and determine what elements are and are not within scope. The thing with the value stream map, when you start to look at this as an entire system, is that systems are boundless, right. They can stretch all the way into infinity or not. So it’s good to get a start and end. Basically, when does our problem space know that it needs to do something and when does it deliver that thing and it all creates basically a circle, and then essentially, it’s always having in mind what’s the problem we’re trying to solve. Is it that we’re too slow? Is it that we have too many defects? What is the business problem we’re trying to solve?

Marcus Grimm:
Now, can we build a value stream, Matt, please? Let’s have some fun on this one. Now, Matt, I’ve heard you say that systems are boundless. They can be as big as you want them to be, but we do need to set the stage. What is our goal? What is our scope?

So, Susannah, you built one for us here. You put together a diagram that looks at some of the fundamental processes of our business beyond Scrum. Walk us through the sample value stream components that you’ve put together that we’ll be talking about here for the next several minutes.

Susannah Parnin-Matchell:
First, I just want to mention that this example is super high level. In reality, when you’re doing one of these, you’re going to see significantly more detail than what we have here. What we’re doing is just what Matt was describing. It’s a first step at capturing the work within the scope that you’ve decided. So here in this example, it is a need or an idea from a customer as a starting trigger. And it is that work that’s been run through the machine of your business and delivered to the customer on the other end. And as Matt mentioned, we’re tracking every single step. So when you’re doing one of these, what that means is anytime work is done, not just code being written, but anytime something is worked on or processed by any organization, member or system, again, starting with that customer, and then all the way through any of the touchpoints I’m talking anytime it’s entered into a system or any time the work gets evaluated, when it changes hands or it changes state, anytime it’s translated or broken down through kind of approval or prioritization processes or detail flushing, all of these things are what you would capture in your map. Anything that’s a distinct step is what you’re after. And the way you get here is by pulling together, as Matt said, the knowledgeable folks in all areas of your organization. And it’s key to have the people who are doing the work, who understand the ins and outs of the system, and then you talk it through and you capture each of these points. It is no small task, as we said. And it’s also important to note that there’s probably no one person in the organization that knows it all. To get a valid map, you really need to know what all the parts are so you can get to that sum. For the sake of this, we kept it really simple. So what we have here is an idea from a customer captured into step one, added into a issues list within some tracking system. Step two, the community voting. Expose it to your community, have them upvote, much like we’re doing with our questions here. And that way they can be preliminarily prioritized. Then that’s translated into executable backlog. Next step is prioritization. There’s always prioritization within organization. You can’t do everything for everybody. After that, we have the Iterative development. This is where your sprints are happening, where the work is being coded, where oftentimes were narrowed in and focusing on our agile practice. Next, we’ve got some typical market readiness activities going on here. So internal trainings that might happen, then support delivery systems, prep and even sales enablement. You’re probably going to have a lot more here, too. How do you buill? How do you turn it on? All of those items somewhere in your map. But for the sake of this, we have these short stream.

Marcus Grimm:
It’s a great stage that we have set here. And now we’ve got our scope to find. Susannah did a great job of showing us this is what we’re looking at. She took on a big project, but hey, she’s got a good team behind her. So we’ve got a good project that’s defined here. And we’re not just looking at development, we’re looking for waste in the process. So now we understand what the steps are. Matt, take us through. We’re looking for time and we’re looking for failures. Walk us through the timepiece.

Matt Studley:
So with time, we want to know a couple of different things about the time. There’s work time, which is time on the keyboard or actually building whatever that step produces as part of the work. And then we have the wait time, which is how much time that it waits. So a great example of this will be an approval meeting.So the work is that 1 hour approval meeting. The wait is that this is a weekly meeting. So it can wait up to 40 hours. But wait, you say it depends. If I submit this on the day before the meeting, it’s only an eight hour work wait time. And that’s why we capture the minimum, the average and the maximum. We want to know in the best case what’s the best we’ve ever seen. We want to know what the worst case is, what’s the worst we’ve ever seen, and what is it usually and they usually will not be just the average between the maximum and the minimum. It’ll actually be offset towards one or the other.

Marcus Grimm:
Now, Matt, when you look at these timepieces, a couple of things come to mind, which is when you talk about things like getting approvals for this or getting buy in on that, here’s where we see some of the complexities that our own businesses have probably put into the process and in many cases with very good intentions to do so. Correct?

Matt Studley:
And it could be that some of these things, especially with wait. It could just be that there’s things need to wait for a moment. And it could be that wait is not a terrible thing. So for example, when we have in the diagram before the waiting for it to be voted on. That’s a good example of it being actually, this is wait time that we need to have. This is time being spent that we need to have.

Marcus Grimm:
So if we think about this particular project, what we’re saying is if we’ve determined that we’re going to let it be in community voting for X number of days. But that’s a process that we’ve decided to put into our business. And the whole point here is that we’re just capturing that information.So that’s how we look at doing the time. It’s the minimum, the average, the maximum. So that’s how we’re going to do the time required for each task. But now we also talk about the fact that we’re not just tracking time for value stream, Susannah. What else are we tracking?

Susannah Parnin-Matchell:
So in addition to the wait time, you’re going to also be pulling your execution experts that you’re working with on those exceptions that happen, those failures, you’re going to dig in on what Matt mentioned as those well, sometimes or the variance of these things, and you’re going to try and figure out how often a piece of work fails at a particular step. So failure might be QA catches a bug. That’s when we all know, right? So it gets sent back into Dev, but it can actually happen at any stage. So you’re going to look at each stage how often the work does not progress through that stage. So, for example, if the Dev team gets to a story and the goal of the story isn’t clear, they can’t execute on it. That goes back to the beginning of that goes back to PO breakdown, if you will, or if a prioritization exercise fails because some enablement work was missed and the priority is therefore not feasible or valid because you can’t execute according to the priority that would send it back. Another something will get all the way through and you’re trying to get your organization ready alongside the completed development work. And it’s determined that support doesn’t have access to what was built, they don’t have the new tooling, they haven’t been trained on it. So that needs to go back into development for provisioning and access, et cetera, and maybe even training so that they can actually support a customer. These are all the types of things that we would be looking for with failure, and there’s infinite points of failure that might happen. What you’re looking for is the average amount of time that something fails within that step.

Marcus Grimm:
Matt, what would you add to that? That was a great answer, Susannah. Matt, you can feel free to stay passed. But anything to add to that,

Matt Studley:
A big thing to look at is this is an incredibly all businesses are an incredibly complex system and failures are going to happen, right? So it’s not that you’re never going to have a 0% failure rate all the way through your process. There’s too much there. So one of the other things that you can start to look at as well is not only where do these failures occur and what can we do about it, but how do we deal with those failures?

Marcus Grimm:
Yes, absolutely. Very well said. So now we understand what we’re doing. We’re actually figuring out what is our failure rate. We’re also figuring out the time that goes into things. And so now, finally, is when we actually get to put pencil to paper or mouse to pixel and get out of Susannah, how do we do this?

Susannah Parnin-Matchell:
The next step is to map the data that you’ve gathered to put it on paper. You’re looking to understand your cycle times here, how much time you spend working, how much time you spend waiting, how much time you spend working and waiting and kind of see how these metrics hang together in the full flow. This is going to allow you to analyze the issues and uncover that waste that we were looking for.

Marcus Grimm:
At this point, we know what we wanted to look at and we’ve measured all these things. So you’ve built a value map for us. So walk us through what we’re looking at here.

Susannah Parnin-Matchell:
So what we’re seeing here is all the pieces that are plotted together. Again, this lets us see the efficiency kind of in the whole system. So without getting too detailed, I’ll just explain the major components. So we’ve got our idea as our start, same items here from our original valuement, but just with our data plotted on here. So you can see it takes about ten days for the issues overtime to get added to the system, a day in the queue before they get maybe put in for community voting. There’s that long wait time for community voting, 30 days that we have them working on it and 20 days of wait to make sure that it’s properly gathered here. Five days of work for creating that backlog. Five days of wait. Again, these are normal things that made up numbers here. So to illustrate our point, but that’s what you see. You see sort of this weight and work ladder at the bottom. What you also see is a triangle indicated in between each step. These indicate queues. So there’s always a queue in between that can be a simple handoff between one person or truly a backlog type structure where things stack up. And again, wait for that next processing step indicated in red, these little dotted arrows pointing back. Those are your failure rates when you have something that generally goes back a portion of the time to the previous or multiple previous steps or a few steps back indicated with a percent of times that it does fail. So we’ve got a 10% failure rate upfront here. In between Dev and prioritization, we’ve got a 25% documented. And then we have a long gap over here between the delivery systems being ready and having to go back into Dev. So just indicating all of the different data that we’ve gathered, averaged and plotted with the steps on the map.

Marcus Grimm:
So on your screen is that same value stream map. If you go to Google right now and Google value stream map, don’t do it right now, you’re going to find that your value stream diagram that you get looks very similar to this. And yet when we were working on this presentation, Matt said, ”yeah, I actually don’t like to show the data that way”. Matt, my first question for you is why not? And secondly, show us what you do prefer to do. So take that first question first and then we’ll flip slides and take a look at your way of doing it.

Matt Studley:
So when you look at this, the human nature is to read in the direction of our language, but the diagram can get a little difficult, especially with the time ladder that’s along the bottom to actually see where the delay is. Right now, if we look at it long enough, we could see it. You can see a 30 day over here, we can see a 25 day over there. We can start to see some of it, but we really got to look at it. And if I just glance at it, I can’t really see what this is telling me. So that’s what I don’t like about it. And this is what I suggest as an alternative. And by the way, Excel does this readily. This is a stack bar chart, and it now becomes very easy to see exactly where your time is going and wherein the process you have good ratios of wait time versus work time. And it allows you to just skim across and immediately you can zero right in on it and say, okay, that spot right there, what’s up with that?

Marcus Grimm:
Well, thank you. And we already got a comment in the chat that somebody else says,” Yeah, that’s a pretty cool visualization.” We all agree as well. So that’s an interesting way to view this data. Now, in the very next slide where we’re going to spend a lot of energy here, we’re going to talk about some of the Ahas. Or the insights. However, I do have a general one that I want to talk about that has gone into this process, Matt, which is the idea that what we’ve come up with here, if I’m a little bit creative, looks a bit like a U-shaped figure. Is that typical? And talk to me about why that tends to happen in our businesses if it does in fact, tend to happen.

Matt Studley:
Yeah. So there’s a couple of things that are going on here. So this U-shape that you usually see, if you notice it’s, where we actually build it is where the time gets the shortest and it actually gets longer towards the beginning of the process and towards the end of the process. That’s what makes that U-shape. And usually what’s happening there is work is getting bashed up. So are we actually going to do this? Think about quarterly approvals. That’s a 90 day wait time to approve a quarterly plan. And then once the quarterly plan gets approved, work starts to get broken down, starts to flow really quickly. You get into your Scrum process, you’re moving stories, you’re doing great. And then it comes time to release. We release quarterly. Or we release monthly because we have calendar-dependent deployments or something like that. So now we’re batching things up again. And once you batch up the story, that story kind of parts, things like getting put on a container ship that containership isn’t going to leave yet, and that’s where it will just sit there. And that’s your wait time. And then finally the ship is allowed to leave and it actually gets delivered. It’s very typical when we see that U-shape is that it’s taking time to get work to the teams, and then once the team is done, it’s taken time to get the work from the teams to the customer. And we always want to strive to flatten that you out to optimize.

Marcus Grimm:
Susannah, I’m going to put you on the spot here with a question that I promise you isn’t in your notes. I try not to do that, but I’m going to do it this time. Susannah, you do a lot of work with large enterprise organizations, cross-functional teams that may not interact quite so much. How does that inform some of that wait time we see at the end of the value stream?

Susannah Parnin-Matchell:
I’ve seen examples of this. I think oftentimes when you see a wait time at the end, teams are waiting for work to be totally complete. And not only is it a higher wait time, but you might also see higher rates of failure when you’re not talking amongst your team. And the work is very siloed and kind of the over the fence when one department is done thrown over type of set up, which is kind of where you see these U-shapes. And so it typically does get flushed out in these types of exercises and becomes a point of focus for improvement. And of course, one of the things we would automatically recommend is expose the full organization to the work that’s coming, the work as it’s being done, and try and create parallel work streams here instead of doing that over the fence work, wait, work, wait type of structure.

Marcus Grimm:
Absolutely. This is a great answer. Thank you. And speaking of which, Susannah, we’ve done it. We’ve got our scope together. We have our times very well recorded. We have our failure rates there. However, if you’re new to value stream mapping, there’s a lot of information here. So now we’re going to talk about what in the world do we do with something like this? Where would you start, Susannah?

Susannah Parnin-Matchell:
Sure. I just want to say this is where you’re really going to start gleaning the value from this process. As mentioned, we’re looking for waste here. It’s not just wait, but waste. Where we’re looking for anomalies in the map times of high wait and low work, that’s when we’re probably going to find waste or steps with high failure rates. Again, you can’t expect everything to go perfectly all the time, but when it’s really high, these are the things that you would find in your value stream map that might provide clues to where you can narrow in on potential issues. And what you said about the elephant before, it’s not feasible to fix everything at once. It provides a starting point for digging into the most impactful areas. So here what we’re seeing specifically in this example first, you have your high failure rates, and it’s when you see something like this that you can dig in and ask the questions, well, why is this failing so much? What can we change in our process?

You’re trying to get to the root cause of that failure issue to really understand it. We’re also seeing an instance here of big setbacks in organizational readiness. So that might be my prior example where support is trying to be ready to support a customer. They get in there to support it, and they don’t know how to use the tool that was built into the new technology, or they don’t have access to that tool and training on it, or they haven’t had licenses provisions, just very disruptive behavior that would send it all the way back to Dev, and then it has to be cycled back through after changes. So those are the types of things you’re looking out for as well. Again, you’re trying to see it on the map and then dig in and explore the root cause of it. Also, anytime you see that high imbalance between wait and work, that’s a flag we had already said many times, wait isn’t inherently bad, but that high ratio generally is associated with a bottleneck of some sort. Perhaps that’s resourcing, perhaps that’s process. Again, you’re going to evaluate it to see is that wait something that we want to do? Are we bundling at this point for efficiency, as Matt said, or do we just not have enough people to process a very high queue? These are, again, a point to dig in.

But the last piece I want to point out here is it’s not just about finding the waste. You can also find clues of efficiency here. I think one of our attendees already commented on their indications of high efficiency here in this map when the work time is really high, but the wait time is really low. So there’s opportunities to learn from that as well. And each map will be different for your organization. And the steps that work flows through and it will also evolve over time. As you zero in on these areas and make improvements, it will continue to fluctuate and hopefully flatten out

Marcus Grimm:
As you can see, value stream mapping is a pretty big concept. We focused in on identifying these challenges or opportunities, not necessarily prioritizing or solving them. And in fact, talking to this team, we realize there’s an entire program that we’re planning on doing on prioritizing addressing these issues. However, Matt, help us out here. Susannah already said it. I said it earlier. You eat an elephant one bite at a time. At a really high level. How would you maybe think about prioritizing within your own organization?

Matt Studley:
Yes. And this is why I like the graph so much, is that you look for your biggest constraint. And essentially, you really examined that one closely first. And the reason why you do that is you have all of these different areas to take all of these different times. If you have one that’s taller than the rest, that takes the most time out of the rest, and you improve things upstream, what you’re going to do is that queue you’ve been talking about, it’s going to start just overflowing and you’re getting work to that station so much faster than it can handle. It’s just going to flood.

Also, if you work downstream and you start improving downstream from that longest task, what’s going to happen is all of these downstream areas are going to starve because the work in this one step that we haven’t improved, that’s the longest step of the whole process cannot supply the work fast enough downstream. So you always want to look at where the slowest part of your process is first, so that you don’t create a traffic jam or no traffic at all somewhere else.

Marcus Grimm:
That is extremely well said. And I think you also summed up really well why we’ve already said there’s going to be a webinar coming up about prioritization and focusing on this because there’s a whole science about a theory of constraints, et cetera. Susannah, at the risk of being a little flippant, though, now the real work begins, right. As we explore these barriers in our value stream at a high level, how would you suggest addressing these items that we have now identified?

Susannah Parnin-Matchell:
This will take us to our last step here. Once you’ve gotten to the root cause of your issues, you’re ready to chart your path forward, essentially. And that entails envisioning your future state. And I think very imperatively should be mentioned here. Setting measurable goals, then prioritizing which areas to tackle first, as Matt was just describing, kind of figuring out which areas won’t flood or stop work within your system. Then it’s developing a plan for those areas. After you’ve dug in, getting buy-in for that plan, aligning on the goals, making sure everybody’s marching to the same tune and the approach for it that’s developed in that plan and then implementing. And I know we’re going to go into this in the next webinar. I’ll also mention here that I think a step-in implementation is continuing to measure. As we’ve mentioned, these maps do evolve over time, and every time you make a change, it’ll adjust your map. So, continuing to keep an updated value stream map and then measure against the goals that you set for your changes is an important piece of this. Yeah, I think that sums it up

Marcus Grimm:
That’s a lot of information, a ton about value stream mapping, about how to identify these wastes that we have as well as time. I’m going to call an audible right here. This is actually our last slide that we have, which is QA discussion. I think actually for the benefit of the room, this is the chart I just prefer to have on the screen because I think it allows us to refer to some of these questions that are coming in. And I will mention, as we’ve already said, we’re going to be talking about prioritization and facilitation more as we move forward. But I’m sure our speakers will be glad to speak to those points as well. So keep those Q&A’s coming in, and I’m going to start ripping down right through them right now.

Question1: Does the map needs to be created as a team effort, or can it be created by a knowledge person and refined it by those that do it? We’ve kind of set this up and almost made it seem like one person can go down and tick the boxes. But, Matt, you’ve done a ton of this. Do you want to walk us through this one?

Matt Studley:
Yeah, sure. So there’s always a temptation to have really knowledgeable people go through and make the map for everybody else, to try to minimize how much disruption you’re doing by going through the exercise. What I’ve usually found is that there’s drift in the system. And so this comes back to the anchoring that we talked about before in the cognitive bias. Is we assume that these are these things unless we really go and check and really follow it through. I have never had one time where we’ve gone through and said, okay, we think this is the map. And what will happen is we’ll show it and everyone will say, yes, that looks good, or we’ll show it, and everyone will be like, well, no, that’s not what happens at all. That was what we did two weeks ago. So it’s really important to have the people that actually are doing the work at all of the stages as part of this process because they are the ones who are getting the live updates because they’re the ones doing it the

Susannah Parnin-Matchell:
What I’ve seen is actually more often than not when you get folks in the room, you see the reaction of, wow, I didn’t know you guys did all of that before it got to me. I didn’t know that it was entered into the sales system and then run to our billing and then created into an order. All of these little steps that the different departments are doing and silos get exposed. And I think that becomes an aha for everybody. And it’s really powerful when the organization understands how something moves all the way through. That’s what sets you up to truly evaluate.

Marcus Grimm:
Next question, and it’s clear we definitely made an assumption with some terms. We talked about the idea of imbalances when we look at this slide. Susannah, define imbalance as we’re speaking about it here.

Susannah Parnin-Matchell:
Sure. I might not have been real articulate here. So a good example of imbalance is that last step that we’re pointing at question and balances. So you have a very long wait time for a very short amount of work time. So we have this one listed under Sales Enablement. Maybe it’s because the sales team doesn’t have time. They’re busy taking orders. Maybe it’s because they’re only getting together quarterly even though things are being released biweekly or monthly. The time between everything else being ready and sales being able to sell it is imbalanced here. I think that answers the question. When you have very high weight and low work, that’s what we would call an imbalance.

Marcus Grimm:
Speak to us about the inverse of this.

Susannah Parnin-Matchell:
I think we’re pointing at one here when the work time is high. And I think you actually see this a lot in the part of your process that is purely using agile. So I think we’ve said in a couple of our different webinars, it’s always the inputs and outputs that can bog it down. When your whole organization is not rowing in exactly the same way. The efficiency is when it doesn’t take a long time to get into a working state. But the work takes a long time. That’s inefficiency. Not necessarily the work takes a long time, but that the work takes significantly longer than the wait. That’s a sign of an efficient team. And what we’ve seen oftentimes with that efficiency is actually when the devs are doing the work, not so much when the work is queuing up to go to the development teams or when it’s sort of out of development. Ready for a customer’s hands.

Marcus Grimm:
Great question here from Jim. Jim, the first thing I would say is I don’t think you’re alone and Matt can speak to this. Jim says my Value Stream apps have almost always highlighted the work intake portion is having the most waste. Any tips on what to tackle first in this intake portfolio and how to tackle these typically involves talking to decision-makers, and having some difficult conversations. Yeah. I guess at the beginning of the value stream, it’s a lot of work. Who wants to fix Jim?

Matt Studley:
You can have multiple stages before the team gets their hands on it. You can have an architectural approval board. You can have a portfolio process in front of it. There’s a lot of things that can take place there. And the tips that I have is usually when the entire business is working on a larger cadence than the team is working on. These long upfront markers in the portfolio area and in the intake area are because the bets are so big that everybody has to make sure they’re 100% correct before they approve them for the teams to work on. But if you think about that, that’s an anti-pattern. And the whole idea here is that if we’re agile, we’re making small bets very frequently as opposed to one big bet, and then we release it to the team and then ship it. So some of the things that can help there is if you have one value stream that’s releasing all the work and you have one project management approval board and it’s one queue, then you have a bunch of different products is you actually split that value stream into three because it splits into three downstream with the development teams anyways, most likely. And I’m using three as an example here. But really what you do is you break the value streams and then those value streams own every piece of the business that they need to in order to get their work done so they don’t have to cross communicate. And that will break the queues and the bets and all of the decision making into smaller packages because this product is different than this product is different than this product, and that allows them all to react to the market faster.

Marcus Grimm:
Great answer. Thank you. Great question. I’m actually going to go back to this slide right here. We’ve got the time chart up here. Minimum, average, maximum, that sort of thing. Walk us through a walking the work looks like, who does that? How is it done? Is it just anecdotal? Are you actually observing the person at a high level? Walk us through what that looks like?

Matt Studley:
So there’s a couple of different ways that you can capture this information. When you first get this concept introduced and start working on it, a lot of it is going to be anecdotal, which is why it’s so important to have the people that actually do the work right there with you. If you have other tools in your value stream somewhere like Jira or DevOps, any of those those things have the ability to measure cycle time, which will give you a piece of the time spent for that piece of evaluation. Right. Now, one of the things that I’ve done to help measure and help understand where things are happening is this is an optional thing you can do with a value stream map. You do not need to do this, and I do not recommend this for your first time. Doing it is putting which tools are used in the stream where so that you can see the tool systems overlapping. That also can start to inform where to go get the information you need. If the value stream has been scaled down enough, then it’s usually contained within one tool, which means that the value stream can actually be automated. A good example of that would be a Jira board with all of the columns for all of the work, all of it, all the way through the business in Jira board. And then you can see each column and how long each column takes. And then you can use similar flow diagrams or something like that.

Marcus Grimm:
I always love it when the question comes in from the cutting room floor. One of the things that the team talked about was some of the best practices, some of the metrics that are out there. And Matt loves to quote these. But then he always says, don’t hold me to that exact number. So I always know that his numbers are always directionally accurate, nothing more. I pulled this chart back up here. What are some of those metrics that sometimes organizations that are really good about doing the math are looking for here, Matt?

Matt Studley:
Okay. So when you’re looking at the performance of a software organization, there are four key lagging indicators that you can use. So there’s your lead time, which is the time it takes to go from the start of your process to the interview process. Start to finish. How much time does it actually take? And that’s your work time plus your wait time, some together of all your steps. That is how long it takes. There is your deployment frequency. How often do we ship things to customers?

There’s our mean time to recover, which is how long does it take from when we’ve detected that something’s wrong in production? Does it take for us to fix it? What’s our meantime there and then the last one is correct and accurate. Which is how often do we deploy? What percentage chances are that there’s going to be a defect, right. A couple of other numbers, one that’s easily once you have your work time and your wait time for all of your steps and all those up, you can also take your total work time divided by your total time. And that gives you your process efficiency percent.

Marcus Grimm:
You’ve spoken about this before. That project efficiency percent seems super useful and super valid. Are there some benchmarks that high performing organizations get up to?

Matt Studley:
Yeah. So with lean organizations, you are typically running in the 10 to 15% range.

Marcus Grimm:
Walk us through that formula again and then and take us to the result.

Matt Studley:
Sure. So let’s look at the diagram that we have in front of us here. So we’ve got work time here, and we don’t have numbers here, but what we would do is sum each of these steps. Now, the total time for each step is the work time plus the wait time. The blue plus the green. So that’s going to give us some numbers on the bottom. And we go all the way through. And then if we add all of those together, that’s our process total time. Now, if we take just over time, just the blue segments here at all of those up across the steps, that gives us our total work time. How much time measured in hours are we actually working on value add to our customers. Now you can put that into a fraction and divide it so that you have your work time total over your total time. And that gives you the fraction of time that people are spending on value-added work as opposed to nonvalue added work.

Marcus Grimm:
Ten to 15% is pretty good.

Matt Studley:
You do not want to fall below 10%. If you are falling below 10%, that means that for every 1 hour that you are spending on value add, you are spending another nine on non-value ad work.

Marcus Grimm:
Which doesn’t sound very appealing. I do want to let you know this team, we did everything we could to put value stream mapping within 1 hour. That was optimistic. And so we’ve talked about the fact that in follow up programs we’re going to do about prioritization and also about facilitation. Susannah, I want to give this question to you as it relates to facilitation very much said, that’s a big deal. You’re asking a lot of information and how you ask it and who asks it. It’s a process in and of itself. As we begin to wrap up things here, what can you tell us about some of the things that you think of as it relates to exactly facilitating one of these? Because there’s doing a value stream, which we’ve identified. But it’s the soft skills, the how you do it. Can you answer that one?

Susannah Parnin-Matchell:
Sure, I can answer it from the perspective of how I’ve experienced it working before and we’ve mentioned a couple of these components. But when you put it all together, it looks a little something like this. First, get the people doing the work into a room together and then set your context. So we are talking about from when work comes in from a customer. In our example, it’s an issue reported by a customer that they want fixed. But that could be anything. It could be the market needs this. So it’s going through PNL, goal setting, et cetera, whatever your inputs are to the process, you set your start and your end and with folks in a room. And it does take some workshopping ask, okay, what’s next? And you might hear somebody say, well, it goes into X system. So you take that right on a sticky, put it on the board. Okay, what’s next? So you just basically walk the work through all of the steps, and that’s when you’re going to have the dialogue and the benefit of having more than one person on the room. They’ll say no, before it gets to Jen, in accounting, it goes through Sheila in order management or whatever. I’m just making this up out of that dialogue, you glean those steps. And so another point I would say is don’t try and build it into a system as you’re standing there. Don’t waste time on tooling up front, capture the items.

I literally use sticky notes and a board. Put it up there, put it up there, move it around. Oftentimes it’ll split. They’ll be parallel work streams, but just keep asking, okay, what next? And one of the earlier rules that Matt talked about was it depends. What does it depend on? Are there two separate streams? Something can go on. Does it depend on what system does it depend on how it came in? Just keep asking the questions to pull out the steps, the distinct steps that the work goes through. That’s how you flush it out. That’s how you facilitate it. Another tip I would have just to finish that thought with is don’t try and get all the information at once. Start with your steps, then start with your wait times. How long before it gets to the next? Then talk about failure. Don’t try and capture all of that in the same conversation. It’s overwhelming. And you’ll go down a rabbit hole first, just map out the steps kind of like we did. Then iterate through it.

Marcus Grimm:
Two final questions here. And then we’ll wrap things up. Matt, I know you’re a big fan and you always say when we do these, let’s make sure we’re dialed in on language. So clarification question, clarify any difference that there might be you did use the word lead time and we’ve been using the word work time. Is there a difference in that context or how do you think about it?

Matt Studley:
Yeah. So work time is a component of lead time. Lead time is the time it takes from as a customer, I say, hey, I would like this. And you say, okay, we’ll get right to it. And the time that they say, hey, it’s ready here. You go. It’s literally the very beginning to the very end. How much time elapsed that’s lead time. Work time is something that we’re capturing in each step. And work time is a component that, when you sum up, adds to the sum that becomes lead time.

Marcus Grimm:
Wonderful. And Jim asked us one more here. How long would you say your typical single product value stream session normally takes? I’m tempted to say it depends, but in the spirit of today’s program, I won’t do that. Matt or Susannah, can you just talk to me about how you tend to schedule and execute on these?

Susannah Parnin-Matchell:
It does depends. That’s a really good point. It’s very hard to say how long it takes. I’ll just say it shouldn’t take longer than 2 hours at a time because people will burn out. So what you don’t want is people burning out and not paying attention because it is the detail you’re going after. So a series of two-hour sessions is generally how I approach it. You need enough time to dig in, get a little lost, and come back at times, but not so much time that it’s grueling and people naturally start zoning out. Typically, it’s been a series of three to five. I’ll say two-hour sessions to go from, okay, where are we starting and where are we ending and setting that context to having the data and pull it back. And in between those sessions, you can formalize it and put it back in front of folks and then flush it out again. And then formalize it, put it back in front of folks, flush it out again. It’s iterative

Marcus Grimm:
I said that was our last question, but I lied because Dawn dropped fire here at the end. So I want to take this one because I love talking about tools. What tool do you guys use to capture the steps and dialogue during a virtual facilitation session? That’s a great question. If you’re going to be asking for all these things, Matt, how do you like to grab data?

Matt Studley:
Okay, so I use two things. I use virtual sticky notes since we’re all remote or if you’re in person, just regular sticky notes. Right. Because again, reality needs to supersede rules. And if you’re using certain tools, they’ll try to force a certain way to you and you’ve got to capture reality. So anything that allows you to do virtual sticky notes for the visual for the data. Then, I use Excel to capture an average, minimum and maximum. From there, I’m able to generate that stack bar chart and actually just copy the image into the virtual sticky notes and then stretch the image and then you can actually see the bars line up really easily.

Susannah Parnin-Matchell:
I think that’s what I would use, too. I occasionally have tried using Lucidcharts, which is just an online process mapping tool. It’s really easy, though, to get lost and kind of dinking around with keeping things straight so oftentimes we’ll start in excel and just capture boom, boom. These are the steps and the next round we’ll visualize it. Virtual sticky notes work very well and anything where you can quickly capture it, not worry about format and just move stuff around on the fly. That’s what you’re looking for to facilitate a session.

Marcus Grimm:
Matt and Susannah, we knew this was going to be a big one and it was. Thank you so much for joining us on the program today. Really appreciate all of you on the call, there’s going to be a survey when the webinar ends. Please fill that out. It really helps the team decide what value to bring you in further programs. We love the time that you’ve spent with us all day. Yes, you will get the slides, you will get the recording and yes, we will give you a spreadsheet tool as well that the team uses is to actually collect this data for everyone at assemble. My name is Marcus Grimm. Have a wonderful rest of your day and a wonderful rest of your week. Thank you so much for joining us.