 Good morning DevOps Chicago. I know we are all hungry. I'm waiting for a great lunch Let's keep this fun and engaging How many of you like freebies I do too In fact, I go to Costco every single weekend not to buy the huge boxes of cereals But to munch on the freebies. How nice would it be if we could make a DevOps transformation Without spending a million dollar investment so Roughly six years ago My then boss who attends the DevOps enterprise summit in Las Vegas? He summons me to his office one fine morning and This is exactly what he says Lakshmi, I want you to disregard every single goal. I've said for you for this financial year Transformed the entire engineering organization to run the DevOps way How many of you have bosses who thinks a transformation could be done overnight? I'm sure we have several of us DevOps in tech podcast and I've read about DevOps in tech articles But what does it mean to convert the entire organization to operate the DevOps way? And this was me on my way back home Borrowed a bunch of books on DevOps and sifted through them Trying to understand if there is this perfect recipe that could that could make a perfect DevOps implementation Six years later I'm glad that my knowledge on DevOps has doubled Not from the books I read But from my experiences my failures and the lessons learned from those failures and I'm glad to be sharing them today But here is a caveat The experiences that I'm going to share you with share with you today is what worked for my team and for my organization and That is not a silver blueprint for every other organization Take perspectives of today's conversation and tune in to what best suits for you and for your team and That alone will make a perfect DevOps implementation How many of you in the audience are working in teams that deliver software in waterfall model? Wow, we don't have water followers attending DevOps Okay so when my boss talks to me about Transforming the engineering organization to operate the DevOps way I Had around 40% of the teams that were still delivering software on waterfall model and here is what I did I Spent around half a million dollar trying to convert all my waterfall teams to agile teams With the hope that once all my teams run the agile way DevOps implementation is going to be a cakewalk And to this day, that's one of the biggest blunders of my career DevOps and agile, of course, they're closely related DevOps enables agile teams to deliver products to the market faster DevOps continuous integration and test automation is a huge boon to the agile teams Because you can take your products to the market as quickly as possible start seeking feedback But that alone does not mean that DevOps is a good fit only for your agile teams DevOps is a cultural movement a movement that is separate from waterfall and agile The core concepts of culture process and tools in DevOps is Extremely useful regardless of the type of software delivery model you use and that could be waterfall That could be agile that could be Kanban. In fact, in my experience waterfall teams have been extremely efficient by using the DevOps model The automation and continuous integration of DevOps Generally compresses the development life cycle of waterfall teams and your teams are able to deliver your software faster So what data do we have to prove this hypothesis? In the last six years of implementing DevOps across Huge enterprises medium-sized enterprises and startups our teams have been gathering data as to what it means to actually implement DevOps in organizations And we looked at two critical factors that most organizations try to understand when they are stepping into the DevOps world And the graph to the left is the time to adopt DevOps As you can see in the graph The waterfall teams take around 30% more than the agile teams to adopt DevOps Quite normal. Here's the reason why The waterfall teams they start everything from ground zero Unlike the agile teams that are able to leverage from the agile mindset That they've already developed within their teams So obviously when you're starting the DevOps way if your team is waterfall They are going to be slow when compared to their agile teams in terms of DevOps adoption The graph to the right shows the efficiency of the waterfall and agile teams in DevOps The waterfall teams are 30% more efficient and the agile teams are 38% more efficient Before and after DevOps adoption So how did we measure this efficiency? The efficiency was measured in terms of the throughput of the teams how much the team was able to deliver before and after DevOps adoption and The waterfall teams the same team structure before and after DevOps They were able to deliver 30% more in terms of the volume of work And the agile teams prior and post DevOps adoption. They were able to deliver 38% more And this data was collected from Enterprises of different domains enterprises of different maturity in DevOps adoption So we all understand that DevOps is a good fit regardless of the delivery model that you use Introduce DevOps to your organization and teams Here's what I did when I first started in the journey of DevOps implementation So I created this huge project plan Identified various phases in the project and said these are the objectives of each phase And you know what I didn't stop right there I went on board and hired project managers who would manage each phase of this DevOps implementation and We also brought some DevOps consultants with the hope that they are going to foster and Help us implement DevOps in a fast-track way In spite of doing all this we felt terribly so we decided to pause and retrospect why we felt and What we realized was like most organizations We looked at DevOps from the eyes of a project management and to this day I See that as one of the biggest blunders of my DevOps career Do not plan to implement DevOps by setting a start and end date to it DevOps is about a new cultural framework It is about how your people come together work together and deliver software to your customers Why would you want to put a start and end date to it? Would you not want to be more scalable? Sustainable and long-term stays with your organization So What better to do it you don't want to project plan your DevOps implementation and You don't want your project managers overseeing the DevOps. So how do you bring some structure to it? Create something what is called as DevOps roadmap and Within DevOps roadmap identify various milestones within the roadmap For each milestone identify what capabilities you want your teams to achieve It could be as simple as your first milestone you automate 10% of your test cases and for your second milestone you In you automate your deployment process a part of the deployment process So as your teams go through several milestones as they iterate They try and identify what works for them. What works for their teams and what works for the organization? Allow your teams to iterate as often as possible as quickly as possible and pivot if required DevOps is best done through iteration So how do you run or drive at DevOps transformation? So we all agree at DevOps is a best fit for waterfall and agile and We all agree that the best way to encourage teams to go the DevOps way is to allow them to iterate But what happens in most organization is that your super boss organizes at DevOps Town Hall And he says hey guys our competitors XYZ are building their softwares in the DevOps way Let's go the DevOps bandwagon How many of you are with organizations where DevOps is driven from top down? There we go so When this transformation comes from top down There is obviously a natural Resistance within your team and within your developers to adopt it The best way to do a transformation is to have it concrete have it organic from within your team and Over the course of years doing it by different trial and error I've found three simple steps that have proved useful regardless of where I implement DevOps step one Start with identifying your DevOps influencers in the team Your development influencers and your ops influencers who would come together work in a team and who would be able to put forth DevOps initiatives and Once you do that mentor your influencers Give them some ground zero rules on what you want them to do or what you want them to achieve and In a while we'll speak about what those ground zero rules could be and Number three Why do you think your DevOps influencers would work on your behalf and make your DevOps initiatives a huge success? Unless they have some sort of incentives for it And you would be the better person to know what would incentivize your team a better compensation a bonus How about this? When you want to incentivize your team Try something that's more win-win a win for the organization and win for your DevOps influencers So what I always do is I try and motivate my DevOps influencers to attend the DevOps conferences DevOps meetups Who didn't want to go to a conference in Vegas in Florida and take a family holiday as part of it While doing that also try and coach them to present their papers and findings in those conferences as a result of this You are incentivizing them by helping them elevate their career and They would bring on board some of the best practices that they would learn from the conferences so these three tips make for any successful DevOps transformation and Regardless of whether you want to do it across all your teams within your organization Or you want to start with one team and learn from that and have it succeed with the other teams as well Google for DevOps and you come across this diagram the three pillars of culture process and tools and the perfect intersection between each of those circles Possible in theory, but in practice. This is not achievable Most companies when they go the DevOps route Here's what they ask Where do I put my investment or where do I put all my resources in? Do I put it on the cultural transformation or? Do I do it on the process transformation or do I do it on the tools transformation? Are there some companies that ask? Should I give an equal share of the pie between the culture process and tools? Should I have set number of resources on culture the same number on process and same number of tools? It's actually a million dollar question Let's talk about the human analogy to this. How about we walk out of this room and we win a lottery? For $200. I'm sure we would all be excited So with that winning let's assume if we want to invest in a long-term or a short-term fund We have two options we invest in a short-term fund and in two years. We have the half a million grows to a million and The long-term investment option is in 10 years the half a million grows to 10 million What would we all choose? The long term or the short term sounds like there are no termers here. Would we all be spending our money? Yeah, how about you Sasha anybody wants to answer this I got a mic Wow Okay, I would go the long-term way I Would rather have the ten million dollars in ten years rather than having two million dollars in two years Of course, I want to have a good retirement life So any transformation for that matter. Let's draw a parallel to the technology If I were to invest in a transformation, I want the transformation to be long-term Sustainable unscalable Right, I want to put my investment in a bucket where it stays with my organization forever and That is the cultural transformation Because with the cultural transformation you're transforming the mindset of the people How they want to work? How they want to work with their peers and colleagues? Why they want to work and what they are doing to the greater betterment of the organization and trust me this cultural Cultural transformation goes deep root into your organization and stays forever for years and years So if you are going through the DevOps transformation route or if you're already in the process of DevOps transformation route Put your resources put your money put your time in the cultural transformation And then follow it up by the process transformation and then the tool transformation The culture should embody the process and the process should embody the tools So we spoke about the cultural Initiatives and the type of initiatives that could make a DevOps team a successful team If you've read about DevOps read few DevOps books Most books recommend more than a handful of cultural initiatives and Obviously, no Googles and Facebooks in the world have the time and money to invest in initiating all these cultural initiatives let alone our small startups and medium enterprises So what would be the top three initiatives that makes a great pitch at DevOps and here they are Blamelessness ownership and shared goals Before we speak about it One caveat of the cultural initiative is that it has to come from top down The leaders of your teams the leaders of your organizations Should practice and exhibit the culture before you see the teams adopting it Blamelessness Attack the problem and not the person We don't do that often Devs attack ops and ops attack devs regardless of them being part of a DevOps team Stop that and whenever you have a problem in a software try and look at what caused the problem It could be either a process a system or a workflow and Mitigate that part of the process system or workflow so that you would prevent it from reoccurring again Ownership something I've struggled a lot regardless of the organization. I've implemented devops Obviously people don't want to own things What's going to be the motivating factor for them to own an outcome? And here is what helps Whenever someone owns an outcome delivers it Regardless of whether it's a success or a failure celebrated Note even if it's a failure Celebrated because failures are the stepping stones failures or the opportunities to learn what works and what doesn't work So once your teams understand that obviously your leadership is celebrating both successes and failures People will organically come together and they'll be more motivated to try new things Because they are not going to be suspended if they are failing Shared goals Traditionally devs and orbs we are so used to sitting at far end of the building Because we are sure if we come face-to-face There's going to be the third world war We try and resist as much as possible. Hey use it in one corner I'll sit in the other corner if you wanted want something to be deployed send me a message on slack And I'll get it done for you And we are talking about bringing both devs and orbs into the same team. How do you get them to work together? Give them shared objectives set shared goals for them So if your devs and orbs have the common set of objectives and if their bonuses are based on achieving those objectives They'll find a way to get it done Regardless of whether they're sitting in the same room or whether they're sitting in the opposite ends of the building They will make sure it gets done and that Creates that culture of them coming together and working together for the greater benefit of your engineering teams So we spoke about the biggest share of the pie, which is the culture the second share of the pie is process and Folks who are in the room today you would work in organizations where There are hundreds of processes and sometimes we don't know why they exist in the first place So how do I start with the process transformation? I don't want to transform every single process as always We don't have the time money and resource to transform all the processes that we are working on so start with the process that is Performed very often by your teams The type of processes that have existed forever as in like nobody even knows why it exists and Also the type of processes where people always complain about These are the three types of process that you want to transform and I recently came across a process transformation technique called value stream mapping and With the organization that I'm currently leading So we subjected few processes through this technique called value stream mapping and It helped us understand the latency of tasks between a process Why there is a delay of let's say like four days between task a and task B of a process It also helped us understand why a certain task takes so long to complete and In fact, the biggest thing it helped us uncover is that some tasks are so risky Because it's just relying on one single person in your team to actually complete the task So use the value stream mapping technique to actually subject your processes to the technique to find out what is the Risks that your process goes through and refine your process and refactor your process and Again do all this with your devops teams Bring someone to coach you through the value stream modeling But do not help your have your mentor or your coach to tell you what you need to do Encourage your teams to come up with this process transformation tool transformation the last one last but not the least the tool transformation Most organizations when they go the devops way The first and foremost thing they would like to do is automate manual tasks and They go and spend their money on all the license tools and the subscription tools Organization or when a team is stepping into the devops world Start with exploring all the open source tools in the market I'll bet you there's One or more open source tool for every single thing you want to automate in the devops life cycle Encourage your teams to explore the open source tools Allow them to iterate and find out what works for them in the tool and what doesn't work for them and There will be a point in the journey where your team says hey I want this feature in order to automate this task and the open source tool doesn't give me that capability and That's the time to invest your money on license software and license tools You don't want to be seen as this No offense to the tool vendors here in the room We all want to start right. We all want to invest in the right thing Definitely we have lot of tools license tools that do a great job in what they do But before you find out what your niche tool is Go open source explore full blown on open source and you'll be at that point in the journey where you'll be like Hey, I want this license tool and that's the time to step on from open source to license tools to recap a Gila waterfall go devops Trust your teams to manage devops roadmap Culture over process over tools Put your money in the right thing that is long-term and sustainable 10 million in 10 years versus 2 million in two years Cultural transformation cause nothing it just really needs the right mindset It just needs the leadership team to exhibit and practice the culture that they want the teams to follow Go open source Devops is a journey not a destination If you don't mind, I'd like to invite my daughter to the stage She joined me from Toronto flew with me down here to Chicago to see me speak. Do you want to wave? Oh, I'd like to close the presentation by highlighting a conversation between me and my daughter six months ago So I came over from a conference in Toronto where I spoke about devops and It was late that night and she was right in the doorstep waiting for me And this is what she says mommy. You said you're going to talk about devops, but what actually is devops trust me I Was talking about the nuances of devops that day and here I am unable to deconstruct what a devops is to a five-year-old I'm mulling over it for a while. Here is what I came up with Devops is about working smart and Devops is a teamwork And a team work with the kids who you love to work and team work with the kids who you do not love to work So it's about developers and ops coming together and making it success. Thank you