Navigating the CI/CD Frontier: Insights from the 2024 State of Continuous Integration and Continuous Delivery (CI/CD) Report – The CD Pipeline EP 12

Hey everyone. I'm Alan Shimel, CEO of Next Strong Group, and you are watching CD Pipeline. For those of you who are not familiar, CD Pipeline is a once a month, uh, video series that we do in partnerships with our good friends at the CBF.

That's the Continuous Delivery Foundation, VBF, which is also part of the Linux Foundation, lf, and, um, couldn't do it without them. We, we do it in, as I say, in partnership. And what it is, is once a month we look at relevant topics within the world of CICD.

And you know, for those of you who are familiar with CICD, there's really no and relevant topics, it seems as there's always so much going on in the space. Um, also for those of you not familiar with CIC, uh, the CDF rather, I would encourage you to go to the website and, uh, it'll be in, in here. It's the, uh, continuous Delivery Foundation.

Laurie, just help me. org. foundation, CD Foundation, I apologize.

CD Foundation. You know, uh, in addition to doing this show, the CD Foundation does a lot of things, but primarily is they are responsible for managing and administrating. Uh, I think it's eight of the most popular tools within the CICD world.

And, um, it's a great foundation. They're always looking for people to help and get involved. And we'll, we'll talk more about that later, but let's go to today's show.

Today's show, or this month's show that you're watching today is, uh, around the release of the annual report from the CDF, and it's navigating the CICD frontier. It's actually the abstracts, uh, is our name, insights from the 2024 State of Continuous Integration and Continuous Delivery Report. That's the ICD.

So again, this is an annual report. There's some really great research and, and findings here. We're gonna go over.

But before we do, I want to introduce you to a fantastic panel that we've got laid out for you. Um, I'm gonna start with Mark, wait, who is an expert on this report, having already spoken about it a few times, and we're gonna rely on Mark a lot at this. Mark, if you wouldn't mind, introduce yourself to the audience.

Sure. I'm the Treasurer of the Continuous Delivery Foundation. I'm a member of the Continuous Delivery Foundation Board.

I'm a member of the Jenkins Governing Board, a Jenkins core maintainer, and I maintain the Jenkins Git plugin. So I cared deeply about CDF and its success, uh, especially its Financial Success Treasurer and I care deeply about the success of the Jenkins Project. Those two things work really well together, right?

Because CDF is the, the owning umbrella project that sponsors the Jenkins project. We depend on it. We, we are deeply grateful for it.

That covers what I had, Alan. Thank you, mark. Next up, let me introduce you to Steve Fenton.

Steve, if you wouldn't mind kinda introducing yourself to the audience. A little background. Thanks, Alan.

Um, yeah, my name's Steve. Uh, I work at Octopus Deploy, um, and we sponsor the CD Foundation 'cause we think their work super important too. And, uh, I'm on the CDF Outreach committee.

I was on the CD Con program committee this year, and I wrote the Journey of DevOps tooling adoption post for the CDF blog, uh, when the report came out. Uh, I'm super excited about, uh, software delivery culture and methods and research. Like this report is taking us into a new era where we don't have to just, uh, listen to the people that wrote the books anymore.

We've got research that helps back up the ideas. So I'm super excited about it. I love it.

I love it. Next up, I'd like to introduce you to Melissa McKay, who's been on here with us before. Melissa, welcome.

And give him a little bit about you. Yeah, thanks for having me here. So, um, I'm Melissa McKay.

I am currently a, um, head of developer relations at J Rog. Um, I, that's a new career choice for me, uh, relatively new, but, um, prior to that, I've been a developer for most of my career and, um, primarily Java server side applications. And I distinctly remember moving my first time moving to a DevOps team.

Um, the very first tool that I was exposed to, aside from source control, was Jenkins. So I have some good memories and some terrifying ones that I share often in lot of my talks as well. Uh, you know, just, uh, getting thrown into the deep end and, uh, having to learn, uh, these tools from scratch.

So yeah, really interested in this information, really interested and getting developers more efficient, getting teams more efficient, and, uh, the CD Foundation is integral to that. Um, I am also part of the, uh, a co-chair with didi, actually, um, the, uh, interoperability special working group at the CD Foundation. And I wrote, uh, co-wrote a book called DevOps Tools for Java Developers.

Very cool. Melissa, thanks for joining us today. Appreciate it.

We, I know you're on the road and, you know, dialing in from the road is much appreciated. Next up, let me introduce you to a gentleman who claims he's looked at the report a few times, but he's really not an expert in it, low expectations, but he's also the chairman of the, uh, CD foundation. Is it chairman?

Is that the right word or the right title? The sports chair. Um, sports chair.

Okay. Yeah, I guess chairman's kind of a, an old word board chair. Um, the DC Ika thei.

Just kidding. I know you know this report very well. You and Mark go over it together.

Um, but welcome, welcome back, and if you wouldn't mind giving people a little bit of your background. Sure. Um, I'm DDI Ika and I am board chair of the Committee of Delivery Foundation.

I also serve on the CDF Technical Oversight Committee, as well as co-chair, the Interoperability special Interest group with Melissa. Um, I am also on the TOC of spinnaker, and spinnaker is one of the projects in the Continuous Delivery Foundation. Um, my team has been working well.

I've been working with the spinnaker team for about four years now, and, uh, making contributions to it. It's a, a amazing tool, and I wanted to get involved with the CDF because of it. Um, I think the, the mission of the CDF right now, as, as, is not just understanding how to help people deliver software, what's, uh, speed and security.

It's also thinking through things like what's next? What comes next for tooling? What are we doing?

How are we, how are we trying to expand the space? And it's that work that really excites me, and we are definitely fed from the information that comes from this report. Excellent.

Very cool. Didi, welcome. Thank you.

Last but not least, she's my co-host here at CD Pipeline, and always great to see her. It looks like she's open today for a change. Uh, Lori LaRusso.

Hi, Lori. Hey, Alan. Yes, I am home.

And if I make a strange face throughout this conversation, I promise it's not any of the panelists or what they're saying, it's the fact that I have two dogs inside and it's pouring outside. So I've tried to dope them up with lots of food and treats, but you know, they're labs, so they have bottomless pits for stomachs. Um, I will say that this is such an awesome panel.

I'm really excited to be here. There's some recruiting work that I did that is paid off. Uh, Steve was on the outreach committee, and I remember when he first joined, he said, I'm just gonna sit back and I'm not gonna, I'm not really gonna like, participate.

I don't know what I should do. And now he's writing blogs and he is showing up on the CD pipeline, giving his opinion about the CICD report, which is awesome. And DDC can forever, um, be in my debt for bringing 'em into such a cool group of people, uh, and recruiting him into some more activity with the CDF.

Um, so yeah, so this is an awesome group. I think it's a great way to, to talk about the report. Lots of good opinions in this room or rooms.

Absolutely. Hey, before we begin, I wanna put it right out there to everyone watching this. This report is available to be downloaded, and you can get it if you go over to CD foundation slash state of CICD dash 20 24 2 24.

And you could download the report there. So this isn't the first state of CICD report. I remember doing the show on this last year.

Who can be our group historian, mark, um, about the history of the state of CICD report and a little background. I mean, obviously it's the, we're the CD foundation. It makes sense to do a report like this, I guess, but, but why?

Yeah, so, well, so I, I liked Steve's Steve's way of describing it. That we've had a culture, we've had a, an idea to recreate, to rebuild, to do a better job of crafting software development. And that's, ideas are great, but it's impressive to bring data to ask ourselves the question.

Is the idea working? First question, how well is the idea being adopted? What are the things that we might consider as ways to increase the adoption?

The, the, the concepts behind CI and CD are not brand new concepts, right? These are, these are well established concepts known for years, but data to tell us how are we actually doing in industry with these concepts? And, and that's the purpose of the report.

And that's, that's, that makes it extra valuable that we get that report across multiple years. We can see how things are evolving. Excellent, excellent.

Um, so guys, if no one has any other background on the report that they want to volunteer, let's jump in. Well, actually, mark was last year, the first report, is this the second one now, or is there History? So, and, and I'm not, I'm not sure on how many there have been, but there have been multiple reports.

As far as I know, we've run this report multiple times. So, so this is not a brand new thing. This is, this is a well established pattern of running these reports.

And, and we're grateful for that. It's, it helps us see patterns and observe sequences of events over time in an industry that is, well, an industry that went through a pandemic, right? An industry that went through all sorts of complicating changes, an industry that's going through changes Now.

Absolutely. Melissa, you were shaking your head. Do you have an idea of how many years we've been doing this report?

Oh, several years. I mean, the re the report itself, at least the latest one that came out, it, it describes, you know, all the different quarters, um, that they've been doing it. Um, okay.

See if I can find that really quick. I'm pretty sure we started in 2021. It's, Yeah.

2021. Okay. So this is great.

So Yep. QQ 3, 20 20 to Q1, 2024. So several quarters, um, 150,000 respondents.

That's not a small quarter. Wow. Though I'm impressed with the Read numbers I was looking for, right.

To get that cumulative amount of responses. Now you have a real sort of a book there of, of data that you can dial, dial in or two. So let's, let's dial I'm sorry, go ahead.

One more comment, sorry on that, that I think is really important to share. Um, there is some consistency, you know, in questions, but as we've reviewed this report every quarter, we always get into these conversations of just how complicated some of these processes can be and how some of the data that's coming out there could be several different reasons for why it's presenting the way it's presenting. So it's been interesting to have those conversations with some of this group actually, um, as this report comes out every time, um, I know I, I give talks sometimes about the whole process of CICD, um, being somewhat like a Rube Goldberg machine sometimes within teams.

Um, you've got all these pieces and parts to go together, and there's a lot of, a lot of different reasons that we might see the data displayed as it is Agreed Worthy of conversation for sure. Absolutely. So 2024 post pandemic stuff's happening, right?

It is, uh, I, I've been on a circuit pretty much since Cuon Paris. I think I've been on the road since then. I'm happy to be home now.

Um, but, you know, who wants to kick us off? What, what do you think are some of the big, big findings in this report? Whether they're surprising or not, right?

That, that we need people to take home with? If you don't mind, you're the, the board chair. Why don't we ask you to kind of kick us off here?

Sure. I think, um, well from the perspective of my CDF perspective, um, one of the things that I found most interesting was the report highlighted, um, the impact or the knowledge of, uh, CICD tools that new developers have. Um, and it immediately showed this gap of like, I think it was, uh, 83% of them were aware of the tools.

And so there's a big piece that, uh, just aren't aware that they're a part of CICD or what that even is, or you know, how they're engaged with it. And that creates some opportunity for us in the continuous delivery foundation to educate and work better with education, uh, universities, um, and to make some impact there. And it's, it's trying to find information, uh, at least from my perspective with Boris Chair, where the CDF can make immediate impact, uh, and kind of, uh, send the community in the proper corrections.

Sure. It's, it's interesting, 83% are aware of the CICD tools, but what percentage of folks are actually using them? Well, like the, yeah, that's the, I guess I misspoke.

Those are, those are the users of who are aware that they're using CICD tools is a better way to say that. Uh, got it. And it is the, the, the individuals who aren't, that become the focus of what I think we need to do in extended education, that more students, it should be a hundred percent of them, right?

Everyone should be aware of Jacobs, right? Everyone should be aware of spinnaker and what those tools mean and what they do. Um, not just because of the history, because this is, this is how you learn the process.

You get the deeper understanding and starting with things that give you this hands-on experience. And so what I've been looking at and really focused on since the report is engaging with universities and saying, okay, how do we fix this problem? Um, and that's one of the things that we're, we're looking at too via the, the interoperability sake.

Um, and I think being able to see that information and then immediately say, okay, I can take some actions and impact that, that's what we want to do with this. You know, you don't just wanna take the information and go, okay, yeah, that's great, we got stuff, but what, what can be actionable and how can we impact the community? Um, should be the intent with a report like this from a virus.

One of the things I find, um, interesting as a finding, and I, I think everyone can kind of understand why, and I think we should maybe expand on this. And, um, it says using multiple CICD tools of the same form leads to worse deployment performance, likely as a result of challenges related to interoperability. So the more tools you use, the harder it is to track.

Like, what are your, Melissa, I'm gonna throw it to you 'cause you're, um, on the interoperability sig, like how do you think we can try and change this metric or turn it around to sort of streamline processes and tooling? This is a tough one 'cause I, I think I'm just gonna provide some of my own experience. I, um, and this goes back and forth depending on what kind of organization you are in, but I, I always see this, this back and forth between like platform teams that decide for every team within an organization what tools they're going to use and try to make that easy for them to adopt.

And then I see everyone get upset with that for one reason or another. And then there's a move to every team being individually managed by a team lead. And they might choose completely separate tooling from each other within the company, depending on their skill sets, depending on what they're comfortable with and what they're used to.

Um, and budgets as well. It makes a difference. But I do have personal experience of having trouble with that.

I remember even just being on a team and we used three different sets of repositories for our bills. So we had to, you know, reach out to one to get other internal team stuff. We had a separate one for like images.

We had a separate one that was open source that other people just preferred. And it was kind of ridiculous just trying to figure out where all of our stuff that our project relied on, uh, where it was stored and, and how to make sure that everything got into our build appropriately and everyone had the right permissions to be able to access everything. So I can totally see why this metric happens.

And I'm just talking about code repositories. I mean, we've got across the board different tools for different parts of the process all over the place, different build tools even so if you're moving one person from one, um, set of tools into another team and it's a completely different set of tools, I can see that being a struggle as as well. So, I dunno if I answered your question or, or just relayed like, yes, this is a problem.

Right? You were nodding your head. Oh, mark, go ahead.

No, no. Steve, I, I think let's give Steve a voice. My voice has been heard plenty.

I think Steve got things to say there. Uh, yeah, I mean, what Melissa was saying about, um, when teams have all made different, um, tool choices, like it's hard enough remembering all of those little command line things you need to call for source control, um, where to log in to see your build status, um, where to log in to see where everything's deployed. If every team's got different choices and you are contributing to multiple projects, which is the situation I'm in, you're just constantly looking up things on a wiki to find out where stuff is.

And so the amount of your productive day is just shrinking and it's just, it's admin instead of programming. So yeah, I, I agree that's, that's definitely an experience I've had too. I have, I've even been on a case where I had to like get off a VPN, get on A VPN depending on what team I'm on, right?

And, and be able to do that multiple times a day. So yeah, it, it's a challenge. I I think one of the things, one of the solutions here is awareness.

So, you know, having organizations at higher levels be aware of this issue and maybe make better decisions, um, in that area would be good. Yeah, I, I, I, like Melissa described the, what I'd call the culture compromise, uh, at the larger the organization, the more likely it has to strike some of these cultural compromises between autonomy for a team and organizational selection to optimize for the organization as a whole. And, and there are different levels of that required for different organizations, right?

Organization size is a big impact on that. Small organizations may, may grant more autonomy and do less damage with that extra autonomy. Large organizations, large organizations, I would expect maximum autonomy would be also maximum damage in terms of their portability, right?

They, they, they have to culturally choose to centralize more and, and deal with rebellion if they have to. So Steve, I think that was sort of what you were describing as well, is that there are times when organizations at large scale have to have to make choices for the efficiency of the organization as a, as a whole, even if sometimes it sacrifices my personal productivity. What I like about this conversation is that it leads me into another finding, um, that you all have just been talking about, and it's that source control management and issue tracking hold the top spots for the most widely used DevOps technologies.

And so you're saying that, and then we're saying, but when you add too many, it creates chaos, Right? I think it's, it's more about, I think those are like the basic minimum, like source control for sure. Um, issue tracking is so helpful, but having multiple of the same type is the biggest issue.

Um, I think that's where the discourse comes and the friction comes Well, and, and that, that friction is not just an internal organizational friction. Let's, let's take source control. Alright?

I was in an organization in a, a company that had a mix of subversion and we were adopting this brand new technology called Git. And we were really thrilled with this brand new technology called Git, except that it meant we were managing two systems and the complexities of managing those two systems. And guess what, when you add yet another system, it gets even worse.

And it's worsening not by, it's worsening by exponential growth because of connection volume, not by linear growth. So choose carefully and some things you really have to say, I'm sorry, I know you love mercurial, but our company has chosen Git and we've chosen this provider for it. Or I know you love CVS, you're a, an open BSD developer and CVS is the best thing ever, but I'm sorry, we're using Git.

So that kind of choice is a valid thing. You know, I, if you don't mind, let me be a little contrarian here today. We are, um, here, over here at Textron, we've been doing a big research project now for a few months on called DevOps.

next, CloudBees has involved jfr, some others. com and maybe 12, 13 years DevOps burst on the scene. Um, and, and, and DevOps in all its aspects, right?

But for many people, CICD is DevOps, even though, as Lori said, it's the, was it the fourth or fifth thing on that DevOps thing? On the DevOps, you know, uh, uh, the fourth or fifth most common feature of, of the DevOps get control or, you know, version control being number one. It, I heard it said, you know, DevOps is the, is the sickness, CICD is the cure, right?

Or something like that. But here's an interesting thing we found. We live in a DevOps bubble.

I do, I'm gonna venture that many of you guys do too. And that when you go out and ask, you know, random IT or, or organizations, IT departments and organizations, then 83% using, or 81% people are using CICD tools. It's kind of, you know, when you're a hammer, everything looks like a nail.

If you're working in a DevOps enabled organization that does CICD, yeah, you're probably using A-C-I-C-D tool. But the fact of the matter is that though DevOps has clearly crossed the chasm into mainstream at an enterprise wide level, it, it's not anywhere near 80% enterprise wide that are using DevOps enterprise wide. There are groups using within the enterprise, and it's the same thing for these CICD tools, right?

They may use Jenkins over here, they may use spinnaker over there. They, you know, it's not, it's not uniform and nor is it totally penetrated in there. And I think that there's another finding in the report that kind of dovetails with this, which is the least experienced the developer is the less likely they're using A-C-I-C-D tool.

The opposite of that is the more experience a developer is, the more likely he's using A-C-I-C-D tool. So the DC you talked about opportunity. There's the opportunity, why aren't our less experienced developers?

You would think they're coming in, they're gonna start with state of the art, they're starting with the new stuff. There's no sense we're learning cobalt. There's no sense learning more to fall.

We should be going right into DevOps and CICD, the DC's laughing, right? Why aren't these new folks hopping right into this? Why, why is it, that seems to me a little counterintuitive thoughts.

Um, well, I I have been, like I said, I've been having conversations with, um, several universities and just asking that question, are we preparing these students while they're still in college to exposing them to CICD tools and how is that being done so that they come into the marketplace better prepared and aware of what those options are and how they work. I have been, um, somewhat surprised with the conversations that I've had, uh, and the opportunities and how to create that experience for, um, young people that are in universities and colleges. But it's, it's not just the impact there.

It's also, as you said, once they're already in the workforce, how, how do we change that culture and give them knowledge? The the key to the statement, of course, is experience over time. They will learn it, but we have to better educate them as they prepare for this journey, um, so that they have that awareness, right?

They should have all, they should have the opportunity to have some hands-on time putting the pieces together, understanding the history and the journey of how we got there so that they can contribute and make better tools. And that's the, the benefit of education at take time to have those conversations and why that's important to do. And so I thi I think there's a, there's an element of what we might even call evangelism or of telling the story that we sometimes forget because we've been, many of us have been in the story for so long, telling it for so long that we forget.

There are plenty of people who need to hear. It's a good thing to compile your code every time it changes. It's a good thing to run all its tests.

It's a good thing to deploy it to production as fast as you can and as often as you can. And those things, those things, while they're not new to me, they are new to new people and they're new to certain classes of organizations, right? There are organizations which are sort of underserved in this space as well, either because they're highly regulated or because they're deeply steeped in another, another development culture.

And so there is an evangelism element, Alan, that's still there, even as large and as long as we've been doing this, You know, that makes me think of telco companies when you say like, they're like, uh, I was just having a conversation the other day about how it's not even like telco companies don't even move at a snail space. Like that's like the rabbit in the hair. Like they're so much slower than that.

And how can we help change the, the mentality of those types of organizations that have so much compliance, so many different departments, so many things, and let them know if you could release the reins a little bit, how much more productive, efficient, happier your developers would be. You know, like, you know how to bring them into the fold. So it's not just about, you know, students and, and young, it's, it's, to your point mark, it's like organizations, you know, complete verticals that are stuck because of this, you know, roadblock of being unwilling to let things go a little bit to release fast, to fail hard and then go back.

You know, that whole idea Well, and, and, and yet there are, there are reasons why many of those segments have difficulty doing that. Life critical software is in fact life critical and life critical software has to go through a different process than the little things I do that I release very often, right? Life critical software is not the same as, you know, the, the aircraft manufacturers with their 50 and 75 year life cycles have a very different thing than those of us who get to live in the internet age and everything.

We can release a new version and we can do that multiple times a day. So, so there is still an active promotional effort that's needed in many, many places. The thing Sure.

Um, the big difference between when you are pre-professional as a developer, whether you are a university or if you're learning to code for yourself, you don't have to collaborate with anyone, which means it's really easy because you can just change the code, right? And it's done. As soon as you add in collaboration, that's where CICD and all of the associate DevOps tools suddenly become super powerful because it, like, I, I guess that's what you learn in your first year, right?

Is when I'm merging code and it's like the first time I've done that in three months, it's really hard work. So that's why we want to do it more often so that it's a small emerge. So I think that that difference between coding for an individual purpose or to get a quantification is so different to coding with a bunch of other humans.

Yeah. But that's for sure. I, you know, and I don't know, have the right questions to ask to prove that out, but that would be a really interesting study as well, right?

The dynamics of developing in a group versus, you know, the l wolf approach, if you will. Um, So Go ahead, mark. Sorry, one, one more angle on this.

The, the, the, the report not talks about the adoption at over 80%, but then when you dive a little deeper into the report, it warns us that there are cases where two thirds of the people aren't using continuous integration. And yet Mark wait, thinks that's astonishing. What we've been doing this for years, it's a decade, it's two decades that some of these tools have existed.

And yet there are people who are not building their code every time they change it. And, and so there really is, there is, while the report tells us large, large part of the world has figured it out, we need to be doing this. But there are still plenty of pockets of places where people need to hear, you know what, it's a good thing to do, ci, it's a good thing to do.

cd I I wanna pound on that point a little bit more because as we are more experienced and we're used to it, we take a lot of these things for granted and we just do it second nature. And I'd like some of the stats in the report that says that, you know, DevOps activities are, are pretty similar across, um, different types and sizes of organizations, which is really nice to hear. Um, I also see that difference between maybe a lone wolf and, and teams.

Uh, when we look at like freelancers and specifically there's a, there's a graph in the report about that. Uh, freelancers have a little bit of a lower percentage of getting involved in DevOps activities that could probably be explained by maybe being alone. Um, but when we are talking to students and we're talking to new developers, we've got to say why we can't list a list of things that a bunch of stuff they need to do or else, uh, we need to explain why, why are these practices best practices?

Um, I know a lot of engineers and I was definitely one of them. I come in all rebellious, think I'm gonna change the world. Think of, you know, we go through stage, think we're smarter than everyone else and then, and then, uh, find out years later.

We clearly are not. But um, we need to be able to explain to these folks why, 'cause they're gonna ask adamantly. Agreed, agreed.

Um, you know, a a an an interesting thing is correlation, like, let me back up. Why do you do CICD? 'cause I could deliver software better, faster, right?

Isn't that the reason? Okay. How do we know you're delivering software better and faster?

Well, one, one measure is the DORA metrics that we've developed here at DevOps. And, and unfortunately the EU started their own DORA thing, which has nothing to do with DORA metrics, but more on security. But it's confusing as heck, I have to tell you the truth as I go through news stories.

But anyway, Dora metrics, right? Google now kind of, uh, administers the, that report, uh, you know, the original work of Jean Kim and Dr. Nicole Fors, grid and jazz humble.

And we use that to measure high performing IT teams, high performing IT organizations. And clearly it says in the report, right, if you are utilizing DICD while you are more than likely to be a high performing IT organization, is that enough? Is that enough?

Steve, I feel like we haven't heard from you. Is that enough to, to sell it, if you will, to say, Hey, this is I doted, this is why we should do it. So, um, the interesting thing about the, the Dora metrics or the four keys, maybe we'll call them to avoid the eu um, legislation.

Um, the interesting thing about them is that you can link them forward 'cause they predict organizational outcomes, which is super interesting 'cause it means it's something very technical that we can do, um, as programmers that will actually change the numbers for the whole organization at the end of each year, which is cool. And they're also lagging indicators of, um, what we're doing in the software team. So they're useful to measure what we've done in software and what we're likely to achieve as a company.

So I think they're really powerful. They're probably not, you wouldn't just use them because you know, if you're working in um, I don't know, an e-commerce website, you're gonna wanna know some specific things as well. Like what's your abandoned basket rate?

What's the value per transaction? There are things like that that will help you understand if you are feed to changes, uh, making a difference to the specific business that you're working in. But in terms of a bunch of things that we could do in any company, in any industry, that will make an impact on like our goals, and that could be financial goals or it could be, um, saving bees or reducing deforestation, whatever our organizational goals are.

Um, like that's quite powerful for me because in the past it's been quite difficult working in isolation and not feeling like you're contributing to the success of your company. 'cause it's too far away, it's too abstract. So I really like them.

I think they're very powerful 'cause of that. Yeah. Anyone else?

No, I, I wholeheartedly feel like the DORA metrics are, are a, a great, a great way to look at things that surely are necessary. To Steve's point, they're probably not sufficient. They're not the only thing you should be doing, but they certainly are necessary.

And if you're assessing them, you're at least stepping towards that improvement that you need to make. And it's a, it's shown for many companies to be a very good improvement. As you improve those measures, your organizational performance will improve as well.

Yeah, I'll just add that it's, uh, the, that it's the starting place for the conversation. And if you gives you the ability to evangelize internally, um, especially is as your company grows to say, Hey, you can see over time that something's happening. And it's a great way to start that conversation to create that evangelist movement that says, Hey, CICD is important.

Which was, you know, to come full circle with something that Melissa was saying earlier. And so it, it, it's all tied in together and that information starts in the report in a way that you can engage with it and kind of set the tone for where you are in that process and, and continue that conversation. One last thing I wanna add.

I, I like the metrics. I really do. I think they're really valuable for like internal measurement, internal progress measuring that something that I'm a little concerned about maybe we can work on in the future, figure out how to solve this problem, is how to define complexity.

'cause by the, when you start comparing yourself to other companies, other projects, it's almost, it's comparing apples and oranges in some cases. And if we can get a better metric that describes complexity, it might help solve that issue. Yeah.

I I tend to recommend that people don't use those comparisons too much. I think the only reason they really exist is because, and I think everyone here would've heard this, at some point someone will say, uh, I'm in finance and so I can't do CICD because we're regulated. And so to be able to show them the door metrics for the finance industry and say, Hey, there's a load of companies deploying multiple times a day in the finance industry, it just makes you realize it's possible even in that industry.

But they shouldn't really be used as like, why aren't you deploying as often as that company over there? So, Well, and, and it's a good highlight that different industries may in fact have different results on that, right? You, you're, to your point of complexity there, there are very different levels of complexity depending on what you're creating and how you're creating it.

Yeah. What I really like about bringing in Dora to this, to this conversation is that what we're looking at is trends and benchmarking and analysis from two different vantage points. And they're saying the same things, right?

Like they're saying like, if you have too many tools and like too many underperforming teams, too many people that don't know what they're doing, you're going to have poor outcomes. If you have, you know, a lot of people using a lot of tools and adopting it and working like you're gonna have better outcomes. And so when you kind of look at the industry as a whole, it's really nice to see that we are being able to measure things, report on things, be able to assess ourselves against this larger group, you know, and to determine how we're gonna move forward.

And I think industry, like companies, I'm sorry, foundations like the C-D-F-C-N-C-F, Linux Foundation, oh, all of them out there are really helping the industry as a whole say, look, we've been doing this for a long time. Here are some key performance metrics that you should be looking at. You know, again, it's going to determine, like, it's going to be determined by your company, by the what you're doing, the complexities and all of that.

But here are some reference points that you can see, like if you follow this path, you are more likely to be successful. You are more likely to have a high performing team if you deviate. If you can't seem to get it together, this is where you're gonna be.

And you can determine where you wanna make your investment. Do you wanna invest in your people to get them where they need to be? Do you wanna level them up?

Do you wanna invest in the next generation to Didi's point and get, so when the developers come into your organization as interns, they already are aware of this tooling. You know, like what plans are you going to put in place to make sure you are on the right trajectory forward? And here again, are tools and metrics and, uh, reports that show you like, if you follow these types of steps, this is how you could be successful.

It's pretty awesome. It is. And guys, let, let me be clear, right?

Would we do this show, it's 45 minutes or so long, it's hard to encompass this whole report, 45 minutes and get everyone's thoughts. I really encourage you out there, if you're watching this, go to the CD found CD Foundation website, download this report. See for yourself, there's so much, so much, so much more findings in there, you know, standardizing on one cd, A-C-I-C-D solution versus using multiple ones and how does that increase or decrease productivity?

And this, this, there's, there's Kers and colonels within Lake Sort, a Russian doll thing, right? There's truths within truths within truths there. Let's talk about the next report.

Who marked did DC our experts on the report? When, when, when is the next version? Did this one do out you think?

Usually we issue they, it's issued annually. Uh, Melissa's maybe better, better versed on the formal report, but in my case, I look forward about annually. And so 12 months from now, we're gonna look at it again.

One of my worries is it's going to tell us again, things are stable in the top, in the top. Organizations with a thousand or more people and stable in this case probably isn't the right choice for those organizations. Stable in a software business in a competitive world is not great.

You want to be better, you wanna be improving. And so there are, we, we wish that people would take this as a call to action, as a step to say, oh, staples good, but it's not good enough. You know?

And the one thing we haven't talked about, um, is the amount of layoffs that have happened. And when you look at the stress put on teams because they're doing the same amount or more with less. So it will be really interesting to see what, you know, what kind of trickle down effect did that have, you know, because that's important.

You can't have high performing teams if you've cut half the team, right? Because then you have a multitude of variables out there now that you didn't have before. So I think it's going to be really interesting to see are they still stable and could this be why, because they couldn't move forward because they're doing less or they're doing more with less.

Um, so that's, I mean, and that's a whole nother topic, Alan, and I don't wanna like open a can of worms, but I do think it will be interesting to see, like, have we hit a stagnation point because we don't have enough workers to make us move forward. Something to think about. I we, we've seen this in other things, right?

25% more with 25% less. Anyway, I think we're gonna need to, uh, call, uh, a close to this episode of CD Foundation or C excuse me, CD Pipeline by the CD Foundation. Um, I wanna thank each and every one of you for coming on.

Lori is always, thank you for co-hosting. For you guys watching this, please go download the report. There's just so much in there.

I mean, I hope this has stimulated you to go do it, but really the report is out there for you guys to use, not for us to pontificate about. Um, everyone, hope to see you again soon on another CD pipeline show. Until then, be well.

We're out. Bye-Bye.