00:00:13

Hi, I'm Paula Thrasher. I'm a digital transformation executive in the defense and aerospace industry. I've worked for companies like CSC, general dynamics and United technologies. And what I want to talk about today is my experience. And five years of running value stream mapping workshops across a number of teams, a number of organizations, and how I think it's a very effective tool in your DevOps transformation. So I wanted this to be very instructional. So you walk away and can actually use this tool in your organization. I definitely would like it to be interactive. And since we're virtual and we've got the slack channel, if you have any questions along the way, definitely hit me up on slack and I'd be happy to help. All right, let's get into it. So the first thing we need to talk about is what a value stream is. So value stream mapping is a technique and it comes from lean manufacturing, but lets you analyze the current state environment in order to improve the future state it's to me fundamentally, a visualization tool and it's intended to be a systems view of your enterprise as is. Now you can also do a future state value stream, but I'm really going to focus on using the mapping technique to model your current state

00:01:21

A key idea, uh, that I want to cover about what a value stream map is is systems thinking. Now, if you've read the Phoenix project, you know, obviously this is one of the three principles of DevOps and I would say, this is the concept that you want to start with the customer and very much focused on how you go from concept to coaching. And that really is everyone in your organization that delivers into the value stream, whatever role that is, whatever that looks like in your organization. Um, obviously it's typical to think about development and ops, but don't forget folks like support test audit and so on and so forth.

00:01:56

The point is it needs to be the entire value stream or not really the point. The next idea that I want to talk about is the purpose, which is to identify and eliminate waste. Now, again, this comes from lean manufacturing, so it thinks about the manufacturing context, things about physical movement and so on and so forth. But in a software world waste takes a little bit of a different form. And I want to give credit here to Mary and Tom Poppendieck, who came up with this concept that was two decades ago, but waste in software is things like defects waiting, building extra features, relearning having lots of hand-offs has switching so on and so forth. I'm not going to get into a lot of detail, but each of these forms of waste, but I will provide some examples in slack channel for those of you that have questions about them.

00:02:40

The next key idea. And of course the whole point of the exercise is to implement countermeasures. I mean, obviously if you're going to identify waste, you need to come up with a way that you're going to actually resolve it. Obviously automation is a huge technique, but sometimes just lowering work in progress or refactoring something is the solution. We'll talk more about that as we go along, but this is really the whole point is the purpose of the map is to come up with the things that you're going to implement that are going to make your process go faster and deliver with better quality and better value to your restaurant. Just to give an example of what this looks like. This was obviously an in-person session, but it's something I did a number of years ago and like a lot of organization, it starts with requirements.

00:03:16

We met with our customer and thought of some ideas and that took a little bit of time. And of course we'd done our usual agile transformation and that team had done lots of optimization, but here's the kicker. Everything else that it took to deploy was actually where a lot of the bottlenecks are. So the benefit of actually drawing this visual was the organization was able to visualize that and really have good conversations about things that needed to happen to make this improvement work. Now, just in this example to give what it looked like when they were done, they went from around 46 days from concept to coaching to about 11 and how they did that was coming up with a series of improvements. For example, in this everything else to deploy that was taking more than five days and getting that down to 12 minutes, I can't say this enough, but you fundamentally change how your organization works.

00:04:03

If you take a process that used to take four days and make it take 12 minutes, it's huge. This is a tremendous accelerator for your DevOps transformation. It's actually, I think how a lot of organizations get real impact and all those things you want read about in the state of DevOps report. So with that, that hasn't convinced you of the value of doing this. Let's get into it. So let's run one. If you want to run one, the first thing you need to do is start with a feature. And I talk about the four, the five RS, it needs to be recent. And that is something that you can remember what happened. So probably in the last three months, it should be real. I mean, ideally this is something that actually has business impact to you and not just like a software upgrade, it should have reach.

00:04:46

And that is something that really covers the full value stream and it should be representative. So it should be something that, um, is typical to how you do work and not like a emergency request or something atypical. That's not going to really uncover the actual processes and practices going on in your organization. Um, the last piece is really important too. I think it needs to be road tested. It should be something that is in production. And ideally you have a lot of trilemma tree on all the places from when you thought of the idea to when you deployed it and even better, some feedback from the customer about how it was received or how well it worked.

00:05:22

Now, the next piece, of course, besides the feature are the people to have the session and just a few titles. You might need to include the customer if you have them, but that's not always realistic. So at least the business owner, certainly the product owner all the way through to all the people in the organization who are part of delivering this value all the way through to customer service. Now, just to make sure this is not a huge list because in most organizations, this is an enormous list of people. You did pick a specific feature. So the people you would like involved in your value stream session are the people who worked on that feature and they can talk to how that feature was implemented, how that process actually went. So not every developer, the developer that wrote that feature, not every database engineer, the one that was on call when you put the thing in production, right?

00:06:06

So that should help narrow the list. Now it might still be 20, even 30 people. I mean, I hope not, but it could be. And a lot of organizations I work with that's about the size you start off with and that's okay. Just understand that it's important that all the roles, especially all the silos are represented because the real value of the session is the conversations you're going to be creating as a quick anecdote. If not everybody wants to participate, one tip, I usually say is tell them it's a chance to complain. People will do that. Okay, next we're going to place activities on the timeline. So for this example, I've just done a very simple, you know, begins on Monday, ends on Friday. If you know, when you started working on the feature to when you deployed it, you can actually put those dates on a real calendar.

00:06:52

If you don't have it, you can just sort of do a notional timeline and people sort of figure it out. In one example that I did an in-person session, I had people use colors to represent their roles. And that kind of let us visualize some of the handoffs that were going on in this organization. Um, on the card I had them write details. What was the activity they were doing? When did it start? When did they start working on it? When did they finish working on it? And then about how much effort? So for example, I started on Monday. I finished on Wednesday, but look, I only spent four hours on it, right? Just as an example. And if two people work on the same activity, we just kind of stack the cards on top of each other. You can kind of get the basic concept of how this would work.

00:07:29

Another example that I did that doesn't follow a strict timeline was an organization that was trying to look at some audit things and improve through that process. And they were really very SDLC centric. Now this is in my mind where the art meets the science, um, their mental model of how they worked was around their SDLC, not around time. So that's what we used in our mapping exercise. And in this case, I had them model manual activities with one color and automated things with a different color. So that was what this organization needed to focus on. What I would say about this. And however you decide to structure, it is one thing to keep in mind is there's a little bit of a, what I call a micro macro going on here, the micro being the actual card, it's going to have the details about the activity and starting finished and the roles and so on and so forth. The macro is like, just look at zoom out. You can see for instance that the yellow means automation. There's a lot of automation and death, maybe a little intense because a lot of places where there's manual and that tells us areas as we get to the waist and the countermeasures that we might want to focus. So, like I said, there's more art to science here, but if you think about how you want to set up and facilitate the session, that's definitely something you might want to think about.

00:08:42

So for, I want to talk about this as absolutely the most important part of the entire exercise is the conversation. Um, I think a lot of times the things that need to be improved are, would seem like they're obvious, but what they're really gonna get the benefit is the conversation that you're going to have between different parts of the organization, getting the context to look at this entire value stream and really see what things are holding your organization back. I think as a facilitative tool, this is the most important piece of this exercise. So it's really important, even though I think from a virtual standpoint, you can definitely do the earlier steps. You know, offline is synchronous before the meeting. You need to make sure the focus of the meeting is the conversation. I would say, I've spent two days on this, but really you can spend two hours. It doesn't have to be a two day exercise, but you do need to make sure you have enough time to have a conversation about the Mackie bill. So as you gauge how long you need to have these workshops, definitely give that a consideration as well. I would say given long versions and short version, the happy medium is somewhere between two and four hours, right? It's long enough to have a good conversation, but not so long that nobody wants to come to your meeting.

00:09:54

The next step we want to talk about is the identifying waste, right? This is again, one of the key things you're trying to accomplish through your value stream session. We talked about the forms of waste. Things like places where we were waiting or where there was a defect and something had to be redone or something was partially done. And then somebody later on in the work stream has to fix it. This is another place where the conversation becomes important. You can identify the waste, but I think you need to have a conversation where the real waste is. I don't want to give you an example. So in one of these sessions that we had, the quality assurance organization was rebuilding the software, but the development team had already built. And the development team thought, well, that's really wasteful, right? We've already built the software and here you are rebuilding it and it takes time.

00:10:36

And it doesn't seem like that's adding any value. Now the QA organization standpoint was they didn't trust the build the developers are doing because they were running it on Joe developer's desktop. And so for that reason, they felt like they had to do it. And we're going to have a clean bill. Now, one can decide where that waste is, but it was important that that team have that conversation about where the actual waste was. And the answer is in both places, the build needed to be done correctly without defects, but it also didn't need to happen twice. This is why that conversation is so important because these are things you can really only surface. I think when you get the entire value stream together, to look at the problem.

00:11:19

Now, the one thing I will say is having done this, you will always find lots of ways. I haven't done this with a team that has, I found at least 20 something places where there's waste in their value stream or more right. It's a lot. So you do actually have to focus and I suggest any technique you have to prioritize. Now, what I love is just most annoying waste of work. This is one that actually is great from a motivational standpoint, if you ask people to fix the source of waste, that is most annoying to them, they will be highly motivated to work on it. But truthfully, a technique that you want to use to prioritize is fine, uh, dot, voting, whatever, right? Um, the point is that you do need to prioritize because you are going to have a lot. And the other piece that I would say is a lot of times, when you look at the big picture, it becomes obvious where the biggest waste is and where the biggest bottleneck is. And those are things you definitely want to tackle because following sort of that whole lean manufacturing theory of constraints, this is where you're going to have the biggest impact on your transformation.

00:12:19

Now, this is the part where you have to ask teams to actually do a little extra work on their own. And that's the countermeasure brainstorm. So after you've voted on the most important waste, we're going to take those topics and think about what our countermeasures look like. Now. I like to use kind of a lean campus technique for this, but anything you want to facilitate is fine here. Um, to follow the lean canvas. What I've usually done is something that looks something like the following, um, where I take the target process, we're talking about, let's say security engineering and the goal, which is to automate the security approval, to make it go quicker. And so to give an example, the current state, now you've just modeled that value stream. So you can describe all the things about the current state. Then you want to describe what you think the future state should look like.

00:13:04

And I also think it's important to have some measurement. You want to know that the improvement you implemented is going to work and how would you know that? So you're thinking about ahead of time before you run this experiment, how you're going to measure the effectiveness of it. Then the next part, I'm going to talk about this in more detail, but I think it's super important is baby steps. You do want to come up with something that is tangible and the team can actually tackle that's small and baby steps. You can actually implement to make progress. Of course, anything you try to do might have some issues, risks. You want to capture that. And it's not a meeting without giving its owners. Cause if not, nobody really owns implementing it and who's going to manage that process. So this is a great way to just structure a lean canvas.

00:13:44

You can add or remove things as you value. And I hope you find this kind of context. Um, guidable to give a context of what this looks like and sort of a real world example. One of the sessions I ran the target process area was, um, the security approvals. The goal was to take something that was taking them four days and reduce it and increase the security of the system that was going to production. The current state was the team was getting all the way to code complete, and then it was security reviewed. And sometimes it's freaking would find things which would cause some rework and delay and often things that were supposed to go through quickly. He was adding four and five days to the process and it was causing a lot of rework and a lot of angst. The future state was to introduce more security automation earlier in the process and bringing security team in sewer so that they could provide more insight to that development team.

00:14:34

Now, how they know at work was that they would reduce the total time to go from idea to in production and also that they would have less security issues in production. Two good things to measure now, baby steps. Now that I first started off with, oh, we've got to implement like eight security tools order to make this happen. Okay. That's not a baby step. What they actually realized was two things. One is the security team had this insight of the kinds of threats and activities that were happening to the system, but they weren't sharing that with the development team. So the easiest thing that they started doing was every week, the security team started briefing the development team on what was going on in their world. Um, pretty easy. It didn't take any, uh, technical implementation knowledge took time. The next thing was they realized that the organization already owned some automation tools that were being used somewhere else.

00:15:21

But instead of trying to go out and find five new tools, they could talk to another team, find out how they were using automation and implement that best practice on their own team. Bringing some feedback in earlier and shifting left into their cycle, which would help them reduce the sort of obvious, you know, brainer security issues that were making it through to the security review process and issues were risks were of course they didn't know if this tool was going to work in their code base versus the other one, but they gave ownership to it. And it was something they could implement really in about four to five weeks, which they did. And it was a great improvement and it really took about a whole week off the cycle time of getting to production. And from the security team standpoint, they felt more engaged with the team and they felt like they had a much better sense of security risk.

00:16:03

So just as an example, there's plenty and they're going to vary as widely as value streams will now to talk a little bit more about the baby steps and how you might want to think about that and making sure that it really is a baby step. I like to think about it in four ways. So one is to think about how broad the improvement is like a single team that's going to make this thing happen, or is it the whole business? Now my security example, it was something their team was going to do. Now, if that was successful, it probably isn't implementation. They want to bring to the whole enterprise, but we're not trying to tackle the entire enterprise implementing something, right. So it keeps it really truly made step now, bounded, is it something you can tackle internal? Great. Is it a regulatory thing?

00:16:44

I'm just going to suggest that if your improvement involves lobbying Congress, it's probably not in scope if your team to do, however, maybe it involves tackling something in a different way than you used to. The point is try to make sure the bounding of the improvement is something that you can actually control as much as possible. Think about it as well, how much effort the system improvement. You can still tackle things that might be very intensive and have a lot of efforts, which you need to break them down into smaller tasks that you can make actionable progress on throughout the process. So it's not one big thing. It's lots of little things. Um, the other thing is how difficult, right? Is this, you know, a simple fix, I mean, the example of the security thing, right? They literally just had a meeting. That's like, I keep getting simpler than that.

00:17:26

Um, visionary is like, we're going to try to address some compliance issues with things it's never been done before. I mean, that's possible. And I have certainly actually had some teams come up with some really innovative things at a value stream mapping exercises. Just to understand that, obviously there's a little more risk, the more complicated you make something. I just use this as something that the teams can kind of think about as you're running this countermeasure brainstorm to kind of really check that they're not trying to like bite off more nature. I think it's the converse is true. I've run the session a couple of times with teams where they don't think big enough because they assume the organization isn't going to tackle core problems. So also the flip side is from a trust standpoint, make sure the team feels like they have scope to really make changes that are going to truly have impact on their value stream.

00:18:14

So

00:18:15

The last part of course is the repeat, right? I think this lives on a lifecycle. And from a standpoint, this is probably the first thing you want to do in your dev ops transformation. I mean, I would say the first thing to start is describe why you want to do a demonstrates remission. But even beyond that, there's probably some low hanging fruit you can tackle early on where this really shines is when you hit that plateau, right? You've done some great things. You've done some automations, you've made some improvements. You've, you've changed some things about your organization, but you're not really feeling that major impact. This gives the team the context to really find those big wins that are going to dramatically improve. As I mentioned in some of these examples. So the idea is you're going to do that value stream map workshop across the team and system.

00:18:59

You're going to basically implement your countermeasures and improve flow. I do think it's important that as part of your life cycle, you're really focused on creating observability because that observability is data. That's going to drive your experiments and future value stream mapping sessions. You'll ultimately can use this as a great tool to innovate and improve your organization. I think it's a great source of finding where you can have the biggest impact that really helps you to live in value better on fire quality. Now, one thing I would say about doing this in a large enterprise, just from my experience, um, some years ago I was running a group that had five portfolios as we did this across all the portfolios. One of the things that I thought initially was, well, I'm going to have to do this for all 32 teams. Okay, well, so what I learned was somewhere around the third or fourth, one of these things that we were seeing the same problems.

00:19:47

I mean, I think this is Conway's law at work. You probably don't need to do this for every single team in your enterprise, because my guess is that there are some systemic things that are true for most teams. And once you start uncovering those in value stream maps, you're uncovering some of the systemic things that you want as nation needs to address across multiple teams, which is a great value to me of this, but it kind of creates frustration for future teams. If you kind of keep repeating this and they keep finding the same problems, the second point I'll make about this is, um, you have to think about what you're trying to actually achieve as value. So one example, that's maybe a little bit atypical that we implemented, um, that I was just been in, was looking at, for instance, onboarding new employees. And it wasn't like a single system.

00:20:38

We were actually looking at a business process from a value stream standpoint that covered about five or six systems, but we brought people who were participants both from the business of the organization, as well as the system organizations in that process. And again, we didn't use fictional workflow. We actually use 10 real cases that had happened and talked about what happened in each system when it worked. And when it didn't work that a little, slightly more complicated version of value stream map. But I would say from a process point, it doesn't have to stop and start at the system boundary. There's actually a ton of value in thinking about the honest to goodness real value stream. That includes the business ownership and process piece of the system, as well as the actual development of the system. Right? Think about the humans that are involved in delivering value, and this is where you get such tremendous impact of having a great conversation. So there's a lot of different ways to have value stream, and I'm happy to talk in more detail about my experiences. And I would love to hear more about some of yours and just, I hope you can think about it as a great technique that I think is really underutilized in taking an organization that feels stuck in a DevOps transformation and really getting a major impact. I've almost never seen a team do this, that hasn't had some dramatic numbers posted as a result of doing one of these workshops.

00:22:01

Just a quick note, because Hey, we are in a virtual world these days. And obviously some of these sessions that I talked about happened in person. It's lovely when you can be in a great room, but that's probably not happening anytime in the near future. So just a few things I want to mention from a virtual standpoint to think about. So first off is I can't emphasize enough having the people and having that conversation really is the value of the session. So make sure whatever virtual thing you have is done in a way that the people who participate in value stream can really participate in the workshop in a virtual context. Um, you do want to have some shared visual capability, um, a great tool that I really like is mural. Um, it could be Google docs, it could be Microsoft teams. It could be any number of things, whatever your organization has or has access to the can create a shared visual.

00:22:48

Um, it's great if you can model stuff, but for simplicity, I like something that kind of just mimics the sticky note because frankly it's simple. Um, the second piece that I think is a really important part of an in-person session, but also a virtual one is having a neutral facilitator is the conversation is a really important piece of this. You want someone who can really have a, a neutral arbiter of these conversations and help people really think through the value stream? Uh, I can't, you know, again, it's, it's a map, not a model. It's not how we think things work. It really is designed on our reality and how things actually work. So it is really important that you model actual work and don't give them the temptation to do too many features, a single feature and model how that actual work happened. That feature going from idea to production is in fact, one of the most impactful things you can model.

00:23:41

Um, so make sure that everyone understands that now one thing you can do virtually that is actually kind of nice that sometimes it's hard to do a person is you can have people go into their system and record JIRA Salesforce service now, whatever that is, and actually date and timestamp, when stuff happened, who worked on it, what happened next, who collaborated and that sort of thing. So you do actually have some artifacts that you can bring and you can have people do some stuff ahead of the meeting, potentially asynchronously in your virtual room and then focus the time that you're going to use for these sessions on the actual conversation. Um, so I think that's actually kind of a benefit of doing things virtually. Um, and also what's nice is that since you've captured this virtually, it makes sharing it really effective, which is something that Greg around pieces of paper is a little complicated.

00:24:29

The one thing I will say about doing stuff virtually is in an in-person session, you have ability to read the room and virtually don't. I think it's really important that you build trust through this conversation. So you do need to make sure you have some mechanism for reading the nonverbal reactions of the participants and that you have a mechanism to really kind of gauge that, um, formally what you might have done informally in an in-person session. So those are just some things to think about as you do this virtually, but I think like all of you, we're all learning a lot about how to live in a virtual world. So if you've had some experience doing some of these sessions virtually, I would love to hear more with that. I'll say that if there's other ways I can help you and running the session, I'm very passionate about value stream maps.

00:25:13

I think they are one of the most effective tools and DevOps transformation, which you can have for really getting transformative impact. But I also think they're one of the least utilized. So I really want to help people implement this. And I'm happy to reach out to me, happy to help give you tips or guidance or feedback at any point. And you can certainly reach me in the conference slack, but, um, outside of that, these are the other ways you can reach me. And then I would love to hear your experience. I'd love to hear where people who've done value stream maps. I learned with each new one that I participate in or hear I've learned a lot and I would love as well as we all navigate the virtual world to hear some things that you've done virtually and how that's worked for you and the tips that you can share. And with that, thank you very much.