 We'll start with the short survey go to Kahoot.it enter this pin number will be on the sides as well Let's start less frequently than six months or more less frequently than six months more frequently than six months more frequently than a month and more frequently Than a week multiple times a week Choose your answer those who are on the survey and if you're not yet you can still join Kahoot.it with this number and put the sound from the computer as well in parallel, okay So what we see is that not many of you are still on the survey So let's wait a couple of seconds until more people join Seconds to join But we see that most of you Here in the room are doing it either Between a month and six months or every couple of weeks. We have a couple of people delivering every couple of weeks. Okay, so next question Let's hope we have more participants by now. How happy are you about your delivery frequency? Don't care much Sad I'm okay with it. I'm happy about it in parallel At least that's a good sign Most of you are not happy about your delivery frequency. Okay, that's the six here Some of you are okay with it and a couple are happy about it Go find those people later on and learn from them. So another type of question delivery frequency is not enough Nothing answers Some of you I mean that the direction is changing towards more than months than the weeks Maybe it's more people. Maybe it's something else related to Delivery frequency is not enough in order to deliver fast Most of you are in weeks a couple very few number in days and Nobody in hours and how happy are you about it about your current delivery time? Next question looking at something completely different. What are you doing up here? I thought you were downstairs boxing chocolates. Oh, they kicked me out of there fast. Why I kept pinching them to see what kind they were Department I've been in. Oh, I didn't do so well either. Oh Right girls. Now. This is your last chance if one piece of candy gets past you and into the packing room unwrapped You're fired. Yes, ma'am Sensitive about it than 2001. I was on the depth side initially Engineering myself then later on managing and leading engineering teams and organizations and in the last I don't know almost nine years of I've been dealing with agile in the last Seven years in Agile sparks where I'm a coach CTO and partner doing all of those things Kanban flow Scrum Lynn startup all of those things that have led me back into The DevOps world, which we'll see we'll see how the connection is made later on so basically When we look at the reason That people are interested more and more in DevOps these days. It's a combination of two things One has been described here in the conference several times It's the need to iterate faster and faster to deliver better results to compete on the basis of speed in face of uncertainty whether it's a Cinefin the Kinefin that Snowden talks about whether it's Some of you that heard the Jeff patents talk about we we are going to fail We don't know exactly what we're looking for. We need to search for the right product faster Instead of making too many assumptions. That's the basis that we're talking about in More and more organizations these days The reason for that is that the targets are moving and they're moving faster and faster in parallel to that We see more and more and more accumulate work accumulating We see that work accumulating and the need to search faster Being in conflict with the fact that we're working on complicated systems And if we don't have the right time to deal with those systems because of what Lucy and Her friend there Had to face we're adding more and more problems more and more complexity more and more technical debt to our systems This leads us to focus Very locally we're trying to do our thing and deliver to our local Success criteria if it's dev it means that we try to deliver Working software Hopefully but not necessarily something that will be easy to deploy or operate or that will be useful To the users not because we're bad people but because we don't have a chance We're looking locally and we're focused on making that happen When that happens we will see situations where there are arrows done stream when in operations or in production But and we even know about it, but we say okay They will catch those errors In some cases it will be their work to deal with it not our problem in other situations It comes back as problems for us and then we spend too much time Asking about okay, how do we deal with surprises and defects in our scrum sprints and how do we plan for it? All of this is called failure demand System thinking terms and this basically creates the situation that will fire fighting all of the time and Because we're firefighting all of the time we create an even bigger problem of complexity and overwork an unsustainable pace all of this is called basically the IT download spiral because it's Reinforcing itself all of the time reinforcing okay, and Agile should have solved it right we should have Created better solutions with better quality working tested software zero defects We should have put all of the people together to work on the same team but agile was The agile manifesto came out in 2001 people used agile even before but when we go into organizations these days even organizations that implemented the agile and for sure there are a lot that Have not done too much about agile or have done something they call themselves a trial, but they're not really Most of them are not leaving this dream Okay, most of them are very far from it Why is that because when you look at the real world there are a lot of problems create making this dream happen There are a lot of forces like Kent Beck talked about the forces that are applied when you try to move faster When you try to really work In an agile iterative mode They are forces that our current organizations are simply not fit to deal with it's quite easy to create a new Organization from scratch and build the right architectures the right organizational structure Don't deal with the legacy and work well. It will be easy for those guys to deal better with Agile and competing on the basis of speed then this Jumbo jet Okay Another reason for our problem is that all of our processes are optimized for efficiency or most a lot of our Processes are optimized for efficiency for creating huge amount of things. We learn to think the waterfall style We learn to think in big batches. We want to create a lot of coffee, but if we want small different amount of coffee or Different style of coffee or fresh coffee. It will be very very inefficient to create it using these coffee pots So this creates a real problem for organizations trying to move faster Deliver more frequently so we do see a couple of companies That are Doing things differently. This is where the dev ops movement or I call it the real agile movement Started these are the web operations companies which understand that they don't have a chance they are willing to invest a lot of energy in Good architecture in a lot of automation in building the right kind of Structures in having their right types of engineers and for these guys This has been the reality. They've shown the light of how to do this and a lot of other people are looking at it These are called also the unicorns in the dev ops world the stuff you look forward to you aspire to but it's Typically beyond reach most of us will not be in such a company In a lifetime, but looking at it more recently. We see a lot of other companies doing dev ops Striving to do this thing for real not just those companies that have it easy or Invest a lot of energy and a lot of money in doing it because they can't a lot of other companies are doing it If we look at it Actually, there are more and more companies that are actually gaining business results by implementing dev ops or real agile Based on a recent survey that was published in 2014 first of all it seems that those companies that are successful in general Have an effective idea organization that shouldn't be too much of a surprise They are twice more likely to exceed profitability of other companies and have a higher market capitalization Okay, so far so good It starts to be more interesting when you see correlation between those highly effective high-performing IT organizations and the fact that they're actually more agile not doing agile not doing stand-ups or scrum or sprints or Kanban but by looking at their results They deploy to production 30 times more frequently not only that their lead times Are 8,000 times faster than their peers? That's being agile That's being lean That's the numbers, right? There are probably companies with very horrible lead times in the years in that survey as well as companies In the hours. I don't know It's very weird. I agree, but actually those numbers are from a survey where Statistics doctors went over the details. It's not some hodgepodge survey But not only that they're not only faster they are also more reliable So the so far the operations people could have said yes those organizations are able to deliver more frequently But there's probably a price to pay It's probably Lower uptime and the system is down for more time when it's done, but that's not the case Actually speed comes with reliability Okay twice the change success rate and 12 time faster mean time to recover for those high-performing IT organizations so the question is how do they do that or How to go towards that direction without You know scratching your company and creating Another one instead So I'm not going to solve all of those problems in the talk today but I'm what I'm going to Discuss is a way to start this journey. Okay, and that way is Kanban Kanban and basically the free ways towards DevOps which come from Jin Kim Kanban is very aligned with those three ways as we'll see later and basically what we're talking about is First of all to think about the system and focus on end-to-end flow then after you do that you amplify feedback loops and Based on those two you then continually improve and experiment and improve the system So let's start with flow back maybe survey how many of you And how about Kanban? How much do you know about Conference or something same amount of used Kanban or know all of the Principles and practices so the first thing you should know about Kanban is that Kanban starts with visualizing Visualizing typically with a Kanban board, but it's not a must Kanban board typically takes your process breaks it into the Different phases or activities between the point you start something in the point you finish it and for each Walk item that you have currently in your process you have a card that card moves throughout the process and By using that you can see how much work is at each step of the flow And start to understand what's going on. It's basically a way of bringing your Design factory to life so everybody can stand next to it watch it and see what is going on the typical When we go back and look at devops The typical Kanban board that we see out there or the typical board even regardless of Kanban that we see out There is at the theme level teams either have a task board the usual scrum style or a Kanban based storyboard with their story backlog here or the print backlog here Development sometimes just in progress and accepted development then maybe testing Then accepted as the screen done or potentially shipable product and that's about it What's important for devops is to go beyond that and look at the end-to-end flow Okay So here we see that small team and their activities within a bigger context the context of the either a bigger program or that single team But working within a bigger value stream the value stream that also includes the work that happened before the team getting work ready to done ready to the sprint backlog and Maybe stop that happens afterwards okay because what's important and the first step the typically organizations take when they go beyond their Local team agile to devops based end-to-end flow is to look wider Look wider not just upstream to what happens in the product owner world from portfolio until Stuff is ready for the team But also downstream between the point that stuff is done Potentially shipable product to the point that it's actually getting ready to be delivered Delivered and deployed the point where we learn whether it's actually useful so the definition of Done in our board the stuff we try to focus on finishing towards changes between The typical agile development view where Dan means working tested software or potentially shipable product To Dan being works well and useful in production. Okay, that's the real agile or devops you Okay, you can notice I'm mixing between real agile and devops because the way I see it and it might be controversial They're not that different Devops is about enabling real agility real business agility end-to-end it's called devops because it Basically crosses this Chasm that was after the team The team so far didn't care so much about what after that happened after this point But now we're talking about caring about what happens end-to-end not just in dev But also in operations and also in Production we'll talk about it. Okay So the first thing is looking at it Looking at it and managing the flow end-to-end doesn't mean changing the team structure. I didn't talk about changing teams I'm just talking about being aware of Where is the work is the work here? How much work is waiting to be pulled in by? Operations how much work is currently in operations and you can see here that while I'm showing this board It's not really a DevOps operation that happens here You can see the difference. This is agile While looking at the end-to-end starting to think towards DevOps was not necessarily doing anything about it The aim is to go from here to here We're here what we see is that basically work is flowing end-to-end in small pieces Through development through operations all the way to production You can see the difference. These are bigger batches. These are smaller batches. There are waiting points There are big releases here. It's still agile. This is dev off And the idea here is to start being aware of what's going on here That is stopping you from being here Whether those are constraints bottlenecks Policies that are creating big batches organizational structures This is the first step visualizing what's going on and starting to be aware of it and starting what are you doing up here? I thought you were done The next step Since we remember Lucy is to start to prefer pull over push mode. Okay, that's the second step in Kanban Don't define everything up front. Don't push everything into Operations once things are finished, but start to work in the mode where people pull stuff into their Activity when they are ready for it And they should pull one by one ideally but at the beginning they should pull At the mode that they are able to do so over time. We might improve that Once you do that a lot of organizations stop here actually Which is a bit sad Because the real power of Kanban is yet to be seen The a major part of the real power is limiting your work in process Okay Limiting your work in process basically means that you will not pull everything You'll not push everything you will have some limits You will have to work under a diet which tells you at some point you cannot pull more stuff At some point where you see that some work is accumulating in the operations Use you will not be able to start developing more stuff You'll need to go there and help them. You'll need to start to care about them. This is hard This is very hard very very hard Kanban is about facing this pain and doing something about it Okay, and we'll get back to that when we go back to continuous improvements When we talk about limiting work in progress, it's both limiting the amount of things that are in your cues that are in your Activities as well as their size. You should not feel pulled in or work on stuff that is too big all of this ties in Also into the work of Reinertson on principles of product development flow. I will not go into that Today, but if you're interested go and read this book or this article you have the reference in the in the slides and That was focus on end to end flow basically to start to think of IT as a design factory and apply the flow principles Visualize the end to end work and flow using Kanban boards break the waterfall work in smaller batches Manage and improve the flow stop starting start finishing and ideally limit your work in process. Okay, that is the key starting point for Kanban The second step is amplify feedback loops. So what does that mean? Basically what we want is for at least for Each of the things that we're working for to tie the loop of we're doing it We want to learn whether it was a good idea as fast as possible. How do we do that? The first step is to slice work into valuable integrative Testable chunks that can really flow to feedback fast. So again, no big things Walk in small pieces The second thing is not even to wait until we deliver to learn whether it's good Not even wait until it's in operations to learn whether it's it's actually operatable whether it we can deploy it so Maybe you're familiar with Acceptance test ribbon development or for sure you are familiar with acceptance criteria that you define when you talk about the stories But how about talking about how will we deploy and operate this? Story or this feature before we start to develop it. How about including that as part of your definition of ready? I call it a pops driven development, but I don't know the name is Is not kept on so far, but maybe someday Maybe the free amigos that should talk about the acceptance criteria or the acceptance that should be Should be including some other people, okay? Operations people, but then there was the question who from operations should be there the net ops person the sec ops security operations person The DB ops person all of them all of the time. There's some complexity there. There should be something that That helps us to decide who to involve when It's not it's not trivial how to Make this happen Another point of amplifying feedback is to be aware that our psychology as engineers as developers is such that when the Feedback loop is faster. We deliver more quality Not just because it's easier to fix things when we get the feedback faster But because we also care more about things When we know that we'll get the feedback faster when we know that we'll know Next week or ideally tomorrow whether it's working or not Whether it's operatable or not. There's better chances that we'll do that work Then if it's going to happen in months, and I don't know if I'm even going to be on that team or project And I don't know who will be the people that were that are going to operate it It's different than if it's people that I know and it's going to be in a short period and Now we get to the people aspect so far. We didn't have to break the organization We just walked on flow and to end on breaking the work into smaller pieces And that can actually work that can actually be a good start, but there's a glass ceiling for that at some point You actually need to go beyond what Agile is doing which is basically to Break down the silos between development testing and the product organization at least some parts of the product organization And you have to do something about these other silos that you asked about The first thing that you can do is that you can create and the projector is not helping us here but you can create these sort of virtual teams Well, there's some association between the people that are working on a certain service or application in development and test and Some relevant people in operations in deployment. They don't have to be on the same HR team They're just need to be some association ideally a stable persistent association over time But even if not It's better to have a per feature or per small project Association than nothing Ideally, of course at some point you will realize that these silos are hurting you and consider breaking them all together by the way a minimum starting point for this Journey or something important to take into account is That these teams should be feature teams other than component How many of you are working with feature teams already? How many of working with component teams? Teams where it's for example the server people all together and the client people all together How many of you are working with team like that? couple So before you go to DevOps think about the feature team versus component team Situation so this was amplify feedback loops Use smaller integrative valuable slices of work bring the operations feedback upfront ODD Bring all of the relevant people to work together all the way rather just by association for a single project a stable association or by changing the organizational structure to support it and Last but not least increase the frequency of delivery in order that you get the feedback from whole production actually faster the third step the third way towards Real agility and DevOps is to continuously improve. What do we mean by that? first of all the basics Continue to do or start to do a cadence of retrospectives by the way if you're doing Kanban You should still do retrospectives on a cadence. It's a myth Then you don't have cadence And retrospectives in Kanban you should do them and you should probably do them every couple of weeks on a fixed cadence If you want some tips, this is a presentation that we use to to help people with that I think every two weeks or every week is a good start, but we also see teams that hold different kinds of retrospectives more frequently and a Catch all retrospective every couple of weeks Also start to look at all of the metrics that are relevant once you start to look at end to end flow If lead time is interesting start to measure your lead time or your cycle time Start to look at the exception start to look at cumulative flow diagrams start to learn what is going on You will both be able to predict better What your delivery is going to look like as well it provides you some Ideas for how to improve Continue the diet. It's not enough just to stop starting start finishing. It's not even enough to put some whip limit You should create the situation where you are walking stable at the certain whip limit and then start a loop of Basically reducing the whip limit facing the pain The it will be painful every time you do it Finding what is making causing the most pain dealing with it Not a full solution, but something that makes it makes like variable at that or sustainable at that whip limit And then go through another cycle of lower lower with me limits And as you do that your cycle times or lead times will improve your process will improve You'll be better position to compete on the basis of speed another way to look at it a Very important although more complex way to look at it is to look at the balance or the combination of the different costs that go into your design factory Basically, what's going on is that typically what we're looking at is Transaction costs or overheads examples of that are the cost to deploy to production the cost to run regression testing The cost to run a build all of those things Historically caused us to go for big batch sizes to go for efficiency But there is a problem when we go towards this direction the problem is that we have holding costs or in other times Delay costs or cost of delay What are those costs for example if we have a feature that we want in production if it's sitting waiting Until this truck is full then we're losing money on it If we have a feature that we're not sure about What exactly we should do there if we don't get to production fast we cannot learn whether our Ideas are good. We have to make decisions and continue to develop based on our bets And if we continue to live to build it based on bets, there is a good chance that we're wrong So if we need to wait until back, there's a big cost to it once we understand that there is uncertainty and we don't know Immediately we understand that there is a big cost to it So our traditional processes are actually more expensive to run Then smaller batch size Processes even if we don't do any automation any DevOps tools any continuous deployment Stuff even if we don't do that just use our current processes typically it makes more sense to run with smaller trucks Woman effectiveness and total cost point of view But now there's the next step the next step is to say, you know what this is reasonable But there's actually even a better way something that makes even more economic sense Enables us to compete even better We want to be here, but in order to be here. We need to do something. We need to reduce the costs We need to reduce the cost of the overheads Or the transaction cost we need to invest in some things those things are for example in this case Some DevOps tools that's the reason actually that people when they talk about DevOps They only talk about those things those are the tools that you need in order to enable you to run faster But running faster is a bigger thing Is an end-to-end system thing tools are just part of it an important part, but just part of it and This thinking actually Seeing all of this picture can actually enable you to build an ROI model for why to use those tools And where which tools to use earlier and which tools to put in later on Which tools are required to make this reduction in the transaction overhead or this reduction which tools are required For the biggest batch size problem that you have right now and which tools are actually required for something That's already okay. It's not the constraint in your system right now. Most of you will probably be in this area This is what we call the horses in the what they call the horses in the devos fold The unicorns are doing continuous delivery and are here, but you shouldn't necessarily be there continuous delivery Is synonymous with devops in some circles, but it shouldn't be It's one way of doing devops probably a way that's not that relevant for most of the IT and product development organizations at least in the next couple of years So continuous improvement was to continue to do retrospectives to sense and respond to flow and feedback problems measure flow cycle times aim to reduce the average and the variability Reduce your walking process continue the diet Accelerate the delivery loop to surface the next opportunities for improvement and Collaborate with everyone throughout the value stream whether it's in dev and ops everyone together To study what's going on in your system and design and run experiment that you deem at improving your flow at some point Or most of the time maybe the improvement that you do should be gradual or evolutionary at some points You might realize that you need something bigger for example an organizational change towards feature teams Or to break the silo between dev and ops It's probably there a mix between those revolutionary and evolutionary types of improvements that make sense In reality, so those were the freeways Towards dev ops If you want to read more about those freeways about dev ops in general a highly recommended book actually a must read book He's the Phoenix project by Jean Kim Kevin Bear if you want even more reading Around the subject and here are a couple of more books the continuous delivery book in startup principles of product development flow Kanban My book Holy Land Kanban where there's actually a discount for you guys in the conference And if books are not enough We're always there we have We are based in Israel, but we have an office activity in India in Pune Prasad over there next to areas in the back Is our guide there? And that's all and If you want we have nice calendars that Prasad created with some lean Kanban devops ideas For the year you can come here and take your calendar. I don't know how many they are so Rush if you want And that's about it Three minutes past but let's take one or two questions and later on if you want Good question So let me make it more concrete. Let's say your teams are doing scrum The question was if you want to do devops, we recommend using a scrum ban or Kanban, right? So I would say that regardless of what you use at the team level whether it is Scrum or Kanban or scrum ban. I would probably add Kanban to look at the end-to-end level So that's a mix of scrum and Kanban. I personally believe That objective I believe that scrum ban is a good idea for any team regardless of whether They're trying to go towards devops or not the thinking about flow is something that is good for scrum teams As well and have with a lot of the scrum bots. I believe that's actually better in most cases than pure Kanban in the team level but looking at the end-to-end beyond the teams Kanban is the thing that goes best with devops Seeing in the field last question Yeah, I believe that an important starting point for having Effective devops teams is to work with feature teams Because if you work with a couple of component teams And each one of them think about how to bring to operations their own component then who thinks about integration about the integration of the operational stuff so I Think it's probably going to work much better with feature teams Which makes sense because agile in general works much better with It's not the devops cannot work with component teams It's not the devops cannot work with devops teams Okay with teams end-to-end you can start with visualizing and being being aware of the flow and just Making sure that you know what is going on and you are aware of your bottlenecks and bed sizes and start to do things about it and at least start to Bring to the managers of the different Functions to work on that end-to-end flow and improve it We've seen several large customers very large customers who started their journey towards devops that way But the role of doing that Kanban step is again to make sure you're aware of your last ceiling Make sure you're aware of your problem and create the energy and they and the confidence That changing the structure or at least the work structure rather than The HR structure to be more oriented around the end-to-end value frame or in other terms Okay Okay, so thank you everyone. I'll be outside if you have more questions