 So hi everyone. I know it's been a long day. I'm really glad you all have stayed for this talk So we're gonna talk about what DevOps can learn from sports teams. My name is Mohit I am the co-founder of dev2prod.com. I'll tell you guys what that is a little later So let's get started First I want to clarify something. I Disagree with what Mike said this morning that DevOps is just a fancier name for sysadmin. I don't think that's what DevOps is I think DevOps is about enabling the business to go faster In a reliable manner and it's about teamwork. It's about everyone working together and that includes Everyone from your business analyst to your sysadmin to your site reliability engineer everyone working together so DevOps is really about teamwork, I think and That's really what I'm here to talk about today So with that out of the way Let's start with lesson number one So I have a question for you guys What do you think sports teams spend their time doing? Right, so most people when I ask them this question, they say playing but the real answer is sports teams spend most of their time in training I'd guess 75% of their time and this is this applies to teams and individuals from a young age when you get into You know a youth division of a sports team you're training most of the time, right? So this is the first lesson that we can learn from sports teams How much time do you spend on training on your job? You probably spend your time on features and bug fixes and your boss says, you know, you learn something on the job, right? Maybe four years of college, but at least Indian colleges don't count in my opinion as genuine training Now there is a difference between learning on the job and Learning with intent So there is this concept called deliberate practice. Have you guys heard about it? There is actually research done by Social scientists. There's a paper in 93 that came out. They studied how Experts like pianists or violinists or chess grandmasters. How do they get to that level of expertise? and the answer is deliberate practice deliberate practice is Systematic practice aimed at bettering yourself at a certain skill. It involves a lot of repetition. It involves feedback It involves setting goals for yourself and eventually getting better at something that you're doing So sports teams do this all the time, right? Everyone has a goal. You want to get better at your 100 meter run So Usain Bolt has one goal and that's what he's constantly aiming to improve That's something that we can learn, right? Maybe we can make deliberate practice a part of our team culture Maybe 20% time instead of hacking on some random project You can take something that's useful to your team and improve yourself in that direction So I'm going to propose something here where you all can help and I'm calling it DevOps cartas Do you guys know what the word kung fu means? Anyone saw Adam Jacobs keynote at chef conf? Okay, the word kung fu does not mean what Jackie Chan does the word kung fu actually means any skill which requires an investment of time patients practice to master Right, so you can actually have kung fu in programming or kung fu in chess Make sense Kata is another term that comes from martial arts. Kata is a Japanese term Kata is a form that is repeated over and over again with the goal to improve So in the Japanese martial arts, there is this concept called shu hari Okay, three words shu means you are a shoe literally means obey I think So in shu when you are in the shu state, you just copy you just do exactly what the master tells you to do You do not question Then the actions become natural to you muscle memory, right? You don't have to think it just happens then you reach the next state Where you start questioning. Why am I doing this and not that instead And then when that becomes natural to you when you start asking good questions, you go into the restate where you transcend And where you start inventing and where you start innovating Right, so I think we go through a similar state states of learning when we go from novice programmers to maybe intermediate programmers to expert programmers But what I'm suggesting is that as a community, we can collect patterns that we see that are often repeated And we can practice them People have done this already with code kata, right? Have you all seen code kata? So what I'm suggesting is that let's do something like code kata but for DevOps instead And I've created a repo at on GitHub at dev2prod slash DevOps katas So I've added two katas there. They have interesting names. One is called edigma and one is called etched in stone I'd invite you all to please take a look and give solutions to those katas How did you solve these problems in your practical life? What different approaches you used? What worked? What did not work? But more importantly, I'd love for you guys to contribute your own katas So please send me pull requests So that's about deliberate practice The next lesson, measurement So this is grafana. I'm sure all of you have seen this and implemented it Sports people are obsessive about measuring things How many calories did I eat today? What percent came from fat and carbs and protein? How much weight can I lift? What is my VO2 max? It goes on and on The Americans have taken it to an extreme. In baseball, there is this concept called saber matrix If you all saw the movie money ball, there is this corporation that studies baseball statistics And they come up with really interesting stats like for example, there's a stat called VORP Value over replacement player Which says that if I picked this guy over this guy, how many more runs would my team make over the season? Isn't that a useful stat to have? Now I know that we measure things But I have this sneaking suspicion that we measure things that are easy to measure Load averages, latencies, what have you Are we measuring the right thing? That's a question that we should ask ourselves, right? The simplest question in the pop and dig book How much time does it take to make a single line change of code and deploy it all the way to production? Do you guys have that answer for whatever you're working on? Anyone? All the way from dev to prod? So I think that's a simple thing that we ought to measure How agile am I? How well am I doing continuous delivery? We measure build times, but we don't necessarily measure everything that comes before it What about MTBF, MTTR, all these things? We know these facts, we know these concepts But do we measure them? How often do I put bugs into production? What's the interval? So the takeaway for me is that Sports people are very clear about what they want to measure They don't measure things unless they really need them So that's a lesson for us that do measure obsessively But think about why you're measuring something Have intent behind that measurement The next lesson comes from total football Everyone knows this team, right? Messi on the left there is the most famous guy in the world But he's able to score so many goals because there's an awesome team around him That's feeding him the ball in the right areas Now total football was a strategy that was invented in the 70s By a Dutch coach named Rynus Michel He was the coach of Ajax, Amsterdam and also the Dutch football team later on And he partnered with a player called Johann Cruyff It was probably the Messi of his time So what total football says is that You know how there are positions in football, right? So you have attackers, you have midfielders and you have defenders So total football is saying that anybody can play any role If you see space, just go for it Somebody else will take your place Don't say that I'm the defender, I'm not going to shoot I'm not going to score Up there if you're near the opponent's goal, just go for it So that frees up your players to be more creative To make space, to focus on scoring goals The lesson for us and I think total football is exactly equal to DevOps Is that what we should be focusing on is cross-disciplinary teams If I'm a developer, I shouldn't be putting my hands up and saying I'm not going to touch the chef code base, that's your job I'll make changes in the chef code base too, right? It's awesome actually to be able to do that Let me give you guys one challenge Try spending one week doing someone else's job With your boss's permission, of course But spend one week shadowing them or doing someone else's job It'll make you appreciate what they do much, much more I spent one week on call at my last job And I got woken up at night two or three times And ever since then I became way more careful about the code I write And that naturally leads me into the next lesson Which is empathy Does anyone know who this guy is? It's a curious choice of picture for empathy So this person is an ultramarathon runner His name is Scott Ureck Incidentally Mike Plays who spoke in the morning about salt Is also an ultramarathoner An ultra is any race that is longer than 42 kilometers Longer than 42, that's what it means This guy is crazy, he can run 100 miles And his record is I think 165 miles which he ran continuously for 24 hours 100 miles just for perspective is the distance between Mumbai and Pune Or Mysore and Bangalore He does that routinely But that's not what makes him special What makes Scott special is after finishing an ultra And he usually finishes in the top one or two He stands at the finish line, he covers himself with a blanket And he cheers on everybody who's lagging He cheers on and makes sure that they also cross the finish line And that's empathy And I think we all need to bring empathy into our lives As programmers, as software professionals When a new guy joins the team Be supportive, listen to their opinions Respect them for what they bring to the table Understand that different people have different strengths and weaknesses And empathize with them Now empathy can only happen if you have actually done it yourself You have to have run yourself in order to cheer someone on I have run the Mumbai Half Marathon And I can promise you that the maximum encouragement that you get Is not from the spectators It's not from the energy drinks or the gel that you're eating It's when a fellow runner tells you that you can do it, you can finish this race Because he's feeling the pain too, right? He's running in the heat too, he or she So that's what I'd like us to take away That we are all in this together, we're all in it as a team We should enjoy it, we should make it fun And we should empathize with each other while we're doing it So those were my lessons Quick note, devtoprod.com is a site That we've just launched today and we're looking for feedback from you guys What we're going to focus on is making bite-sized videos On devops and continuous delivery And we're also trying to create other repos Like devops, katas and things like that So we'd love for you to sign up, give us feedback, tell us what you think That's me on Twitter, Mohit Tate And on GitHub, I am pastafari That comes from Flying Spaghetti Monster fame So thank you all for staying back for this talk I hope you had a good time Any questions? Yeah, so you said about that philosophy where you spend some time doing someone else's job Or you know, like if you are a mobile developer You spend some time doing web development for a week But is it a practical thing that can happen in a fast-paced startup? So like you said, you spend time doing on-call Probably that company was big enough to basically afford one person Switching a role for a few days or so But in a startup when we really want to set up this culture How can we manage that? So that's a great question So to answer one part of it, the company where I worked previously Developers were also on-call So it was a part of my job as a dev to also be on-call So that took care of it Secondly, I think in a startup we already play many roles I think in a startup if you are a small team Then you are already playing many roles You are already probably doing QA, you are doing your own dev You are deploying your own code So you already have that kind of feel for what all the roles mean This probably applies more to larger structured siloed teams Where a person is a QA, a person is a dev, a person is a BA That's where I think it would be more beneficial So I am not sure if startups are the right context for that suggestion Anyone? I guess we are done Thank you