Q&A: VendorDome: The Time is Now - Accelerate DevOps & Agile with VSM

Helen Beal

[0:14] Welcome to this DevOps Enterprise Summit, Las Vegas 2020 Vendordome. But this is not a Vendordome, it's a vendor love-in today. I'm Helen Beal, and today I'm going to be playing the devil's advocate. So Jeff, please go ahead and introduce yourself.

Jeff Keyes

[0:30] Thank you. My name is Jeff Keyes. I run the product team here at Plutora.

Helen Beal

[0:34] And on the other end of the rainbow, Steve, tell us all about you.

Steve Boone

[0:38] Hey, everybody. My name is Steve Boone. I lead up the product management for our DevOps organization at HCL Software.

Helen Beal

[0:44] And to the audience, we are taking questions live today, so please put them in the Slack channel. That's the Ask the Speaker Track Four channel specifically, and let's get this party started. So what is the problem, guys? Is stuff really broken or are people really making a fuss about nothing? Are we saying that everyone's been a bit dumb and we've been doing it wrong all this time? What have we been doing wrong, Jeff?

Jeff Keyes

[1:07] Well, it's kind of funny. It's fun to be here at the birth of a new category called value stream management, and yet we're at a DevOps Enterprise Summit conference. And I remember walking around the booths last year, and everywhere there was value stream. But I don't think people really get what the goal is. They just know it's cool, and so go get me that tool or some of that. The core problems of value stream management focus on really four key areas. One, people still can't see along the application delivery pipeline. They don't know what's happening from idea all the way to production. Well, and if you can't see across a single pipeline, that brings you to problem two, you can't see what's happening at the portfolio. At the portfolio level, you have an additional problem of dependencies, timelines, how they all fit together, and yet they all have to merge going into a production environment. The third core problem of value stream management focuses on the ability to manage having a control plane, if you will, to manage what's happening across different methodologies. Not every team is DevOps. Not every team is at the same level of DevOps. Oh, to be all automated all the way through, but it ain't reality in most enterprises. And the fourth problem is if you haven't solved all three, for sure you don't get metrics of delivery and you're not having any system of continuous improvement. I had one of the partners that we have, I remember talking to him yesterday, or sorry, last week, about one of the problems they were facing in their DevOps transformation. And one of the best messages he said is, "We did a lot of really cool things, but we couldn't prove it to anybody. We couldn't show them we'd done better." So value stream management acts as an umbrella to actually handle and solve these problems of visibility.

Helen Beal

[2:55] So we're flying blind, are we?

Steve Boone

[2:58] Absolutely. We're flying, not so much necessarily blind, but I definitely think there's a problem with rolling this information up. Jeff, you talked about this idea of continuous improvement. I think that's exactly right. When we talk DevOps, we always talk about this concept of fast feedback. And to me, the idea of visualizing your value stream or being able to look at your value stream in real-time, to me, that's providing you the ultimate feedback loop. And at all different levels, not just at an individual development team level, how we communicate, how we track and plan our work, how we can help one another and communicate better. But also when we look at it from an organizational level, how do we identify high-performing teams? How do we know what their best practices actually are so that culturally we can embrace those, we can share those, we can educate other folks? That's been one of the biggest challenges. More and more I see companies that are turning around and saying, "Okay, engineering team, use whatever tools you want to be as effective as you possibly can." And that's great, but then you have the problem of, well, how do we make sure, from a compliance and security standpoint, that all those different teams, all those different applications, the decades of technology, aren't putting our business at risk? How can we actually start to validate what they're doing, learn how they're doing it, and really use it as kind of a North Star, right? So that we can start changing conversations from being reactive, "Hey, what do we think is wrong?" To proactive, "Here's how we're going to go fix it."

Helen Beal

[4:21] So we've been doing this stuff for decades, like you just said, so why haven't we got it right yet? Why do we still need to identify a North Star?

Steve Boone

[4:29] Yeah, I think the big challenge is you've got a lot of large enterprises that would like to be unicorns, right? They want to do true continuous delivery, but oftentimes they feel more like horses. And the reason that is because we are still stuck in CAB meetings. We're still stuck with a ton of regulation that we need to get through. A lot of folks are just plainly saying, "Yes, look, we've reduced this number of defects. We've ran these security scans. We've done all of this great work. Somebody approve our release." And that's taking a whole lot of time from some of your most talented and successful people when we're spending hundreds of thousands of dollars in meetings validating this stuff, when the reality is we have the data, we could look at it, we could trust it, and just start to lean out a lot of the different inefficiencies that we have on a regular basis so that we can start to trust our processes a little bit more, we can start to trust the data a little bit more, and really start moving towards embracing, hey, if we're going to do all this time, modernizing our applications, embracing Kubernetes, embracing microservices, we should be able to push a button and push those things out whenever we want and have peace of mind of knowing that that's not going off the rails. And I think the only way you can really start to embrace that and celebrate it is if you've got visualization of that entire process and you know you've got the right safety checks in place. So then you're not losing sleep over it

Jeff Keyes

[5:46] Mm-hmm. And I think another problem is we've all been hearing all these benefits of, "Go DevOps. Go implement CI and implement a new way of testing." It's not that these things are bad, it's just it may not be your slowest and biggest pain point in your entire delivery process. One of the things that value stream management really focuses on is take a look at the whole process. Does it really matter if you take your build time from 12 hours to two when you're spending six months ideating over the things you should build or another six months to deliver? As you said, Steve, from when it is checked in, now it's still six months to get through the process. Man, focus on the right stuff. And I think the power of using these metrics to run micro experiments, to run evaluations of those choke points and fixing them, that's where this is all changing. I think there's one other point. We've long had it beaten in our heads that software development's not a factory. It's not just a simple process. Things are changing all the time. We have to stitch these pieces together. The idea that why not use metrics and tooling and bring this data together is now this big aha. Like, "Oh, I get it. That's what value stream management does. Now I can have visibility." So all of a sudden it's a hot topic.

Helen Beal

[7:02] Okay, so we're kind of saying that maybe people aren't that dumb, but they're flying blind, which is not really their fault. They just haven't been given the data that they need. But it sounds like we're still doing some pretty daft things perhaps. Steve, you mentioned CABs then. CABs, are they a stupid thing to do? Or if they're not, why do we do them if they just get in the way so much?

Steve Boone

[7:21] Yeah. No, I think we need to still have... It's always good to be able to look back and say, "Okay, yeah, we're doing right by the business." Right? We're making sure it's always good to double-check risk, but at least a lot of companies that I've worked with, these meetings go on all the time for every application. Sometimes they're week-long meetings, and you're going to come back in and justifying your release process and justifying your quality. We should just be able to trust those. When I think about things that we could do to really improve time, we'd start looking at business alignment, right? What are we working on day to day? Is it actually aligned with the business goals? How do we prevent things like unplanned work from coming in and taking us away from our key objectives that we want to deliver? Now especially something like 2020 when more people are working remotely than ever, we find ourselves getting pulled away from different tasks. People need help. We don't have that single place where we can really come together and say, "Hey, here's the company strategy. Here are the goals. Here's the alignment that we want. How do we make sure that every time that we're checking in code or writing code, that it's valuable, that it's what we should be spending our time in?" And I think that if you can start to eliminate some of the waste and automate some of the governance checks around the CAB, if you can get the team aligned on the prioritized thing the business wants, then all of a sudden you feel a little bit easier to go, okay, yeah, use those tools that you want to use. Take whatever processes you want to do. Experiment with two-week sprints, one-week sprints, whatever it might be. But the business still has peace of mind that we're not putting them at risk and putting it at jeopardy. And we're not just going through a process of rubber-stamping some of these things, right? We've all been in those meetings where they're like, "Well, have you ran your security scans?" Yes, absolutely we did, and we probably did, but no one in these meetings is analyzing them. No one's really picking through them. They just want to know that you ran them. So how can we actually really go to bed and sleep well at night knowing that the place isn't just a hot mess, that we can actually put good quality software that's going to delight our customers and make them happy and actually deliver value.

Helen Beal

[9:12] It sounds lovely, Steve, but I've got to tell you that a lot of people feel that their business and technology teams are not that united. So what does the person do if they feel that there's the business and a completely separate part of their organization that is the technology team? So Jeff, any insights into the business-technology divide?

Jeff Keyes

[9:33] Well, that's kind of the funny part about this whole world that we live in. When I started being a developer, one of the best pieces of advice I got was, "Go work at a small software company because software's the product, that is the business." And it's funny that now we're starting to be in this world where we're realizing that software really is the business of every company. Who would ever thought that we'd live in a world where the differentiating feature of a car is its software, and yet here we are. We got customers where they're a power company, yet they're producing things that are in-home monitors, street-based monitors, and the software that drives it is the differentiator. Software is eating the world, and as soon as we realize that, that changes the story. Now, the next cultural shift isn't just that software is one of the primary focuses that we deliver, but it's that we're all delivering that value across the value chain. And helping people see the entire value chain and doing something like a value stream mapping exercise is really effective to bring the whole pieces of the puzzle together.

Helen Beal

[10:36] Funny you should say that. Have you been looking at the questions then? Gloria has asked us a question. Gloria would like to know what is the difference between value stream management and value stream maps. And since you said value stream maps, you can start us off there.

Jeff Keyes

[10:51] Well, I will. A value stream map is an exercise. It's a workshop, if you will, where you put people in a room that are involved in the, hopefully as broad of the delivery cycle as you can get. And it's an exercise of evaluating it step by step. Actually, on the Plutora site, you and I have done webinars on that topic, Helen. You can go read all about that and watch a webinar on that exact topic. Highly recommend it. Most importantly, not for the efficiencies that you'll gain, but for the alignment that you'll get of the entire team on one goal, and that's delivering software value. Value stream management is the set of practices, tools, and culture, if you will, that come together to manage the entire delivery from beginning to end that integrates into the tool chain that you've got, where you can implement those changes that you've defined in your value stream mapping sessions.

Steve Boone

[11:50] Yeah. Two things. I'll try to condense the previous question in a little bit more to this. We talk about the value stream mapping, right? And one of the questions you talked about was, how do we bridge that gap between the business and the people? I'm doing a talk later this week, on the third day, on humanizing DevOps through data. Right? And to Jeff's point, when you start looking at the whole end-to-end spectrum, it gives people more empathy of what it actually required to release quality software that makes our customers happy. So what am I talking about there? Well, I think it was DevOps Institute earlier this year put out a whole report around this idea of human skills in DevOps and what employers are looking for. And some of the top things that they're looking for are in these, what we call E-shaped type skillsets. Right? Which means people have experience, they're energized, they're ready to go out there. They're not just T-shaped, which means that they're broadly focused on, or I should say, broadly knowledge of the company, and then specialists in one. They're much more well-rounded than that. And part of the way that we do that and help people become from T shapes to E shapes is actually by exposing them to everything that it takes to get that software out. So it's not just about engineering did our part, QA did our part, design did our part, operations is doing their part, but they understand the business requirements. They understand why each part does the things the way that they do, what their expectations are, what their management thinks, how they're being bonused and credited on their own work. Mm-hmm. And when we look at the whole bigger picture, then all of a sudden it's a little bit easier to go, "Hey, you know what? This is challenging. We need to work together to solve this problem. It's not a development problem, it's not an operations problem, it's a business problem." And that to me is a huge light bulb for a lot of companies. They think today we're doing DevOps, we're doing a lot of the tactical things, but where they really struggle is the culture side of it and actually being able to work together to bridge those gaps. So that value stream mapping exercise that Jeff talks about, that's huge. It is as important as a retrospective. Some companies are only doing it once every six months, if that at all, and we have an opportunity now to actually digitize that, make that an everyday conversation, make that something we live and breathe.

Helen Beal

[14:01] Okay, so I was about to make that point, that it sounds lovely, this value stream mapping exercise, but I think most people feel that they spend far too much time in meetings anyway. So how do we make it easier for them to do that continual inspection and adaptation? And I think you've just said that we digitize it. So Steve, can you expand on that point on how that helps people pivot and persevere?

Steve Boone

[14:24] Yeah, absolutely. Think about all the tools we interact with on a daily basis as an engineering organization, from source control to ITIL, to issue tracking tools, CI/CD, you name it. How we engage with those tools, the digital fingerprints that we leave behind actually tell us a lot about how we form and storm our normal everyday activities. A great example is working with a team who essentially was struggling on code reviews, and they were wondering, well, work would get finished, but it would take so long for it to get reviewed. And it wasn't that people weren't doing code reviews, it's just they didn't have enough people to actually be a plus two code reviewer, right? It was a management delegation on the team of who could do what. And when your senior people are getting pulled into fire drills and they're getting pulled into other directions and they have to explain to management what's going on and why, they're not always around to do those types of code reviews. So those little pockets of waste, right? When we look at where the work actually sits, where a work item gets held up, is what's our work in progress? Right? Are we taking on too much work? That kind of information, that kind of visibility, by digitizing that, we can easily come in as product managers, as development managers, as C-level executives, search for the things we care about, search for the business value. We said we were going to deliver a new front end in 2020. Where are we on that? Right? We get these big business goals to get broken down into sometimes hundreds of various different work items. So where our team spends our time, how we interact with those work items, how we interact with the code changes, all of that can be visualized and bubbled up to give us this really unprecedented visibility into how our teams actually work.

Jeff Keyes

[16:00] Yep. I think there's a-

Helen Beal

[16:02] Tools, tools, tools. Oh, yes. Tools, tools, tools. Question from Carlos. Are some companies simplifying VSM as a tooling issue?

Jeff Keyes

[16:13] Oh, for sure. Can you make- Just buy a widget and you're good. Yeah, no. A tool isn't going to solve your problem per se. The tool is an enabler, but you have to combine that with a whole bunch of other things. Just like Jez said, culture eats process for lunch. The point is, is there's a culture here that we're working on transforming along with architecture, process, trust, and everything else. The cool thing that value stream management gives is visibility. Visibility creates that collaboration and efficiency that you need. What's going to change the culture is when you can run these experiments or have the ability to compare different teams and team styles and say, "Hey, this one's working." And then ask the critical questions that would be part of the cultural naysayers, if you will. Oh, they can't be secure enough. Oh, they can't be compliant. Oh, they're not going to deliver the right kind of quality. Oh, whatever else is in there. And you know what? When you can correlate their MTTR, you can correlate their bugs escaping into production, or even correlate it to customer sat and correlate it to your net promoter score, oh my gosh, you're now proving something. Hey, this is the new way. And everyone has that same goal in general of wanting to deliver value to their customers. And if you can show it's being done here and it's being done well, you might still run some experiments that aren't successful. You know what? A faster you get to quote unquote "failing," the better. And that's what the metrics are for.

Helen Beal

[17:51] Well, you should- So the vision you're painting here- I'm sorry, go on ... Sorry, Steve. The vision you're painting here, guys, it's beautiful, this beautiful place where we can see everything. But these teams have been building these DevOps toolchains. These teams have got tools already that tell them about their MTTR, their service desk does, for example. We know about the ideas. They sit in the product backlog. So don't we just need a dashboard, Steve?

Steve Boone

[18:15] Yeah, no, that's exactly what I was thinking. The last thing we need is another dashboard. Absolutely the worst thing anybody could say is, "Let's put up another dev pit dashboard." If you don't have any, great, cool. But it's not about the numbers, right? If you're looking at just MTTR, if you're just looking at lead time and cycle time, those will give you a general sense of the health of your value stream. Right? But I bet that most people listening to this right now, if I asked you, "Hey, what do you think about your value stream and the quality of it?" You could probably put a finger in the air and ballpark and we have some issues. Right? Mm-hmm. Now, the rubber meets the road when people talk about, well, what are the real issues? How do we fix them? Right? Now, all of a sudden, instead of people saying, "I think," we want to be able to say, "I know," because we're trusting the data, the data tells us. So to me, it's not about a dashboard. It's much more than those things, right? It's about throughput. It's about distribution. So what's your velocity? How many story points are you able to get done? That's great. But also, what's the breakdown of those? Are we delivering more features than we are defects? Are we working on things the business actually cares about more frequently? If our throughput's through the roof because we're just knocking out defects all the time, we're really not delivering a whole heck of a lot of new value to our customers. Right? So there's a lot more there. To me, it's not about a number. The magic is in the relationships. It's how all that data fits together. It's how you can look at lead time, cycle time, MTTR, with the number of contributors you have, with the number of defects that are going out the door, with your distribution. All of that together tied with your quality results, your security scans, that's going to give you a way much more broader representation of actually how healthy and successful a value stream is. And if you're making business decisions on, we want to put out this new feature, we want to invest, or we want to build this new application, wouldn't it be nice to be able to know, well, what are the best frameworks that we can build upon? Where is our best experience? What's our most healthy value stream? What's our best way to get from idea to production? Because then I already know that I've got a leg up. I can already say, "Hey, we've got a lot of expertise in this area." We might even be able to look at, do we have people in this area that are available right now to help us? Those are the types of insights that we start gaining that aren't even necessarily at a developer's mindset but are more rolled up to executive-level decisions.

Jeff Keyes

[20:24] Exactly, and if you think about the foundations of what makes up a value stream management platform, Steve, you know you were talking about that you need a common data model, a common way to look at every tool across the tool chain- Sure ... that you can ingest data and stitch it all together, correlate from planning to build, dev, test, all the way through the release, whatever the criteria is, and on into production, so that you can see the entire journey and then measure it from predicted value to what actually happened. And that correlation, that's the magic. That's right.

Helen Beal

[21:00] So that's about flow, I think we're talking about here. So we're talking about the visibility of the work as it travels through the end-to-end system from idea to value realization. But we have a question from James. James wants to know, does maximum value require visibility of features from end to end in the value stream? I think this is an interesting one because it's not just talking about speed, it's talking about prioritization. Mm-hmm. Steve?

Steve Boone

[21:24] Well, and then I read that, too, the visibility of features. We're talking about I made a release, there could be some feature flags that are on and some are not. I want to be able to look at what's the performance of some of those features. So absolutely, right? I think that's where this space is growing into, is really start saying, "Hey, I pushed out some things," or, "The system is live right now. Which feature flags do we have on there that are actually high-performing that we feel confident in compared to which ones I don't?" And who's taking advantage of those different things, right? That to me, again, start talking about that fast feedback cycle. That's extremely important.

Jeff Keyes

[21:57] Yep. I think there's a trend, too, from a product perspective that just as much as we don't measure our developers on the number of keystrokes they press, we're not going to measure our delivery teams by the number of story points that they produce because really if you want to take an entire team and make them more successful, just increase your story point estimates, and voilà , you're now more successful. The point is we have to look at the actual value delivered and what does that actually mean. There is a prioritization, but we want to maximize that flow through the pipe and make it the most efficient that we can and measure the value that comes out the other side.

Helen Beal

[22:35] So I love that, that we can stop gaming the system. It's like with Steve, what you were saying about data-driven conversations, not opinion-driven conversations, I think.

Steve Boone

[22:42] That's right. Yeah. No, that's 100% right, and just that other idea of features and end to end. If we are tracking the features, if we know where our features are at any given time, or that breakdown between here's my epic and here's all the linkage between the stories and underlying behind that. Now, all of a sudden, we can come in from a business perspective and say, "Well, where is the business value? Is it 30% done? Is it 75% done?" We could have clearer, cleaner conversations and set expectations accordingly with our clients. Right? We can say, "Hey, here's when we think this will be done." And matter of fact, we can actually say way more clear than that, "Here's precisely when we believe it will be done." Right? Because we already know. We've got such clear visibility, and it's so much better than a conversation of just going back to your product managers and going, "Ah, it's probably going to have to wait in one more release." Well, why? Mm-hmm. Why? So often, we just go, "All right. That's fine. It slipped. We'll get it in the next one." But why? To me, that question of why something might slip, what else were we doing? We were probably spending our time on important stuff, but we should know that. We should be able to plan for that. So this idea of being able to plan for the unplannable, it's not impossible to do. We can start looking at just the way that we track work items for planned work. We also track incidents, vulnerabilities, support tickets- Mm-hmm ... as they come in from our customers. And so being able to look at how our teams manage that work, who's available, how that all bubbles up, that-... directly correlates to how much business value you can actually deliver per sprint, per release, per quarter.

Helen Beal

[24:18] So you mentioned agile and epics there. I don't know whether you've caught sight of that next question from Keith, but I'm going to draw our attention to it now. I think it requires us maybe taking a few steps back actually and thinking about what a value stream actually is, which we haven't talked about yet today. So for the uninitiated, what is a value stream? Because what Keith's saying is that a value stream is like an agile epic versus user stories. So he's saying that we can get very large value streams that we may need to break down into pieces.

Jeff Keyes

[24:48] I completely agree with that. In fact, it's like the story of the blind men describing the elephant. If you're trying to describe, it depends on where you're coming from. A way that I like to think of value streams or describe value streams is if you take all the stuff that's happening with agile, and you take all the stuff that's happening with DevOps, and you add some connectors to the outside for the inbound expected value and some connectors to the after you put it in production to adoption, NPS, customer sat, and other value-related metrics, that's value stream management. In essence, it acts as a control plane across these agile release trains following every step of the process from ideation to production.

Helen Beal

[25:30] But what's an actual value stream? And you know I like to use the definition, it's anything that delivers a product or a service, but- Mm-hmm ... am I massively oversimplifying it, Steve? What's a value stream?

Steve Boone

[25:41] Let's look at a practical example, right? Take a single team that's responsible for delivering an application. There could be many different parts to it, right? They probably know the different components that they're building for that application. Depending on how that team is structured, there could be multiple value streams there, right? If that application has four different core parts to it, and there's different small micro teams within that that are responsible for those, they could have different value streams. Documentation, design, all of those groups that we interact with to get software out the door have their own value streams. So if we want to make a prediction or tell the business a commitment on when we're going to get something done, well, what does done mean? Done means it's ready to go. We can push it out the door. We have the documentation. We have all of the marketing collateral that we need to get done. We have all of your support ready to go. All that stuff has to be considered. And so when we want to push a product, we want to get that out that door, we want to have an idea of what are all these other value streams? How do they impact what we're doing in engineering? So yeah, there's several different ones, and it's important. We look at it as, I try to break it down into let's get as granular as we possibly can, right? So it makes sense that if you've got a small documentation team that's just writing documentation for this one application, guess what? They have a backlog of stuff that they work on, and they want to track that. And if we're going to say, "Hey, when are we going to get this latest documentation up?" Is it going to be in line with when we're pushing the software? Would be really good to know, right? Not guess, not hope, but actually know and plan for it that way. So 100%, you're going to have a lot of different value streams, and I encourage all the teams to manage, make them responsible. They will want to manage their own value stream. They're going to get enjoyment out of managing their own value stream because it's going to allow them to see all the inefficiencies of how they operate with different parts of the organization today.

Helen Beal

[27:27] Sounds like an anti-pattern to me, having a documentation team. Going back to your E-shaped question or-

Jeff Keyes

[27:34] Or just completely do away with documentation. There we go.

Steve Boone

[27:38] Tell that to my customers.

Helen Beal

[27:41] But you bring up a good point. I want to take you back to a question that I'd kind of skipped over that came from the audience. You talked about E-shaped people in the context of the DevOps Institute upskilling reports earlier on, and James... No, not James. Nick wanted to know, is this E-shaped skill set related to what Gartner is calling a versatilist? So yes or no, and then perhaps why multi-skilled people are important when we're trying to do this stuff.

Steve Boone

[28:09] Yeah. I don't know specifically the question from the Gartner report, but when I think about E-shaped skill sets, what we're really talking about is people that not just have the technical chops to do the thing that we hired them for, but they have the ability to be successful collaborators within the business, right? They're able to go out, they're able to work with the different parts of the organization. They can represent themselves, their team, others, and instead of just having a little bit of an idea of how that works, they're interested in it. They want to be engaged with the other parts of the business. That to me is a solid E-shaped skill set. A lot of that comes from experience in being curious about the different parts, willing to experiment on how you interact with those various different groups. So it sounds like there's overlap there without actually knowing what Gartner has defined it as. I hesitate to say yes, that's the thing. But that's the way I look at it. We're going to be talking a whole lot more about that on Thursday this week. Really just about how data in general helps make people feel more connected in a day and age where we're definitely not connected. We're the least connected we've ever been, at least from a human-to-human conversation standpoint.

Helen Beal

[29:21] Jeff, is value stream management humane? Steve's claiming it is. Is it humane technology?

Jeff Keyes

[29:27] One of the biggest fears that people have of interconnecting their tools and having it come up into anywhere central is like, "Oh my gosh, people might see that we blah, blah, blah." It's not as fast as it could be, and I'll have big people come and beat on us with sticks. Right. The whole culture has got to change. The best part that anyone, especially if you're on a team, can do is to say, here's a baseline. Maybe you don't promote the baseline, but it's what happens after four months after you've made some pipeline differences and you say, "Look, we increased our throughput by 3,000%."No matter where you were, that's the number that matters. We improved our quality by X percent. We improved our adoption, our customer sat score by X. Those kinds of things are hugely not only validating, but exciting as a team because we want to deliver stuff. Is that humane? Absolutely. I feel like so often the problems people run into of culture are, it's the psychology of how do I make this happen? I can't because so-and-so's over here and they didn't let me, and I can't get access to. You do a value stream mapping session, all the ideas pop out, and everybody's like, "Well, that's stupid. Why are we doing that?" And the whole team gangs up on the stupid things that are happening. And then you have a chance to actually prove it. That's powerful and that's frankly really humane.

Steve Boone

[30:55] Yep. No, I completely agree. To me, that's the beauty of the value stream as I look at it is just how we communicate in an individual daily level with a small team. Especially if you're a team that's not used to working remote and you've always worked in a central office together, it's really easy to turn around and raise your hand and say, "Hey, can I get some help on this?" Or, "Hey, can somebody look at this?" You could say, "Oh, we've got Slack. We've got all these different tools. I can just ping people for help." But when the fire drill happens and we need people to help right now, we need to get on with a customer, that unplanned stuff, that's really hard to manage right now. So what's going to drop on the floor? We only have capacity to do so much as a team, and so we need to make trade-offs. And if we want to make trade-offs, and we want to say, "Okay, I need these two people to go help this customer because we have to solve X, Y, and Z," okay, well, whatever they're working on needs to either be covered or we're going to make decisions that it's not going in the sprint. But how are we going to justify those? What are the impacts of those decisions? All of that's extremely harder to do. It has consequences. People like checking things off their list and feeling like we got that done. So at the end of the day, if we can show everybody the bigger picture and why certain things are happening, why they're not, it just makes it a much easier conversation to have. We don't find ourselves repeating or justifying ourselves to everybody. And to me, that is extremely humane because right now one of the things that I think everybody struggles with is just that overall, where are we going? I feel isolated. I feel alone. When reality is we're not. You're working with a team of people to solve really challenging problems and bring great value. Let's not lose sight of that. And to me, that's one of the biggest things we can do is by making it visible is we're making sure we're not losing sight of any of those things. We're not losing sight of quality initiatives. We're not losing sight of security initiatives. We're not losing sight of business goals. Everything's right there at our fingertips for us to query and look through.

Jeff Keyes

[32:40] Yeah, to put a more finer point on it, can you imagine how humane it is to the team that's currently being managed to story points delivered, and there's a developer there that's like, "You know what? I want to improve my pipeline. I want to do more automation, more test upfront, discover problems before they get to production," and having some test team that's trying to repeatedly over and over test the same features, and hopefully they find all the problems, and I'm going to go automate it. And yet what's inhuman is we're going to penalize that guy because you didn't get enough story points done. That's right. Yep.

Helen Beal

[33:12] Okay, well, we're talking about connections, we're talking about discoveries, so making local discoveries and turning them into global improvements, I think, across teams. And this question reflects back to something Steve said a few moments ago as well about the complexity of value streams and perhaps that value streams may look separate but have pieces or things in common. So Roman has asked, "Is value stream component reuse count in different streams a good performance or value indicator?" Thoughts.

[33:44] Component reuse count I'm guessing is, hey, we've got a component that can be reused across many different applications. That's how I would interpret it.

Steve Boone

[33:53] Yeah. And I think what you could look at is that there will be data that would show, as long as that team can deliver consistently high quality, that the teams consuming that component won't be negatively impacted. But I would think if you know you have a package or a group or a single reuse component that's being pulled in by tons of stuff, boy, I would really want to make sure that's got a really good value stream around it. I want to be making sure that the security scans that they're running are running often, that the quality and security tests that they're running are published and we know what they are. And I'd want to make sure that we're gating for improvement on that. It's going to be hard to go to any team and say, "Hey, you need to have 80% code coverage," unless you started with that in mind from day one. But you can go and say, as Jeff, you were talking about, what's the current baseline, and how are we going to get better? If it's 25% today, can we make it 26 or 27 by next quarter? If that's a goal for us, we need to plan appropriate, we need to take in those goals into consideration with the business's goals, and we've got to juggle and weigh those appropriately. But I think having all of that visibility would allow you to know that if you've got that individual component that's being pulled down and it's a poor quality value stream, that should be a red flag. You should want to fix that right away. I want to ask if we should be talking about applications anymore in the context of value streams, or whether we should be talking about service components.

Jeff Keyes

[35:17] Yes. Thanks, Jeff. Next question.

Steve Boone

[35:23] I might even say just the people representing those service components. I get back down at the end of the day, all of those things, there's people behind all of that, and I think that's an important part as well is that we're more than the IDs or the services that we log in with each day and to put these things together.

Helen Beal

[35:42] Okay. There's a great question here from Denver. Can you correlate dollars, dollars saved from outages due to defect reduction, dollars generated by new features, by retaining clients, getting new clients, and if features were additional billable items? Can we visualize that too? Can we put the dollars on the board, people?

Jeff Keyes

[36:01] Yes. I'll give you a couple that are really interesting. One interesting aspect, a sub-piece of the value stream is test environment management. I think it's one of the Achilles' heel of any DevOps transformation.We actually have a good piece that was done by EMA on calculating the dollars of it, lost time, downtime, lost development, and so forth. I think as you look at the quality and the software quality problem, higher quality is less expensive to maintain, and there's plenty of stuff that's been researched and presented along those lines as well. Huge business case for implementing value stream management, frankly. Just is. Go ahead, Steve.

Steve Boone

[36:51] No, the answer is absolutely. I think the question is when I talk to a lot of people that ask me that question, my question is, "Yeah, where's your data at for that?" And that's the challenge, right? People will go, "Yeah, we absolutely can do that," right? Because if I can look at, hey, you had a customer, they were on version X, and then they signed up because you put out a new version, went on that, great. But that information's usually hard for a lot of clients to bring to me. Now, what we can do is we can look at what's the value stream costing you to operate, right? If we can look at the number of contributors you have, just from a straight engineering perspective, what's it costing me to run this thing, right? You could look at something simple like headcount. But if we can start showing that over the course of leveraging value stream management, we were able to identify and reduce the amount of time it takes for us to handle outages, to identify and fix security vulnerabilities. I think you can make a huge case and actually show that the things we're investing other areas is a good payoff. For me, when I started getting excited about value stream management, it's because I had people coming to me and saying, "Steve, we've been doing DevOps for six, seven years. How do I know I'm getting the ROI out of it? How do I know that the things we're doing are actually beneficial to the business, that we are delivering faster, that we are reducing the amount of bugs?" And so we started saying, well, we have to track that. We have to show that. And so putting cost around it, absolutely. It's just a matter of having the data.

Jeff Keyes

[38:10] If you're going to do a presentation to management and you want to have a case, have one slide, just one slide with this quote, "The price of light is less than the cost of darkness." That's deep, man. Nice. Very deep. There you go.

Helen Beal

[38:29] So rather than having one slide for leadership, and we all know that leadership only care about their KPIs and bonuses anyway, but rather than having that one slide, would we not be able to just show them a live screen showing them the incoming value of the product and the current cost of it?

Jeff Keyes

[38:45] I think that's the whole point is showing visibility in what's happening in the pipelines. Where are things going? How are they improving? Because at the end of the day, people just want to see that we're improving, and that we're doing better than we did before, and we're delivering more than we did before.

Steve Boone

[39:00] Yeah, and I think the thing that really, I just speak from my own experience at the companies I've worked at, the question is, "Hey, you said you were going to deliver this thing." Mm-hmm. "Where is it? How did we do it? And if not, what's holding it back?" Right? And then even from those perspectives, those are sometimes hard questions to answer. People don't want to hear excuses. They want to see the actual data. And so anytime you try to explain the well, and I think, and the buts, that's a little bit harder. But if we just show you transparently where we spent our time, then we know. It's spoken for, right? And I think the reality is engineering is pulled in a million different directions, and at the same time, the business is constantly changing their mind on where they want to go, what their new priorities are, the new things they want to chase. And so how do we balance all of that and go back and prevent that conversation of engineering going, "Well, we could've got it done, but then you guys wanted us to do X, Y, and Z," right? It's like if we've got clear understanding of where we're going, then we can prioritize ourselves accordingly, and the business, I think, respects the heck out of that.

Helen Beal

[40:03] Let's go back a couple of steps. Let's talk more about business and leadership. Jeff gave us a great example of how to sell to leadership, and I made a very flippant comment about how leadership only cares about their KPIs and their bonuses. What do we do with our leaders if we feel that they're not listening to us? We've talked about the message, we've talked about the data. How do we get that clarity of alignment that you're suggesting, Steve, through the whole value stream, like blurring that gap between business and technology?

Steve Boone

[40:37] How do we use value stream management to align the CEO's goals with my user story? Yeah. Well, not only just the CEO's goals, right, but our clients and our stakeholders as well. And so it's just about executing the same things we've been doing, right? We should be taking that feedback and the kind of driving goals that we have. Those should be in tools like Aha!, they should be epics in tools like Jira. We should be tracking them somewhere. I think the problem is they tend to fall by the wayside. How many of us are dealing with backlogs right now that are just not super clean? Probably plenty of unprioritized stuff back there, and every time we go to draw up another sprint, we could go, "Gosh, there's no shortage of stuff to do around here, is there?" And that becomes, I think, the overall underlying problem is if we can just look at that thing, if we can start coming in and each week I can show you a swim lane of the work that is already planned and prioritized, who's working on it where, and I can watch as they kick off builds, commit code, run tests, that piece of value flow through my organization. Cool, because I also get to watch where it stops, where it gets hung up. And all of a sudden it's like, I'm coming in, I'm looking around, and I'm saying, "Okay, where's this epic? Well, three of these things have been stuck in development for three days. There's only two days left in the sprint. That's probably not getting done. Why? What's that person do?" And it's not to point a finger, it's just as a whole, we need to have each other's backs on a lot of stuff. There's always things flying by. So if we truly want to make something a priority, we have to do that. We have to free people up to get that work done. We can't have them being pulled and ripped in a million different directions. And so I think there's still some work that needs to be done. We're trying to take that a step farther by looking at integrating with tools like Aha! to say, "Hey, here's the big ideas. Here's the kind of two, three-year plan that we want to go for." If we can bubble those things down, we can start to pull that information in, and we can start get teams act on that more readily.

Jeff Keyes

[42:28] Yeah, I completely concur with that. Steve, you and I are both vendors in this space, and I'll tell you one of the most powerful sales messages we have in our sales motion is to say, "Here's one of the dashboards you can have that show you light, show you visibility of delivery, and here's the number of story points you delivered, and here's the correlating effect. And you can trace it all the way back to the initiatives that were started with at the beginning." Yeah.

Helen Beal

[42:56] So there's a question here that's very pertinent to what you're talking about right now. So Joe asked, "I was wondering if there's any part of value stream mapping dedicated to decision making and the process inherent to it, so stakeholder involvement, discussion, and validation." So I think what he's referring to here is the fuzzy front end. So we've just talked about Aha!, so let's talk about value stream mapping. So as we all know, it's a tool from lean manufacturing. I think what often happens in our industry when we use value stream mapping is people start at the developer task and look at it as a CD pipeline. Yes. How do we use value stream mapping to get into the fuzzy front end?

Steve Boone

[43:34] Yeah. The fuzzy front end, I think, is where all the interesting stuff happens, right? Because it's where we have a ton of good ideas, and we have to weigh the pros and cons with other investments that are going on within our business and with our clients. So, the data's there. As long as we have it, as long as it's sitting in these tools, we can pull it in. Your value stream isn't linear. It has different shoot-offs all around it. And so it's not just a pipeline. We like to think of it as a build. I build, I deploy, I test, I release. There's literally a million other things going on that aren't represented in those things, right? And what I always tell folks is we want to get as granular as possible. We want to outline our value streams to mimic how we communicate about work on our day-to-day basis. So you just don't say, "Hey, we built it." Before that, there was probably a code review or two steps through that, right? We should look at those. How do we communicate it? We say, "Hey, this needs code review." Well, in our team, that's a plus one, right? And if it's going to pass code review, that's a plus two. Our value stream has bubbles that represent plus one and plus two because work gets stuck there. Work can sit there. So any place work might be, we need to represent it. And if there isn't a tool today that I can tap into to represent that work, then we have to provide the APIs so that you can get it in there one way or another so that we can start tracking it, right? And so that's really where it's at. It's all about integrations. The better the integrations, the better the data, and the better we can represent how it's flowing through the organization.

Helen Beal

[45:02] True.

[45:02] You also mentioned swim lanes a little while ago, Steve. There was a question from the audience, this is from James. "Is there a correlation between Kanban and VSM?"

Steve Boone

[45:16] Yeah, absolutely. And not only Kanban, but Lean and Agile and in a number of different ways, right? I look at all of those different methodologies as trying to provide the business with agility, right? You're trying to say, "How do we do more with less? How can we plan something that we want to get done, but still be flexible in case things change?" And all of these different styles and methodologies you use really are trying to say, "Hey, we can help you do that," right? Here's some best practices around that. So regardless if you're doing Kanban, regardless if it's just straight Agile, there's all different ways that you can help and just kind of visualize that work. But when we look at a swim lane, at least with our representation of it, absolutely, we think about it as a Kanban board. Really hard to go move, and I know a lot of teams have started visualizing their Kanban boards, and then it's nice to be able to move that physical thing across the board when you're done with it. But when you're looking at doing it across hundreds of applications in your organization, and you really want to be able to search, query, identify, highlight, and track those different pieces of information, it's really hard to do that with Kanban boards. And so there is some aspect to that. We want to show that work moving, who owns it, where is it at, all the way. That is a core concept and a core visualization that I think a lot of folks are driving to. But to me, it's about being able to roll that up so it's just not a single team or a single service or application, but it's for an organization. You can split that apart, right? Yeah. Hopefully that answers that question. It's a really good question. Yep.

Jeff Keyes

[46:42] I think the point, one of the core tenets of value stream management is to be indifferent, agnostic, not caring about what the development methodology is. Whether you're Agile, Waterfall, or all points in between, it's agnostic for whatever level of DevOps automation and processes you are. It doesn't care. The point is, is that you've got metrics which just are. In the larger enterprises, you've got decades of M&A, divestiture. In some banks for example, or power companies even, when they talk legacy systems, they might be talking about something that is 50 years old. Oh my gosh, I complain about stuff that is nine, eight years old. I can't imagine some of these systems that have been around that long. And yet, does it make sense to modernize these? Maybe, but maybe not because there's not that much investment going on there. Maybe it's just keep that system alive for however it is. Should you not bring in metrics of it? No, you actually should. At least then you can have some visibility and see what's happening as you correlate these different value streams together as they go on into production. You need still the visibility to see what's happening.

Helen Beal

[47:57] So I'm enjoying these conversations we're having about kind of nested and branched value streams, and there's a question that's come in from Raja as well, which is, "Any tips to reach into silos to get their value streams to feed into the overall value stream?" Kind of like a value stream of value streams. Does that remind anyone of anything?

Steve Boone

[48:18] Sound like the team of teams talk we heard earlier today, right? I mean, that's-

Helen Beal

[48:22] Scrum of scrums

Jeff Keyes

[48:23] ... there's a big thing of that. Yeah. Yeah. 100%. Absolutely. 100%.

Helen Beal

[48:26] And I kind of feel like silos, we know, are an anti-pattern, and I kind of feel like the whole purpose of thinking like value streams is to break those silos- Mm-hmm ... and make them into a tube instead of a load of bubbles.

Jeff Keyes

[48:42] Look, there's absolutely value in every single team just starting for themselves, because if you want to break down silos as you've moved from project-oriented to a cross-functional product-oriented team, you're now, we build it, we own it, we own the delivery, the maintenance, everything. We care about what we deliver. So start there. I think it will create sort of a desire for other folks to say, "Well, I want that." There sort of feels like there ought to be a you might be a redneck if kind of talk about you. You might need value stream management if you're tired of getting asked the question of, "When's that feature done?" You might need value stream management if people keep trying to figure out what the quality of the release is and when is it going to be done. You could probably go on and on for all these questions that are silo-oriented kinds of questions. Because if you're seeing silos, the answer is implement a system where all that data gets brought into a common place. That's called value stream management.

Steve Boone

[49:46] Chris Nowak, who runs our advisory and adoption at HCL Software, comes from a highly regulated banking industry, and he used to love to go and tell his teams, "Look, if you buy into the way that we're trying to operate and you want to get people to support you, you've got to show them what the trade-offs are." Mm-hmm. So he'd like to go and tell people, "Look, if you want me to keep audit off of bothering your team, let me automate your processes. I will take care of audit for you. You won't have to spend any time talking to audit." And that was a great way that he helped get people bought into saying, "Okay, hey, we're going to let you help us try to automate some of our stuff." Value stream is a similar thing, right? It's a give to get relationship in just damn near everything we do. So what can we provide people, especially engineering teams? Well, obviously, we talked a lot about visibility. Developers want to get better. They want to do the most efficient job that they can. This will help them with that. I also think that if you say, "Hey, if you want us to keep the release engineers off your back and asking you 30 questions before every couple of sprints that we want to push out the door, this is a great way to do that. If you want to spend less time in your CABs, this is a great way to do that. If you want to make sure that you don't have to go and vet every little thing you do and explain every little thing you do because it's already out there, people already understand security. The CISO knows what you guys are up to, right? Quality leads know what you guys are up to. This is a great way to do that." All you're doing is helping be a better communicator. And I'm not poking any fun. We don't have a lot of great communicators on all the engineering teams that I've been a part of. And people are very focused on their day-to-day tasks. They're great at going out there and busting out code. We need to communicate. Now more than ever, we could use better empathy, better communication. That's just the world we're in. Call it the new normal, call it whatever you want, but that's exactly what this is designed to do. Right? It's just make everyone's lives a heck of a lot easier and put us all on the same page.

Helen Beal

[51:38] I'm going to take what you're saying and line us up with a question from Eduardo. So the problem is everyone's really busy, right? The problem is what we're talking about is an emerging market, an emerging platform, toolset, whatever you want to call it. So at the moment, we've got maybe a minority of people that have got the proof point it works. And people are just going to say, "Yeah, it sounds great, but I'm far too busy. I'm trying to keep the lights on. I'm firefighting all the time." So Eduardo's made this point about... What he's said is, "Why shouldn't we treat technical debt as any other item in the product backlog?" To which my response as a normal human being, not the devil's advocate, would be, you absolutely should treat technical debt as a product backlog. No question, right? But if he's having to ask that, I'm guessing he's being told that he shouldn't be. So how can he use value stream management to show people why measuring technical debt is important?

Steve Boone

[52:31] Well, I tell it the same thing when I have a conversation with my kids if we're going to the toy store, right? "Buddy, you got $10. How do you want to spend it?" Mm-hmm. Right? "You can spend $2 over here. We can get some candy. Spend $5 over here, we can get a toy. But when will we have $10?" And that's the time that we have, and we got to think of those same kind of trade-offs when we're talking about paying our technical debt. We're paying anything else that we want to get out the door. How much allocation are we going to put towards features? How much allocation are we going to put towards technical debt? Because those are real conversations. And as technical folks, we want to come back and say, "You're crazy. We can't do that unless we do these other things first. We need to pay this debt." That's a hard conversation to have with a C-level executive or some other folks that are really focused on closing that deal and getting stuff done. Right? So how do you make a technical conversation a little bit easier to have? Show them the breakdown, man. Show them the data. The data doesn't lie. Right? And that to me is like the best part about this, is we can come in and say, "Look, if we want to get this done, and we still want to pay..." It's financial advisory for your backlog is really one way you can look at this, right? If you want to pay these things down and you want to get ahead at the same time, we have to pay into each bucket a little bit. And so what better way than to know and prioritize what those things are and actually show that we're making headway on them?

Jeff Keyes

[53:43] Yeah, and the key there is, absolutely correct in the thinking that everything we do or from a product perspective are just features. Problem is, is that when there's a planning organization, they don't think about technical debt, and there's no visibility like, "Oh, there's a bunch of technical debt here we better go fix." The value here is making that visible and transparent, so now it's back of like, "Well, how do I spend my money?"

Helen Beal

[54:09] So we're into our final five minutes. Can you believe it? This conversation is flying by. So I'm going to lead us into tying up, and I think the most useful takeaway that the audience is going to get today based on the questions, and in particular, the last two questions we have from Robin and Raja. I want you guys to first of all explain as succinctly as you can how somebody that's never done it before goes back to their organization and identifies a value stream. And then what the first three steps they need to go through in order to make sense of that value stream.

Jeff Keyes

[54:44] I'll just swing at that. Yeah. How about that? I'll go quickly. Hey, pick an application that somebody can concretely point to, whether it's a cloud solution or a portion of it, what have you, and look at the process from beginning to end. How to get started, pull the people into a room for a couple of hours and ask: How do we decide and create, from idea all the way to production, everything that's required in this process? And every time you hit a step in the process, put a box, go through the value stream mapping exercise. Next step, take the data from the different tools where stuff's being tracked and put it into a value stream management platform and show the data and baseline and see where you're at. While you're doing the value stream mapping exercise, you're going to discover, hey, it's really dumb that over here we do X, Y, and Z. How could we fix that? You'll have little kaizen moments. Great. Fix it. Put it in the tooling for your value stream management platform to have a newer model that will help you through the process. Measure the final result when you get done with the updated process, whether you automated, you changed how you prioritized, whether you limited your work in progress. Whatever the fix was, great, and then you'll see if it was successful or not.

Steve Boone

[56:02] You're spot on. We've got a couple of different e-books available at our booth. One of them is on data-driven DevOps. The other one that we have out there, I believe, is getting started with value stream management and kind of walks through some of those fundamental things that teams can go through to grab some markers and have the whiteboard conversations, when the reality is you could get started this week at the end of your retrospective. You're already asking, "Hey, what went well? What went poorly? How do we improve?" It's a great play. But instead of really honing in on some of those things, I think it makes sense to step out of that, have a whole dedicated meeting where, to Jeff's point, we're just looking and talking open and honestly. And that's kind of maybe the big thing is it's got to be open and honest. What do we think is going on? How do we think the work actually flows through? And I think it'd be really interesting, as you'll see, is people have different opinions about what they think is actually happening within- What? We do what? Right? Yeah, exactly. Yeah. So your little core bubble of people that you hang out with all the time are probably in some sort of alignment of how you think the world is operating. But as soon as you branch out, it's like a game of telephone. It goes completely farther down that road. You start having conversations with the design team, and they start telling you how their process works, who they have to do, who they got to speak to to get stuff out of, what their requirements are, and all of a sudden, you're like, "Dude, I just thought you made the pictures for us and we put them in the product. I didn't know it was going to be that big of an ordeal." There is that all over the place. And so having a conversation with your core group, being able to visualize that, understanding where your hand-offs in the groups you work with are important, then you can come over and say, "I want to work better with you." That's a great way to talk to me. "Hey, nice to meet you. I'd like to work better with you." And if we can have that conversation within our organizations, I think that just sends... Tell me more about how you do your job. That way I can help you do your job better, and then we benefit together. And to me, that, I think, is the great way to go about doing it and getting started is just ask people, "How can I make your job better? What do you do? How does your job operate?" And that'll initially start the appropriate things you need to do to start mapping those things out.

Helen Beal

[58:06] Perfect. So thank you very much. I've been Helen Beal. I've been the devil's advocate today. This has been our vendor love-in. Thank you, Steve. Thank you, Jeff. Thank you for bringing humane technology to the masses.

Jeff Keyes

[58:19] Thank you.

Steve Boone

[58:20] Thanks.