 Hello everybody, I am happy to be here today speaking about unlocking high performing teams with open source. I'm Tracy Miranda, the Executive Director of the Continuous Delivery Foundation, and let me introduce myself. So I've been at the Continuous Delivery Foundation just for the last month, where before that I was director of open source strategy at CloudBees, where I got to work closely with the Jenkins and Jenkins X open source community. And I've also been heavily involved with the Eclipse community, including being on the board of directors there for a long while. So in general, you could say I am a big fan of open source, so I love everything about open source. And so yeah, no surprise that this talk today features how you can leverage open source to make the teams better. So you feel free to get in touch with me either on Twitter, at Tracy Miranda, LinkedIn, or I also have a blog where you can meet me. So on to the talk today. And the first question I think we need to ask ourselves is, what does it mean to be a high performing team? And why does it actually matter? And the reality is that in the world we live today, every business is under tremendous pressure to transform itself into a software business. And continuous delivery is a cornerstone to this. If you imagine an organization that can deliver new features faster than the competition. Or if you imagine an organization that can take advantage of fast feedback to build a deeper relationship with its users. Or imagine an organization that can pivot when needed to respond to industry and world events. And that is the big differentiator that continuous delivery and delivering software to end users brings to an organization. So today, we're very fortunate to have some amazing research in this area. This is thanks to the State of DevOps report and also the companion book known as Accelerate written by Nicole Forsgren, Jess Humble and Jean Kim. And this book provides research back information on how you can go about building and scaling high performing technology organizations. And this quote in the book from Nicole Forsgren, which says, 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 what the book does outline is exactly what we mean today by being a high performing team. It provides for specific metrics, often known as the Dora metrics by which teams can measure their performance. Now, two of these metrics look at the speed of your software delivery, how frequent are your code deployments and how long does it take you from the moment you commit your code to the moment it gets out to the world. And then the other two metrics are focused on security or safety. So how long does it take you to recover from incidents? And what is your change failure rates of every time you make a commit or push some code, how often does it fall over? And as you can see from the numbers on the slide, the folks who are doing all these things really well are significantly better. You see the incredible numbers like 46 times more frequent code deployment up to 2,000 times faster than those folks who aren't doing that. So that is in a nutshell what we mean by being a high performing team. And one of the key things to take away from the slide is you don't have to compromise speed for security. You can have both at the same time. So how do you go about doing this? So the accelerate book is pretty awesome because it maps out a whole set of capabilities related to the research show that teams who are these high performing or elite teams do. Now these capabilities are divided up into different types of categories. And in particular, one third of them or the first eight are what we call continuous delivery capabilities. So practices and capabilities that will help you focus on delivering software. Now, just before we go more into what this means and how open source can help. I want to position three things that are often used in an interchangeable and confusing manner, especially if you are new to the space. And those are agile, CICD and DevOps or as I prefer to say agile continuous delivery and DevOps. While there is overlap with each one, they do each tend to have a distinct focus or kind of starting point. So agile focuses on processes, DevOps focuses on culture, while continuous delivery focuses on tools and automation. But not to say they don't include other things, but that is kind of the key starting point. And continuous delivery is the aspect that I want to talk a lot more about today. So what do I mean by continuous delivery? Well, continuous delivery is a software engineering approach in which teams produce software in short cycles, ensuring that that software can always be reliably released at any time. This is related to CICD because that includes continuous integration, where we see continuous integration as the practice of merging all the developer working copies to a shared mainline several times a day. But continuous delivery is the umbrella for all the processes including CI that go towards producing that software. So we know a lot about continuous delivery and we know how to manage team performance, but the reality is that the adoption of these practices is very, very low throughout the industry. And even for those who have gotten good at delivering software, the brothers been pulled out from under their feet and this has made things very complicated in this area. So the way I see it is there's three key problems affecting organisations who want to get better at continuous delivery. First of all, the rise of microservices and cloud native technology. So once upon a time we would have teams and it was the default there was that you would have a monolith. So teams were working on monolithic code base and deploying a monolithic application and they only had a small number of environments to worry about. Then along came microservices and cloud native architectures and they promise to dramatically improve what we're capable of delivering, especially when it comes to scaling. So you get huge benefits with scaling. But with those benefits also come challenges. Now teams would have to deal with a proliferation of environments and with microservices a proliferation of code bases that would make continuous delivery more important and more challenging. The second problem people would see we would see is the whole fragmented continuous delivery landscape. So with the rise of these new technologies, we've also seen a corollary rise in the number of tools in the landscape. However, it is challenging for users to figure out what works for their use case, and often putting together different tools to create a full solution is left as a trial and error lesson to the user. And we're definitely in a space where new technology paradigms are coming along at a faster rate than ever before. So if you think about things like serverless and machine learning, the rate of change in technology today is simply incredible. And then the third point is simply that change is hard. People and organisations have limits on the amount of change they can absorb at any one time. But certainly what we thought, though in the last few months, we've all learnt to keep our distance to wear a mask and to wash our hands like we're going into surgery, but most of us have. So change is hard, but it turns out that when it becomes necessary, or we have a shared sense of purpose, we can adapt faster than we think we can. In most cases, it's still a big challenge for most of us. So that sort of sums up the present. We know what and why, but we still need to figure out the how. And I think many of us are in that same position where we all want to do it together. So this was the thinking behind the Continuous Delivery Foundation, which was launched in 2019, originally as the new home to a set of open source projects. So Jenkins, Jenkins X, Spinnaker and Tecton. And the idea was that it would be this future home for projects, but also a place to drive collaboration in the continuous delivery space and use what we know about open source or at scale collaboration. So when we first launched the foundation, we had a lot of meetings and we were happy to get advice from folks in the industry like Jane Groll of the DevOps Institute and Jess Humboldt to help us focus on where what we wanted to tackle. And today, the Continuous Delivery Foundation as an open source foundation has the mission to improve the world's capacity to deliver software with security and speed. So we believe that every team can be a high performing team. And every organization can be a high performing technology organization and CDF was bigger open source partner just to help you to make that continuous improvement journey easier. And so what I want to talk to you about today is how we want to do that sort of three key ways that we're approaching this adoption of continuous delivery and helping everybody to become high performing teams through what we've learnt of open source practices and principles. So the first thing I want to share is just some efforts we have in trying to drive continuous delivery adoption. The first thing we mentioned is that there's a very fragmented landscape. So the Continuous Delivery Foundation put together this continuous delivery landscape. It's an open source document that's an interactive landscape. And this is our version 0.1. And the idea here is to map out all the different categories of types of tooling and how they come together to build a continuous delivery solution. So we know there's much more to it than just Seattle and CD. You have to think about things like version control and security management and testing. Testing is super important. So this is the place for people to take a big picture, look at things to start to differentiate what supports cloud native or traditional. And we welcome and encourage everyone to submit all the tools they use with open source of proprietary to this landscape so we can start to build out a shared outline of all the tools in the space. So the second thing we help promote is to see adoption of open source projects. So, as I mentioned earlier, CDF kicked off with four initial projects. And these projects are all at different points of adoption and usage. So Jenkins was the original tool that brought continuous integration that democratize continuous integration for the masses, and that's, you know, heavily adopted across all sorts of different industries. Then also with a lot of enterprise adoption, we have Spinnaker, which is the tool Netflix uses to achieve its continuous delivery aims. So those are two tools more on kind of the heavily adopted side of the adoption curve. But we also have tools that fall into the kind of the innovator and early adopters because these tools, like Gencomplex and Tecton, are focused on kind of the new containerized microservices cloud native world. And I'll talk a bit more about those in a minute. And then after we launch, we have additional tools that have joined the continuous delivery foundations, so do check them out on our website. But one of the things we know going back to the research from the Accelerate book is that the high performing teams leverage open source software. So in the book they elite performers leverage and plan to expand their use of open source, whereas they also they tend to use more open source tooling where there's a correlation and look performance. Had the highest use of proprietary data and tooling. I think when you look at how quickly the landscape changes, this, you know, one theory is, is that by leveraging open source you're not reinventing the wheel and if you stay kind of current and engage with the community you can adapt. You often see, you know, open source tends to be pretty resilient, especially in difficult times. And that's certainly true for kind of well sustained open source projects. So one of the other things that we're keen to promote and how you can leverage open source to get better. Is, if we go back to these capabilities, and we sort of ask ourselves, okay, how do you bring software securely and at speed. And the list is pretty long. So there's a, you know, there's 24 things you have to do there. Some of them involve, you know, the most challenging things which are creating habits and working with your teams. And what we ask ourselves is, are there some things in that list which can be simplified or in fact automated and even have tools help you do that. And, you know, I think the answer is pretty much yes. Certainly all the eight continuous delivery practices can be facilitated a lot with tooling, as well as a whole set of other capabilities. And what we're seeing with the continuous delivery and some of the newer projects is that their tools are looking at, you know, leveraging this research and building in those best practices by default. So if you take for example a tool like Jenkins X, which for those of you who know Jenkins, Jenkins X is completely different. It's a whole new rewrite in Go and kind of optimised for CICD on Kubernetes. But Jenkins X, the team there, you know, started off saying, okay, how can we promote some of the capabilities from the Accelerate book and make sure those are built in by default. And that includes things like making sure everything is version controlled. And that includes all your environments. So you can have this environment promotion through, through what they call GitOps. And also, you know, other features as well. So as we think about microservices, we're going to be in this world where you can't be writing all of your pipelines by hand. So Jenkins X will help automate those pipelines. So we're not, you know, we're no longer treating pipeline as pets. It's more that pipeline as capital. You can just kind of create them and kind of manage them as a whole set. So one of the ways Jenkins X also kind of helps promote best practices is by building on other open source projects and incorporating them to, so it's also not reinventing the wheel. And so we have a big mission at the Continuous Delury Foundation to promote tool interoperability. And actually Jenkins X builds on one of our other projects, which is the Tecton project. And this is great analogy of, you know, the Tecton is kind of the plumbing. So it provides some building blocks for CICD and Jenkins X is the porcelain. So it builds upon that and provides a great user experience. And we'll leave the toilet analogy at that because we're not going to say what that means about what you're delivering. So it's really like the whole philosophy of Tecton, and this is a project that came out of Google. It came from the Knative platform, but it's already been heavily adopted by IBM and Puppet, who are using those same building blocks for their platforms, and even has heard a great story from eBay as they're kind of rebuilding their continuous delivery platform and looking to leverage Tecton. So it's by using these tools and taking advantage of kind of the latest and greatest that you can avoid the technical debt, and you can build kind of conformant systems that make the most of today's technologies, and that will evolve thanks to the ecosystem over time as things change in the industry. Okay, so interoperability is a big focus as well. So as a community, we want to also drive the future. So besides the Tecton, we're looking at ways that we can improve the state of delivery for the entire industry. So it might be through common APIs or metadata. One of the really interesting discussions is why can't all the tools have a standardized way to express release metadata. So it's a great community where lots of like-minded folks are coming together and sort of having these discussions and saying, how can we all make the most in open source so that we're working together across the ecosystem to make things easy and help us all get better at software delivery. And if you're interested, here's where you can get involved in those conversations as well. So the third and final thing is, I want to address, is the whole idea of change is hard and it's challenging to set up new habits and change how your team has been behaving. So these are the initiatives where we want to help you on your continuous improvement journey and make that easier. So the first thing we hear a lot is, okay, when it comes to these best practices, you know, what are they and how can we get there faster. So accelerate book maps out a lot of these capabilities, but then how do we go deep into that and then how do we put them into practice. So that is a key thing that CDF will be focused on in 2021. And we'll be looking at a best practices working group where everybody can come together to do this. And this initiative is being led by Michael Galloway of Netflix. I'm going to pause for a minute and we're going to switch to Michael Galloway here himself, just introducing that initiative to kind of give you a sense of what we want to do in this area. So take a look at this. Continuous delivery is a goal for many organizations, but today every organization that wants to achieve that is forced to go through the same cycle of trial and error and expensive learning before they can reach that goal. What makes this especially painful is the fact that many of the lessons that organizations end up learning were lessons that others had already learned before. Lessons like what are good strategies for reducing blast radius of software changes? How can canaries help increase confidence in a delivery workflow? As a key goal of the CDF, we're going to invest time into creating a living community driven knowledge source to start capturing and distributing the various best practices that have been acquired over the years by our member organizations. It is our hope that with this resource we can reduce the time and complexity for organizations to finally succeed in establishing a true continuous delivery workflow. So that is best practices at Continuous Delivery Foundation and check out our website if you want more details or if you'd love to get involved. The other community we currently have for helping drive adoption is the End User Council. The Continuous Delivery Foundation brings together end user organizations. These are folks who don't directly produce software, but they use it for their operations. So some of our member companies like Netflix and Capital One and eBay would all be end user members. So we have an end user council where folks meet together to have these great discussions in a kind of safe and a neutral environment. And they kind of compare notes of, you know, what is your approach to governance? What is your approach to compliance or security? And just have really good peer-to-peer discussions to see how other people are managing things to get good context rich understanding, you know, the organizations with 100 people, organizations with 10,000 people, and what difference does that make? And so this is something being led by John Mark Walker of Capital One. And if you're interested in joining some of the meetings, please check out the link there and you can follow the links to us for an invitation to our next end user council and just be part of that conversation. So those three initiatives kind of really tie into what we're trying to do at CDF. So CDF is all about people collaborating with transparency, diversity and openness, and this makes all the difference to innovating at scale. So to conclude, I think we are very lucky as we all become, you know, a software eats the world, we know what it means to be a high-performing team, and the awesome Accelerate book gives us the high-level steps we need to follow to unlock high performance. And as you've seen, continuous delivery practices are key to this. So while microservices and cloud-native technology have changed the game and in some cases have forced us to kind of rethink our systems and the way we've set up our teams, we can look at kind of tackling that. So even though the change is hard, open-source is the key to kind of unlocking those capabilities and practices. So one thing I encourage you to do is to adopt open-source technologies to make the most of modern software delivery. So look at some of those projects as you're building blocks. And then join open-source communities to make your continuous improvement journey easier. So to work with like-minded folks who are also tackling the same problems and also trying to figure out how they can kind of continuously improve. So I naturally invite you to get involved with the continuous delivery foundation. You can check out more on our website. We have a pretty awesome community. These are some of the folks who got together at our virtual event just a month ago at CDCon. And yet we try to operate at the space between continuous delivery, open-source and building a global and diverse community. So thank you very much. I'm happy to answer any questions and we would very much love to welcome you to join the community building the future of continuous delivery. Thank you.