Europe 2022
Connecting Software Delivery to Business Outcomes
Connecting Software Delivery to Business Outcomes
HL
Hope Lynch
Sr. Director, Technology Strategy, CloudBees
LD
Logan Donley
Sr. Technical Evangelist, CloudBees
DP
Drew Piland
Senior Product Marketing Manager, CloudBees
Transcript
Hello, and good day to everyone and welcome to DevOps enterprise summit, 2022, where I'm thrill to be joining a panel discussion for connecting software delivery to business outcomes, which is a topic we in the industry have gone back and forth on. Thus, we wanted to bring together a capable panel to discuss what this means for us at CloudBees, how we envision this within the market, what the advantages are pitfalls and best practices. My name is drew PI and I'm in the product marketing organization at CloudBees. I will be MCing today's session where I will be asking questions to help spur discussion with two of our panelists, who I am happy to introduce Lynch, who is our senior director of technology strategy offers a wealth of experience in the it industry, including time at red hat and Cisco prior to CloudBees, we will also be joined by Logan Donnelley, who is our senior, senior technical evangelist.
And prior to this role was an essay at cloud BS. And before then spent time at both red hat and Dell EMC. Both of our panels have a breadth of experience across industry and different roles, spanning technology to sales, to implementation. And I'm really excited to see where this discussion goes throughout today's discussion. Feel free to pop in any questions into slack channel, where our panelists will be responding in real time. So to get started, as it relates to the topic of connecting software delivery to business outcomes, I'd like to understand why this is important. I think there's a lot of skepticism in the market around what marketing says versus what is actually enabled in product and what people actually care about. So to get things started, um, first to hope, um, why should we care? And what does this actually mean?
Um, one of the big reasons we should care is as has been said, every business is a software business these days. So if you have delivery teams that are working away and maybe they're working really, really hard, but they're working on the wrong things, you aren't gonna get the business outcomes you expect. So connecting software delivery to those business outcomes, understanding how they connect to your strategy is really critical. If there is not a way to draw a Dele, a direct line between those, uh, things you, you won't get, um, maybe the time to market you were looking for maybe the return on the investment, um, in the software delivery teams or even the tools that they're using. So, uh, without that you have a big, huge gap in your company strategy.
Awesome. And I guess Logan, is there anything else that you would like to add on to that, or,
Yeah, so I think it also goes the other way, which is important when you've got all these objectives in your kind of software development teams. If you actually wanna get funding for these types of projects, it's important to be able to tie them to those business outcomes. Cuz obviously the business cares most about how do we keep getting more profit by delivering things to our customers. And if you can't prove that, okay, if I introduce these new techniques, we're gonna be delivering software faster. You're not gonna get the budget for it. So that's just always important to relate those to
Awesome. And I, I think that there's a good segue into the, the next question that we had, um, um, a, a term that in the industry value stream management, and this is something that, um, hope initially I'd like you to dive in first, just to give us a little bit better understanding, um, get a little bit more granular into what value stream management means,
Right? Um, so value stream management, which sometimes is confused with value stream mapping related, but not the same thing. Uh, mapping is you are planning, you are trying to optimize, you're trying to find gaps maybe, right, but management is the active work that a person or teams do to optimize that value stream and making sure that they have the visibility end to end. The most simple way to think of a value stream is concept to cash. You have an idea, the formulation of that idea and all of the touches that happen along the way for that to be delivered. And you start seeing customer value, the things that happen along the way that could, uh, impede that delivery, slow, that delivery, stop that delivery. Um, that is part of your value stream.
Thank you hope and yeah, that, that's very interesting as you kind of look at the difference between kind of what we in the industry you're looking at as value stream management versus kind of the, the, the alternative of value stream mapping, which is sometimes there is, um, a lot of confusion. Um, I guess, um, Logan, uh, based off of Hope's answer. Um, is there anything else that you would like to add, um, for what you think of value stream management meaning?
Absolutely. So I think extending on what hope was talking about, like in my previous career, as a consultant, we would actually do value stream mapping as an exercise. So at the start of an engagement, we'd do value stream mapping. We'd have all the leadership come down, all the developers, all the ops people would come down and, and map out their value stream. And we'd take that to see where they were at the start. And then we'd go through an eight week process, try to transform how they develop software. And then at the end we do the same exercise and prove out, Hey, look, you've done these things. We've had these massive changes. Like this has been a great success, but that was, you know, a very time consuming thing to actually get everybody involved. You know, actually getting multiple leaders all into a single room for hours on end to do this.
Exercise is not reasonable to do this frequently. But the important thing is with value stream management is we're not looking at things at just one fixed point in time. We're doing it consistently, cuz we wanna be able to prove out that any changes we make are making these actually making the positive influence we want them to make. And so having a system in place that doesn't just have this, this fixed exercise of what does it look like right now? We need to continuously see, do the changes we make improve over time. Do they get worse? Um, and just having that continuous thread so we can always see what direction we're going in, I think is, is just a, a huge shift and really valuable for any company.
Yeah. That, and that, that's very interesting. And I, I think that actually offers a good kind of transition into the, to the next question that we had. I mean, as you're, as you're talking, it sounds like value stream management is a little bit unique, um, to each of the customer's environments on the stakeholders are likely to be different. Um, depending on what value stream they're beginning with, um, to help in that optimization. Um, and it does require a lot of transition and getting the right people involved. Um, so I guess building on that, um, I think it really gets into the core of what value stream management means, um, in your opinion, and either hope or Logan feel free to take this one first, what capabilities are critical to value stream management. And this, this is really where we can discuss, um, whether certain metrics or visualizations you would like to see, um, capabilities that are critical to support value stream management. Um, what do you both view as critical as we've defined value stream management today? So far Logan, you can,
You can take this one. Um, so I think really the important thing to consider when we're looking at ice stream management is there's two levels, right? So the main thing we're thinking of is the insights we're gonna get the decisions we can make based on our information, but any sort of insight that you get is only as good as the data source. And so we see this two very related problems of gathering information on your software delivery process and then transforming that into usable information. And so I'm gonna go ahead and actually do a screen share here, here is a release. So this is our way of kind of mapping out your whole end to end process. So we're starting with kind of the information from doing a get commit all the way through gathering evidence, uh, doing our deployments and then going all the way out to production.
And so the important thing is there, there are many tools that can kind of gather information and pull it into some sort of dashboard, but this is truly the orchestration layer. That's actually doing all the work. And so the information that we get is not like we're not removing it from, uh, the deployments or anything like that. This is directly information of, you know, who's done what, how long it's taken all of that tied directly into your software delivery process. And so we're able to take this information and then build out our insights dashboards. So we have a whole bunch of kind of outta the box and customizable dashboards, but we're able to get things like how long all of our releases are taking what the longest tasks are across all of them. And we can make customizable ones that actually pull from third party tools like JIRA and can, you know, really fulfill any of those, uh, analytic requirements. So, but with all those capabilities, we're able to get a, a great overview of what's going on in your organization.
And, and I want to, uh, add on to what Logan has said. Um, the big thing with value stream management, and I'm emphasizing this in capital letters is bringing in all of the relevant data from across the organization, the things that impact that value stream, the work that's going on, the approvals that need to happen so that you can optimize. If you do not have the right measurements to be able to say, yes, everything is going great. There's nothing we can improve. Um, you're kind of halfway doing value stream management. You'll still get something out of it, but you are not going to, um, potentially, you know, be the highest performing, uh, organization you could be because there may still be some things hidden that that could be optimized, that you can't see impacts that are slowing you down, that you don't have visibility to. So having that dashboard that Logan showed populate it with the right information from the right places is absolutely critical.
Yeah. And, and Logan, thank you very much for sharing that. Um, I know me personally, I'm a very visual person. So being able to see the stats kind of quickly jump into those charts is very beneficial for someone like me and I, I know our tool, um, it has out of the box capabilities, but also the ability to, um, to customize if there's different reports. Um, 1, 1, 1 piece I did wanna follow up on as you were showing those, um, you, did you and hope, hope, both alluded to, um, it's all about where the data is coming from and you specifically mentioned plugins, um, that are available within our platform. Um, can you, can you go into a little bit more detail around what those plugins are?
Yeah, absolutely. So we understand that everybody has a whole different tool set. I think there was some research that said most organizations that are, you know, beyond a certain size, have like a hundred tools in the average software delivery tool set, which is mind blowing to me. Um, but in order to actually support these teams, we need to have, you know, integrations with all these different tools. And so we have, you know, a ton of different plugins that effectively allow any, any release manager or anyone who comes in here and is gonna be building one of these workflows out to just add an item, try to make it as user friendly as possible. So even non-technical people can do this, but they can just choose a procedure on one of the plugins. So say it's JIRA. I wanna pull my tickets from JIRA that are related to whatever query or I'm using Ansible and I want to kick off a playbook. And so we have all these different capabilities related to these different, uh, these different tools because we understand that everyone has their critical work path that requires these external tools. Um, and I guess one other note is if a tool isn't actually available as one of our plugins, it's very easy to build another one. If they have like a rest API or a CLI, you can really kind of use our plug-in development kit to put something together in no time.
Awesome. And, and thank you for elaborating there. I think the flexibility, um, and the scalability that comes with that is definitely, um, a big value add for most of our customers. And, um, for the next question, hope you started alluding to this in your prior response. I would like to lead off, um, with you on this one specifically. Um, so as it relates to value stream management, I think it's all about properly setting expectations upfront. So in discussions that you've had with our customers, um, starting with hope and then can go to Logan as well. Um, what outcomes should they expect from implementing value stream management? Um, and I guess to go a step further, I guess, how do you define those outcomes and are some of them easier to attain versus more aspirational in nature as a multi-part?
Yeah, I, I think the aspirational piece is, uh, that someday you're gonna have a perfect value stream <laugh> that, uh, that, that probably is not the expectation to have, but, um, some of the outcomes, if you are doing value stream management, well, uh, you should be able to, again, draw that line to the strategy and understand that the development teams are working on the most important work development teams I've worked with in the past. Sometimes if there was nothing happening because we didn't have visibility into the value stream and we were doing sort of a, you know, back in the napkin prioritization, sometimes we would just decide, you know, this whole sprint we're gonna work on tech debt, right? No one's told us any different that isn't necessarily what is most important, uh, to the organization. So that alignment with not only that one team, but with the other teams, perhaps we were working on tech debt when we could have been helping another team, um, do something that was, that was of higher value.
Uh, also some of the outcomes around metrics, right? There are, uh, a few critical metrics, um, for value stream management that are always monitored. There's probably eight or 10, but you know, the most basic ones you're gonna be looking at throughput, right? You're gonna be looking at how long it takes a piece of work, um, to go through the cycle again, you know, concept to cash. How long does it take it to flow through? Um, if you do it well over time, you can start to get some predictability around certain types of work. Then you can actually plan better across the entire organization. Um, understanding your, your average lead time, if you know, how long it takes from usually when the idea or the work starts well, not the work starts, but idea is planted, let's say until it is completed, um, that gives you another lever you can pull for plant.
And then understanding the cycle time. When someone on the team has actually started development, started planning the work, maybe even, um, diagramming until that work is completed. That becomes more predictable over time. And within that, you're able to see what are the typical blockers. Sometimes blockers are different for different types of work. Um, but the outcomes overall in, in an ideal way, one of the big ones is being able to connect the development teams to the why in the organization. Um, not just having them do work random work. Sometimes they feel it sort of random because things keep coming in their direction and, and it's turns into sort of a feature factory, but connecting the development teams to the why of the organization, why are we doing this? Why is it important? Why does it matter to our customers? Um, actually can spur more creativity.
The development teams can come up sometimes with better ideas, better ways, uh, to reach the goal. So for me, um, those things are critical. Um, the why for the developers understanding your lead time, your cycle time, understanding your throughput, I think at minimum, um, if you have those, uh, you have a great start and again, there are many, many more benefits that you can get, um, from implementing these practices, but those are some that you can get pretty early on. Awesome. And is there anything else on Logan you'd like to add on from an outcomes perspective?
I think hope has covered pretty much everything, but it really just helps your organization be more data driven. You might have lots of good ideas for how you think things should go, but until you can actually prove it with data, you know, getting buy-in can be challenging and you might have incorrect ideas about how, uh, or what the best approaches are. So definitely, uh, helpful in that regard.
Great. And, and I, I think that those both, um, hope a comment you made specifically that I think ties really well you've, you've already gone into metrics, um, very detailed right there, but I, I guess to build on that kind of the developer experience, the employee experience, I think everyone at the end of the day, we're, we're trying to get out of our own silo. We're trying to make sure we're all marching in the same direction. And if you don't have this visibility to value stream management and can provide, then sometimes you might not feel like you're working on something that matters. So really understanding the why, um, helps improve employee satisfaction. It's gonna make sure you're working on better things and everyone's marching ideally in the same direction. So you kind of already hit it correctly there and you started to go into, um, some metrics.
And I, I think what we often see as metrics by themselves, sometimes aren't the most useful. You wanna make sure that, um, you wanna make sure you're measuring the right thing. So within, within the developer area, we're very familiar with door metrics, um, as one thing. But one, one question I wanted to add on is kind of outside of door or four door metrics and beyond door metrics. In addition to some of the metrics you already alluded to, um, what are some others, um, that you think are really important to help monitor, to make sure that the organization is marching in the right direction?
Um, some that aren't at the team level that are usually very important is, uh, for any company that's trying to move fast is time to market. So they are looking at, um, we had an idea. We gave it to maybe the product manager, right? We gave it to the product organization. How long does it take for that idea to be available in the market where we can start making money, we can start charging for it. Um, also once that idea is in the market, if you are able to collect some telemetry data and understand usage of that feature that has been pushed out that's information, you can feed back to the development team to help them understand what's being used. Most what's being used least that's insight for them, maybe also for the design team. Um, then you also can, if you are in a really an organization that has done this really, really well, you can use that to calculate your return on investment, right?
The amount of work we did to develop this feature, um, no one is using it. What did that cost us? We invested a certain amount into this feature. Oh my gosh, it is way more popular. Um, what, what is that ROI, uh, for that one? So really the big thing with the metrics is going to be, there are standard metrics, but find the ones that matter to your organization, the ones you will actually use, because one of the worst things is to have a dashboard full of information where it's tracking 20 or 30 things. I've seen this in the past, and there are only two that anyone truly cares about. And there are other things that you probably could surface. So, um, take the time to understand what matters, what things, uh, what, what metrics should be measured and the ones that are actionable. Um, yeah. Going, going by the regular basic script is good. But beyond that, um, there's a lot of customization.
Well, thank you for that. And, um, I guess just to be sensitive to time as we conclude today's session, um, um, first I'd like to thank you both for joining the panel today, um, to conclude though, we'd like to just use us as a chance to summarize kind of what we've talked about. So, um, I guess how have we realized this value at CloudBees, um, as it relates to our internal thinking around value stream, um, the implications to our customers and probably most importantly, um, any advice you'd have to people out there who, um, aren't using value stream today, or haven't truly understood how to leverage value stream management. I just wanted to use this final portion for any parting shots of wisdom you have.
Yeah. I, I think my biggest shout out is going to be, if you are in a very large organization and you have, let's say more than 75 or a hundred developers, or you have more than, let's say six or 10 development teams, value stream management is going to benefit you. Value stream management helps you when you have a lot of complexity. When you have a lot of moving parts, you have a lot of people contributing to the work. Um, there is no way that an individual or even many teams can track what's going on and respond in time for it to be relevant information. And as you know, the whole thing about yesterday's weather, definitely yesterday's weather, but a value stream management tool lets you see what's happening now and today, and also hopefully track that improvement over time. So if you are in an organization where there are some disconnects, um, yeah, look into a value stream manage
Great. And uh, Logan, is there any, any final pieces advice you would have to our listeners today?
Yeah, I think two things. So first don't be afraid of your initial stats. It can be very frequent that, uh, you're implementing a new dashboard. You're thinking about what metrics kind of the people excelling in the industry are getting, but trying to concern yourself about what ideal is, um, versus where you are. Like that's not the right approach. Find out where you are today. Don't worry that your boss is gonna get upset with those stats because that's a great baseline. Any improvement that you have from there is gonna really reflect itself. If you have the kind of stats to back up that those changes have been successful. The other piece of advice I would say is, uh, to Hope's point, you need to consider what things you're actually caring about in terms of metrics. Um, there's kind of a, a saying that like the metrics that you focus on kind of lead the way that your company like the direction of your company, right? And so if we're focused on minimizing costs, that's going to optimize whether you work towards that goal. If you're focused on the number of deployments, you're gonna focus on that goal. And so find the right goals for your company and create the dashboards that align with those. Cause that's going to lead to the most success.
Great. Well, those were all the slides and questions we had for today. So we'd like to thank everyone for attending today's session. Um, a big thank you to our panelists, um, for sharing, um, their thoughts on value stream management. And um, with that, we will conclude the presentation. Thank you all.