 Hello everybody. It is my pleasure to be speaking to you today at OpenJS World and I'll be talking about unlocking high-performing teams with open source. So let me first start by introducing myself. My name is Tracy Miranda. I'm the Executive Director at the Continuous Delivery Foundation and the recurring theme in my career has always been open source. So I've worked with the Jenkins community and before that was heavily involved in the Eclipse open source community. So in short, suffice to say, I love open source and communities. So for today we'll be answering the question, what does it mean to be a high-performing team and really what does it take? So as a starting point to answer that, I'm going to start with a proposition that today every business is a software business or at least is under tremendous pressure to transform itself into a technology organization and continuous delivery is key to this. So delivering new software features faster while making sure that your services are solid and secure is the key differentiator for almost every business today. And so we can think about continuous delivery as being critical to how teams deliver value. So when we think about those benefits to an organization, picture an organization that can deliver new features faster than its competition or picture an organization that can pivot to respond to industry and world events or picture an organization that can take advantage of fast feedback to build a deep relationship with its users. So these are some of the benefits of continuous delivery. And it's not just at the organizational level. It also helps a lot with your processes and with your teams. This is my favorite part. Like these processes help create a high trust culture and most importantly reduce burnout, which at a time when we have so much to contend with, it would be really nice if certainly in our professional lives we can do whatever we can to reduce stress and burnout when it comes to delivering software. Okay, so what is continuous delivery? It's essentially a software development practice in which teams release software changes to users safely, quickly and sustainably. I'll talk about a little bit more how this has changed recently. We have been delivering software for a long time, but the rise of microservices and cloud-native architectures has caused a corollary rise in continuous delivery practices. Continuous delivery includes the practice of continuous integration, which is, as many of you may be familiar, the practice of merging all developer working copies to a shared mainline several times a day. And before we go further in looking at this, I want to position three things that are often used in a slightly interchangeable and confusing manner, especially if you're new to the space, you will often hear people talk about Agile and then continuous delivery, or CICD and DevOps. While there is overlap, each one tends to have a distinct focus. So for instance, Agile is focused on processes. And yeah, I tapped to this great blog post from synopsys.com. And then when it comes to DevOps, DevOps is an organizational and cultural movement that aims to increase continuous delivery. So as a result, you see it will focus on culture. And then continuous delivery focuses on the tools and automation, almost seeing that as a way to drive culture change. So we have seen in specific cases you have great tools, and really be that point that helps push your team's culture in the right direction. And so for the rest of the talk, I'll be talking from that perspective of tools as that basis for driving change around software delivery. So I start every talk by telling everyone how lucky we are in this day and age and when we're delivering more software than ever, that we have this incredible research around what it takes to build and scale high-performing technology organizations. And this comes from the Accelerate book, which if you have not checked it out, I highly, highly recommend it, written by Nicole Forsgren, Jess Humble, and Jeanne Kim. And it's a partner companion to the State of DevOps reports, which they ran for a few years as well. And my favorite quote from that whole book is from Nicole, where software delivery is an exercise in continuous improvement, and our research shows that year-over-year, the best keep getting better, and those who fail to improve for further and further behind. So yeah, News Flash, Standing Still is just not an option when it comes to modern technology development. So, but the book then goes on to break down what it does take to build and scale your organization in this way. And these are in the form of 24 specific capabilities to drive improvement. So that's a lot of things to manage all at the same time. But I want to focus in on the first eight. So numbers one to eight over on one side. And these are specifically what we call the continuous delivery capability. So pulling together version control, automated deployment, continuous integration, security. These all come together to form a fundamental basis of improving how your team can be high-performing. And as you're making improvements in this space, the other thing well-spent spells out is how you go about measuring your success to see how to track your progress. So the book talks about the four metrics, so two on speed and two on stability. Unlike other metrics, these are super important because they not only kind of fall in this domain of IT metrics, but they are also business metrics. And this peer-reviewed research has shown that they correlate with high-performing teams and good business outcomes. So on the speed side, it talks about how frequently is your team deploying software? Is it daily, weekly, monthly, yearly? And then what is your lead time from the time you push to that change gets to production? So those are your two speed measures. And then when it comes to stability, you can think about it as, you know, how many failures are you having per the number of deployments? And then secondly, how long does it take you to restore services? So what is that time it will take you to recover when something goes wrong? So we have this great book, Accelerate, and we have all these amazing benefits. So we kind of know the why and we know the how of continuous delivery. But adoption is still not as widespread as you might think. And that's where we have the Continuous Delivery Foundation coming in. So there's about three things, the way I see that prevents people from being as far down in their software delivery journey as they'd like. So one is this rise of microservices in cloud-native technologies. It's an amazing game changer. It allows us to scale incredibly. But at the same time, it's a completely different paradigm of, you know, lots of environments distributed, code bases, and it leaves teams with a lot to contend with. You know, it's just an explosion of environments. And that has in turn also led to a lot of tools emerging in this place. So it's a very fragmented landscape. It's very difficult to figure out how to put together an end-to-end solution. And finally, change is hard. We all have limited amounts of change that as people or as organizations we can do all at the same time. So it's very tricky to kind of evolve our tooling and get away from technical debt. So in response to these kind of challenges, the Continuous Delivery Foundation was set up back in 2019, partly to nurture open source projects. And I'll talk a little bit more about these later. But in general, we see us as having this wider mission of we want to improve the world's capacity to deliver software with security and speed. And there's this saying we have in technology that the future is here. It's just not evenly distributed. And this is definitely the case when it comes to software delivery. But what we have seen is we believe the power of open source collaboration and use of technology can incredibly help level the playing field and make it easier for folks to get better and better in this way. So today, I want to talk to you about three ways the Continuous Delivery Foundation is approaching helping the industry and helping people who want to go on this journey to becoming high-performing teams. So the first thing is around driving continuous delivery and adoption. And we approach this with a number of different initiatives. So we have a Continuous Delivery Landscape. For any of you folks who are familiar with like the Cloud Native Computing Foundation, they have this amazing science here. Landscape also sort of known as the Hellscape and in the most affectionate way. But what we're trying to do here is zoom in specifically on software delivery technologies. Sometimes we fall into this trap of thinking it's CINCD, so it's just integration and deployment. When really there is a lot more to it, to deliver software, you need to get your testing right, you need to have potential analytics and monitoring, and security is super important. So the idea here with this, we're putting together this landscape to try and give people first a high level view of all the different options in the space opens also not. And this is all open to contribution. So if you see a tool missing, please do submit a poll request. So another initiative I want to touch upon is that we have an End User Council. These are for folks who are working in organizations who use Continuous Delivery Solutions, to put together end-to-end solutions and making them work for their use cases. So the group meets monthly to have these in-depth focus discussions on specific topics. So for example, we have a lot of folks from the FinTech space, and they'll need to talk about the specific governance and compliance regulations they need to meet with their software pipelines. We also have wider discussions around developer productivity or measuring success. And we're also looking to help drive the direction of tool development. So the people who are using the tool can give feedback to the people who are creating the tools. And one thing you'll see on our website is that group has put together an End User Council Plan where they also map out an editorial calendar of the key topics that everybody sort of agreed on. Hey, these are things we want to have deeper discussions. We want to spend time on it. It's not like they're in-depth discussions, and it will take time to sort of work out what we're doing, compare notes with other people in the industry, and also figure out where we should be improving. So you can take a look at some of the resources coming out of that group on our website. So going back to the three areas in highlight, the second one is around open source projects in this space. So the CDF launched with four key projects, Jenkins, which I'm sure many of you have heard of, and have used as used by practically everybody in different ways. Then we've also got Spinnaker, which is the incredible technology that came out of Netflix. And then we have the newer projects in the cloud-native space. And I'd like to look at it this way from an adoption perspective. So a lot of folks are using Jenkins and have been for many years, and Spinnaker has also got some great adoption. And then on the other hand, as we have cloud-native technologies and more people moving over to microservices, we have projects like Jenkins X and Tecton, which are focused on building on Kubernetes and providing options for how you can build your CI and CD pipelines and have them just with a lot of scalability and taking full advantage of all the benefits of being in a distributed environment. And one of the ways we like to think about our open source projects, so we have them at every end of the adoption curve, but we also try to push our projects to help tie to these best practices or to these capabilities. Because when we look at the list of things that the research says we need to get better at, there's a lot of things on that list. And we have to ask ourselves, is this something that software tools can help us with? Tools will solve all your problems and they're certainly not going to bring around changing your culture or making your team better, but are there some things we can trust to tools so that we can focus on the harder things that take longer to bring about change? And I would argue yes. There's a whole set of things where if we can have tools that kind of lend ourselves to more opinionated workflows, they can set us off on this golden path. So in particular with tools like JenkinsX and Tecton, we're really looking at it that way of saying can we set out with these tools that encourage best practices by default? So moving on to the third point first we talked about general continuous delivery adoption, second we talked about projects. The third side I'd like to see as the community side. So what can we do to make this continuous improvement journey easier? We talked about earlier change being hard and we're always looking for ways to make easier for people to bring about that change in the organization and have other folks to talk over some of their decisions and choices and see if they're on the right path. And one of the other ways we like to approach this is saying how can we simplify things for the whole industry? How can we make solutions easier, especially when it comes to this explosion of tools and choices? And there's a strong set of folks who share this idea that we need to promote interoperability. We need to have standardized building blocks. We shouldn't be reinventing the wheel and we should really drive for common APIs and metadata and that will kind of improve the rate of adoption and the way the industry can adopt end-to-end solutions and beginners can get started and things like that. So to that end one of our most active special interest groups is the SAKE interoperability. It meets every two weeks and we have great conversations where we're trying to bring people together, trying to find common ground and it's spinning off quite a few initiatives. For instance, we have a focus group, a special interest group on events in CI CD saying okay, let's standardize how we talk about the events you get from a CD pipeline and let's see if we can drive for different tools to all adopt the same strategy so it gives us these building blocks to build upon. And similarly, the Tecton project, if you take a look at that, it's got some great building blocks for anybody looking at continuous delivery in a cloud-native space. And one of the other kind of initiatives that sort of emerged as super important when we started those discussions in the interoperability group was this around terminology. Even as you get started and you start moving between different tools or looking at different tools, you find that different tools will use different terms for the same thing or they'll use a word in a different way and the scope is slightly different. So we've tried to capture that as well in what we call our Rosetta Stone for continuous delivery. And it's a page in GitHub which it kind of compares and contrasts the terms and it tries to drive some clarity around these terms so we can make people's life easier when they're looking at and evaluating different options for their continuous delivery. So that was kind of a whistle-stop look at the ways that continuous delivery foundation is trying to bring about this change. So striving for continuous delivery adoption, promoting the sustainability of open-source projects that help with best practices and then just bringing together the communities in ways that we can make life better for everybody through interoperability. So I want to sum up when we asked ourselves in the beginning what does it mean to be a high-performing software delivery team? The Accelerate book spells that out for us. We need to continuously improve in these practices and we measure that against how quickly we're deploying software and how safely we're doing it and how well we can recover when things go wrong. While we're trying to make those changes, microservices and cloud-native technologies have drastically changed the game so we're having to evolve while things are changing under our feet and change is super hard so it's something we have to contend with but the option for staying cell doesn't really exist for any kind of modern or evolving organization. But nevertheless, open source can come to the rescue so in a couple of ways we can think about this. One, to take a look at open source technologies, anything from Jenkins, Detectons, Spinnaker and some of our other newer projects and these help make the most of modern software delivery so you're not reinventing the wheel or maintaining software that already exists out there. And then secondly, just being part of open source communities that are undergoing the same journey really helps make life easier for everybody. And in that vein, I want to finish off by saying after OpenJS World, we also have our annual event at CD Foundation so that is CDCon just around the corner and if anything I've said today has piqued your interest, I would say it's one of the best places to come meet the community. We have a lot of interactive birds of a feather sessions as well as talks from experts and people doing their best on this journey so it's an amazing place to meet folks, learn things and also have fun in a very welcoming community so would love to welcome you to join in with us. And I'll leave it there, please check out our resources on the website or let me know if you have any questions but I look forward to joining the community building the future of continuous delivery. Thank you very much.