Drew Piland

Hello, and good day to everyone, and welcome to DevOps Enterprise Summit 2022, where I'm thrilled 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 Piland, and I'm in the product marketing organization at CloudBees. I will be emceeing today's session, where I will be asking questions to help spur discussion with two of our panelists, who I am happy to introduce.

Hope 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 Donley, who is our senior technical evangelist, and prior to this role was an SA at CloudBees, and before then spent time at both Red Hat and Dell EMC. Both of our panelists 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 the 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, first to Hope, why should we care, and what does this actually mean?

Hope Lynch

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 going to 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 direct line between those things, you won't get maybe the time to market you were looking for, maybe the return on the investment in the software delivery teams or even the tools that they are using. So without that, you have a big, huge gap in your company strategy.

Drew Piland

Awesome. And I guess, Logan, was there anything else that you would like to add onto that, or?

Logan Donley

Yeah. So I think it also goes the other way, which is important when you've got all these objectives in your software development teams. If you actually want to get funding for these types of projects, it's important to be able to tie them to those business outcomes, because 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 going to be delivering software faster, you're not going to get the budget for it. So that's just always important to relate those two.

Drew Piland

Awesome. And I think that is a good segue into the next question that we had. A term that, in the industry, value stream management, and this is something that, Hope, initially I'd like you to dive in first just to give us a little bit better understanding, get a little bit more granular into what value stream management means.

Hope Lynch

Right. So value stream management, which sometimes is confused with value stream mapping, related but not the same thing. Mapping is you're planning, you're trying to optimize, you're trying to find gaps maybe. 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 impede that delivery, slow that delivery, stop that delivery, that is part of your value stream.

Drew Piland

Thank you, Hope, and yeah, that's very interesting as you look at the difference between what we in the industry are looking at as value stream management versus the alternative of value stream mapping, which is sometimes there is a lot of confusion. I guess, Logan, based off of Hope's answer, is there anything else that you would like to add for what you think of value stream management meaning?

Logan Donley

Absolutely. So I think extending on what Hope was talking about, 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 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'd do the same exercise and prove out, "Hey, look, you've done these things. We've had these massive changes. This has been a great success." But that was a very time-consuming thing to actually get everybody involved. 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, we're not looking at things at just one fixed point in time. We're doing it consistently because we want to be able to prove out that any changes we make are actually making the positive influence we want them to make. And so having a system in place that doesn't just have 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? And just having that continuous thread so we can always see what direction we're going in, I think is just a huge shift and really valuable for any company.

Drew Piland

Yeah. And that's very interesting, and I think that actually offers a good kind of transition into the next question that we had. As you're talking, it sounds like value stream management is a little bit unique to each of the customers' environments. The stakeholders are likely to be different depending on what value stream they're beginning with to help in that optimization. And it does require a lot of transition and getting the right people involved.

So I guess building on that, I think it really gets into the core of what value stream management means. 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 is really where we can discuss whether certain metrics or visualizations you would like to see, capabilities that are critical to support value stream management. What do you both view as critical as we've defined value stream management today so far?

Hope Lynch

Logan, you can take this one.

Logan Donley

So I think really the important thing to consider when we're looking at value stream management is there's two levels, right? So the main thing we're thinking of is the insights we're going to 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 these two very related problems of gathering information on your software delivery process and then transforming that into usable information.

And so I'm going to 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 the information from doing a Git commit all the way through gathering evidence, doing our deployments, and then going all the way out to production.

And so the important thing is 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, we're not removing it from the deployments or anything like that. This is directly information of 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 out-of-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 really fulfill any of those analytic requirements. But with all those capabilities, we're able to get a great overview of what's going on in your organization.

Hope Lynch

And I want to add on to what Logan has said. 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," you're kind of halfway doing value stream management. You'll still get something out of it, but you are not going to potentially be the highest performing organization you could be because there may still be some things hidden 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 populated with the right information from the right places is absolutely critical.

Drew Piland

Yeah, and Logan, thank you very much for sharing that. 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 know our tool, it has out-of-the-box capabilities, but also the ability to customize if there's different reports.

One piece I did want to follow up on as you were showing those, you and Hope both alluded to it's all about where the data is coming from, and you specifically mentioned plugins that are available within our platform. Can you go into a little bit more detail around what those plugins are?

Logan Donley

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 beyond a certain size have, like, 100 tools in the average software delivery tool set, which is mind-blowing to me. But in order to actually support these teams, we need to have integrations with all these different tools.

And so we have a ton of different plugins that effectively allow any release manager or anyone who comes in here and is going to 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 want to 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 tools because we understand that everyone has their critical work path that requires these external tools.

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 a REST API or a CLI, you can really use our plugin development kit to put something together in no time.

Drew Piland

Awesome. And thank you for elaborating there. And yeah, I think the flexibility and the scalability that comes with that is definitely a big value-add for most of our customers.

And for the next question, Hope, you started alluding to this in your prior response, so would like to lead off with you on this one specifically. So as it relates to value stream management, I think it's all about properly setting expectations up front.

So in discussions that you've had with our customers, starting with Hope and then can go to Logan as well, what outcomes should they expect from implementing value stream management? And I guess to go a step further, how do you define those outcomes? And are some of them easier to attain versus more aspirational in nature? So multi-part.

Hope Lynch

Yeah. I think the aspirational piece is that someday you're going to have a perfect value stream. That probably is not the expectation to have.

But some of the outcomes, if you are doing value stream management well, 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 back-of-the-napkin prioritization sometimes, we would just decide, this whole sprint, we're going to work on tech debt. No one's told us any different. That isn't necessarily what is most important 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've been helping another team do something that was of higher value.

Also, some of the outcomes around metrics. There are a few critical metrics for value stream management that are always monitored. There's probably eight or 10, but the most basic ones, you're going to be looking at throughput. You're going to be looking at how long it takes a piece of work to go through the cycle. Again, concept to cash, how long does it take it to flow through?

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. Understanding 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, that gives you another lever you can pull for planning.

And then understanding the cycle time. When someone on the team has actually started development, started planning the work, maybe even 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.

But the outcomes overall, in an ideal way, one of the big ones is being able to connect the development teams to the why in the organization. Not just having them do work, random work. Sometimes they feel it's sort of random because things keep coming in their direction, and it 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, actually can spur more creativity. The development teams can come up, sometimes, with better ideas, better ways to reach the goal.

So for me, those things are critical. The why for the developers, understanding your lead time, your cycle time, understanding your throughput. I think at minimum, if you have those, you have a great start. And again, there are many more benefits that you can get from implementing these practices, but those are some that you can get pretty early on.

Drew Piland

Awesome. And is there anything else, Logan, you'd like to add on from an outcomes perspective?

Logan Donley

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, getting buy-in can be challenging, and you might have incorrect ideas about what the best approaches are. So definitely helpful in that regard.

Drew Piland

Great. And I think those both, Hope, a comment you made specifically that I think ties really well, you've already gone into metrics very detailed right there, but 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 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 that value stream management can provide, then sometimes you might not feel like you're working on something that matters.

So really understanding the why helps improve employee satisfaction. It's going to 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 some metrics, and I think what we often see is metrics by themselves sometimes aren't the most useful. You want to make sure you're measuring the right things.

So within the developer area, we're very familiar with DORA metrics as one thing. But one question I wanted to add on is kind of for DORA metrics and beyond DORA metrics, in addition to some of the metrics you already alluded to, what are some others that you think are really important to help monitor to make sure that the organization is marching in the right direction?

Hope Lynch

Some that aren't at the team level that are usually very important is, for any company that's trying to move fast, is time to market. So they are looking at, 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?

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.

Then you also can, if you are in 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. 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. What is that ROI 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 take the time to understand what matters, what metrics should be measured, and the ones that are actionable.

Logan Donley

Yeah. Going by the regular basic script is good, but beyond that, there's a lot of customization.

Drew Piland

Well, thank you for that. And I guess just to be sensitive to time, as we conclude today's session, first I'd like to thank you both for joining the panel today. To conclude, though, would like to just use this as a chance to summarize kind of what we've talked about.

So I guess how have we realized this value at CloudBees as it relates to our internal thinking around value stream, the implications to our customers, and probably most importantly, any advice you'd have to people out there who aren't using value stream today or haven't truly understood how to leverage value stream management? Just wanted to use this final portion for any parting shots of wisdom you have.

Hope Lynch

Yeah, 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 100 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. 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. In Agile, 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, yeah, look into a value stream management.

Drew Piland

Great. And Logan, is there any final pieces of advice you would have to our listeners today?

Logan Donley

Yeah, I think two things. So first, don't be afraid of your initial stats. It can be very frequent that 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 versus where you are, that's not the right approach. Find out where you are today.

Don't worry that your boss is going to get upset with those stats, because that's a great baseline. Any improvement that you have from there is going to 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, to Hope's point, you need to consider what things you're actually caring about in terms of metrics. There's a saying that the metrics that you focus on lead the way that your company, the direction of your company, right? And so if you're focused on minimizing costs, that's going to optimize the way that you work towards that goal. If you're focused on the number of deployments, you're going to focus on that goal. And so find the right goals for your company and create the dashboards that align with those, because that's going to lead to the most success.

Drew Piland

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. A big thank you to our panelists for sharing their thoughts on value stream management. And with that, we will conclude the presentation. Thank you all.