You. Every January, thousands of people go out and buy treadmills, and come February, the vast majority of them wind up looking a little bit like this. And there's a reason for that. Basically, what it boils down to is one simple truth, and that is that buying a treadmill doesn't make you a runner. Now, you might be wondering, well, wait a minute, what in the world does that have to do with DevOps? Well, as it turns out, there really are no magical tools. So just as going out and buying a treadmill isn't going to magically make you a runner, going out and investing in bring new CI CD tooling, brand new project management software, et cetera, isn't going to magically, in and of itself, take your team and enhance your entire DevOps process. Now, don't get me wrong, tools are important. Having the right tool does in fact make a difference. But the tool itself is only going to be helpful if it's being used. Now, a couple of months ago, I participated in a set of roundtables at GitHub universe. And these roundtables were attended by all sorts of different DevOps professionals, all sorts of different leaders, sea level folks, et cetera. And if there was one common theme throughout all of the conversations that we wound up having, it was this. The most common blocker to being able to implement new techniques, new patterns was team culture, that all of this investment was being made in the tools, but nobody was using them. So rather than focusing solely on what some cool new tool can do for us, let's instead turn our attention to how we can actually use those tools, how we can actually implement the necessary changes to take our DevOps practices to the next level, and what it really all starts with, and I'm going to work through kind of three main key points here, is, number one is asking the right questions. So going back to the beginning, buying a treadmill doesn't make you a runners. I'm now a runner. I didn't start life as a runner. It was something I picked up about ten years ago. And the reason that I became a runner was because my body had found itself in a shape, in a level of fitness that I just wasn't really happy with. So I wanted to improve upon that. But I knew in order to do that, I was going to need some form of exercise, some set of habits that I was going to be able to stick with. And in particular, I needed something that was going to be portable, and I needed something that was going to give me tools. And the great thing about running is all you need is a pair of shoes. You don't even need that treadmill. And there's always some new race, there's always some personal record that you want to be able to beat. I want to go a little bit faster here. I want to be able to run a marathon. I want to run some new distance. So I had those challenges and I had something that was portable and so that was going to allow me to achieve my primary goal. What was my primary goal? Well, it was to get myself fit and to make sure that my body took on a shape that I really kind of wanted it to be able to take on. Let's bring this then into our software development processes. And we need to start by asking the right changes, by asking the right questions even. And number one is why do we want to change? So it's not just simply a matter of, hey, we want to start automating CI CD. It's not just simply a matter of we want to adopt new agile methodologies. The real question is why? What is it that we are bring to achieve? I didn't set out just to go run. I set out to try and improve my shape and try and improve my fitness. So what is it that we're trying to improve? So let's take an example of we have a mobile app, and our primary challenge when it comes to our mobile app is we're not as responsive to customer requests as we would like to be. So we have bugs in our application. We don't have a really good methodology for taking customer requests, taking customer feedback, being able to bring that into the product and our process of, in turn being able to add those features and deploy that, but is also problematic. It's shoddy. So what's our real goal here? Our real goal is to be more responsive. Our real goal is to try and ensure that our mobile app is going to be updated in a timely fashion. So that's our real goal. That's our real why. Once we've established that, then we can turn our attention to the how we're going to do that. Then we can start to find, well, what tools are we missing? What are the challenges, what are the barriers that we currently have? So is our CI CD solution meeting our needs? And if it's not, then we can take a look at incorporating that new tool. But you'll notice that we're starting with the why. What is it that we're trying to really do here? What's the core of it all? Then we can start incorporating those tools and identifying the challenges that are currently getting in the way of us being able to achieve that goal. Additionally, when it comes to making these kinds of changes, we want to not just identify what tools we're going to need, we want to not just identify what processes we may need to implement, we also need to identify who is key to success. Because again, it's all about culture. If we can get everybody on board, the rest kind of doesn't matter. Now, when people start to look around and try to identify, okay, well, who are going to be the key voices here? People typically start with the obvious, which is going to be leadership, it's going to be sea level people, it's going to be our managers. And don't get me wrong, that's certainly going to be important. That I remember years and years and years ago that I was working with a team to try and help them get from a waterfall methodology to something that was going to be more agile. And while the manager kept insisting, oh yeah, I'm all for it, I'm all for it, I'm all for it, in reality, he wasn't. And on top of that, he was also listening to a couple of curmudgeonly developers that really weren't on board either. And so as a result, the whole project kind of was doomed from the start here. So we want to identify who's going to be key to success. So certainly, yes, it's going to be all of those managers, c level people, 100%, but it's also going to be individual developers, it's going to be my mentors, it's going to be my leaders, and it's also potentially going to be a couple of those, hopefully lovable curmudgently developers, the ones that are strongly opinionated, because if I can bring them over to my side, if I can impress upon them the importance, the why we're making these changes now, they can be champions for the cause, they can be champions for the change that we are trying to implement. So why are we trying to change? What is that we're really hoping to do? What are the challenges? What are the roadblocks? What do we need to actually invest in? And then finally, who's going to be key to success? Once we've established the right questions, then we need to establish a plan. So kind of kicking this back again, my plan again, just trying to lose weight, find a particular set of fitness, was to run a half marathon. For those of you not familiar, that's 13.1 mile, 21.1 km roughly. So I had a plan and it was going to be to start from a particular set of mileage very low because I was really just starting as a runner and then building up incrementally until eventually I was going to be able to run that race. So I had a plan. I put that forth and now it was my job to start to follow that plan. So let's now bring this back to our scenario. So we know we've established our real goal here is to improve upon our mobile app, that we want to be able to be more responsive, we want to be able to deploy faster, et cetera. So let's start by clearly defining success. In my analogy, again becoming a runner, my way of defining success wasn't just that I was going to be able to complete the distance, but also that I was feeling more fit, that my clothes were going to fit a little bit better. I want to be able to clearly define success. So that might be that we're bring to reduce the amount of time that it talked for a piece of feedback to it finding its way into our code base, to it finding its way into my deployed application. I want to define this is where we are, this is where we want to get to. I want to make sure that it's measurable. I want to identify all of those different metrics so that way I know did I succeed or potentially did I wind up failing? So, clearly defined success. The second is to now find the right team, find the right champions to begin to follow our plan, to be able to implement this plan. Now, hopefully you've already got a handful of teams that are all set and ready to go, but you may need to make some changes to put together the right set of people to start down this path. One of the things, of course, that's going to wind up happening as part of this is you're going to be asking people to change behaviors. Potentially you're going to be asking them to do new things. And one of the biggest roadblocks is if people have already been bring the exact same thing, they're going to keep bring that exact same thing. And that's really what we're trying to change. That's what we're trying to break but of. And so one big strategy that you can use is to start to form new teams. Now, forming new teams actually does bring an additional set of benefits because it allows me to cross pollinate, it allows me to take experiences from different parts of my organization and share them together. That lessons that a developer may have learned over here, lessons that a developer may have learned over here, we can bring that chocolate and peanut butter together and find ourselves a more diverse team. Diverse teams are inherently going to be more successful. But on top of that, if we're already making this big change that I'm taking these developers and I'm putting them onto a brand new project, it's the perfect time to now start to implement additional changes. Because after all, if you're already like changing the team that you're on, changing maybe the frameworks that you're using, changing the project that you're working on, you're not going to bring with you some of those mental barriers of I've always done things this way because you're working on a brand new project. Now is a perfect time to start to develop some new habits. So identify those teams and maybe start to form some new teams as you've identifying the teams that can then be that part of that pilot, that can then be those champions, find the project for them to work on. Now, in my example, I've been talking about a mobile app, so of course that's then going to be the pilot project, but that's admittedly overly simplistic and it's being used for purposes of the talk. Instead, what you really want to focus in on is find projects, find components that are going to be meaningful, that are going to be large but not overly difficult. Try and find a better way to kind of explain that. Sort of a Goldilocks for anybody's familiar. Porch is too hot, porch is too cold. You want to find something that's just right. So this might be an internal service or an internal library that is used in a lot of different projects. Maybe it's being shared. And what's nice about that is maybe it's something that's relatively small, maybe it's handling auth or whatever it is that it happens to be doing. But it's really important to the success of the organization, to the success of multiple applications that are now using this service, that are now using this particular library. That winds up being like a perfect spot for me to start. So let's start to work on implementing our updated processes. Let's start to work on incorporating some of those new tools, some of those new techniques into that pilot, into that project. Or maybe it's, hey, we know we're going to be developing something new. Maybe we've been doing an Android app and now we want to do an iOS app or whatever it is that can also be a perfect pilot. And again, it's going to have that advantage since we're not already building it, that it allows us to more easily incorporate changes to that. And then lastly, number three is implement and review. So again, going all the way back to that analogy, I start running and now I'm going to start to look at am I having success? And if I am fantastic, let's identify why and keep doing those things. And if I'm not, then let me go back and take a look to see, well, is there an existing behavior that I need to change or do I maybe not have the right tool? Do I maybe not have the right plan? Is there something else that I need to maybe adjust or update to allow me to have success? So I'm using an iterative process here, bringing this back to our example of our mobile app and all of our teams or our singular team that's now going to be working on this. How can we start to implement these changes? I think the biggest thing that we can do is to focus in on adding behaviors rather than changing them from the start. So for example, one of the things that can be potentially problematic, that can cause problems is large prs, large pull requests. Because the problem with a large pr is it's more difficult to review, it's more difficult to roll back. It can wind up making changes to multiple different components inside of whatever it is that we happen to be building. And it then in turn becomes lets manageable. Okay, so I know that a point that I probably want to get to is a new behavior of smaller prs, but I don't want to go to my teams and go, hey, let's start change this. Let's start now only doing smaller prs because again, that's going to be that behavior that's maybe ingrained into them and we're not ready for that yet. Okay, cool. We're not ready for that. So instead let's focus in on trying to add new behaviors. So again, kind of going back to that running analogy, I wasn't quite ready yet to start having up all the burgers that I was eating. That's fine. That wasn't the most important thing for me to start doing. The most important thing for me to start doing was to add to what I was doing in my life. So start lacing up my running shoes, get out the door and away we go. So rather than let's change to get all of our developers to start buying smaller prs, let's instead focus on adding behaviors. So if we're not already bring code reviews, let's start to add those in. If we don't already have tools to start doing linting or automate for checking code quality or to add on unit tests and to start to run those. Let's add those behaviors in, because here's what's eventually going to happen, is a smaller pr is going to be easier to review, a smaller PR is going to be easier to add unit tests to. A smaller PR is going to be able to be updated that much easier. And so eventually what's going to wind up happening is because we're adding on these new behaviors, because we're adding on code reviews, eventually people are going to want to make that part easier, that if I haven't had a burger the night before the run, the next morning becomes a little bit easier. Same concept here, that if I'm adding on code reviews, code reviews are going to become easier if I'm using smaller prs. So what's going to happen over time? We're going to wind up naturally trending in that direction towards smaller prs. So let's focus in on adding behaviors rather than changing behaviors, especially from the start. And what we're going to find is that eventually those bad behaviors, those behaviors that are getting in the way are eventually bring to decrease. Next, document our successes and our failures. Things are going to work. Things are not going to work. I want to know in both situations why and what can I do to continue to replicate and build upon my successes and what can I learn from the failures? What changes can I make here to help ensure that we're now going to continue to move in that right direction, which then leads us to that last little circle there of iterate and grow. So as we continue to learn, let's now turn our attention to bringing on another project, bringing on another team, and continue to grow out from there. Now, at this point, sometimes people will give me a little bit of pushback and they go, hey, wait a minute, Christopher, it sounds like what you're really trying to say here is you want to implement change through groundswell solely. And that's not at all what I'm trying to say, because it does need to come from both directions, that I need my managers, I need my leaders to buy into what we're bring to do what we're trying to accomplish. That's key to success. But the other part to the key to success is ensuring my developers are there as well. And so I want to be able to grow from both directions there. So let's continue to iterate. Let's continue to identify what's working, what's not working, what changes can we make? What behaviors can we add on and then continue to grow from there? Obviously there's no magical solution. As I said at the top, yes, tools are important, but there is no magical tool. Change, particularly when we're talking about cultural change, is bring to take time and there are going to be setbacks. We need to accept that. We need to make sure that we're in this for the long haul, that we're not just simply trying something, just for the sake of trying something, that we have a clearly defined goal, that we know what it is that we're trying to do, we know what it is that we're trying to solve. So that way when there are those setbacks, we can bring that right back to the very beginning. And what's the very beginning? It's asking the right questions. Bringing in a brand new tool just because it's the cool new thing, just because everybody else is doing it, or to make a reference that some people may or may not get, just because it goes to eleven rather than going to ten isn't going to bring about the change that we hope that it might. What's going to bring about the change is, is defining those goals, defining the why, finding the right people to then champion that and then starting that process of adding on the behaviors that we're looking for, figuring out what it is that's working, figuring out what it is that's not working, and then continuing to make the changes from there.