Hi. Oh thank you for having me um I'm. Very excited. I brought my daughter along to New York and it's my first time here so we done a lot of sightseeing, was excellent, I'm totally. Jealous jealous, of you people living here it's so cool well. That's another enough. Of this small talk because I have only 30 minutes and I wasn't, able to make any choices so, I have to rush to all my slides so. Just hang, in there or something I don't know I'm, going to talk to you about the continuous culture, and. Why. Is the, continuous culture for, me such an exciting subject, well, this. Are. Some steps from the state of the DevOps report, which is run by puppet, labs and. They have run a research, amongst. 2100. Companies, and. They compared, large projects. To small projects, in the rate of success and the, rate of success is only 10% for. Large projects, and another. 52%. Is. Challenged, so they don't there's another. 38%. That never goes into production I don't. Know if we recognize it I have worked on a lot of projects, that have never gone, into production have. You also, so. That's terrible, it's it's a draining, process to work on something that's never going to add, any value to your project, right to your company and. Small small projects, have such, a better success rate it has, a 74. Percent, success. Rate which. Is crazy, if you compare it to the 10% and here's, another one, there. Are a lot of unused, features in our. Systems, this, is also from the same report, you, should definitely read into it they. Say in large projects, there is a 64, percent of features that's not used that's, 2/3, of your code that's, not used and. While it's sitting there there, are some people who think that unused. Code doesn't, cost any money that. Isn't true right, it costs, so, much money you get your. Only priority should, be eliminating. Those things I don't, know this is right. This. Is my oh okay. Great I. Love. Other female speakers they have the same issues as I have thank, you. Okay. And. In, small, deliveries, there's only a 14%. Of. Features that's not used and this, is not because those people are better at making assumptions, they. Screw up just as, much as people working on the large projects only. They learn faster. Which, ones to eliminate and they. Actually do that they eliminate, the features. There, were experiments, that just plain filled, and that's. The most valuable thing you can do the. Cheapest code to maintain is code that isn't there. So. Why. Are, we so, bad. At making assumptions. And, I would like to introduce you to the kinetic model is anyone familiar with the kinetic model already. Okay. That's, very little heads this, is kind of, the. Thing I think of every day for me it's very important. The, kinetic model tells you something about complexity. And. It. Says there's a relation, between cause, and effect and, in. The simple quadrant, over here there. There, are the easy problems, you have a cause and you have an effect and you can actually, see. The cause, causing. The effect so. Like I, spilled, some milk and there's a stain on my clothes that's. Easy right you can just see. It and you can observe it and you can act properly, upon it so, you learn things as a kid already a lot, of problems are in a simple domain then, there's the complicated. Quadrant, where, you have some cause and some effects and there's, a complex, relation, between them, so. You have a lot of parameters which are all kind.
Of Affecting. The way the effect, will be, observable. And to. Be able to work in this quadrant you have to be an expert you, have to have people. Who you can call. Analysts we know those right and they. Can write, 1200. Pages reports. And actually. At the end of the report it will, state the truth and, we. Think that, software development, is in that quadrant, it. Isn't, and it's. The worst mistake, you can make software. Development, is in the complex quadrant, at least maybe. In the chaotic and in a complex quadrant, there is a cause and there is an effect but, we don't understand, the relationship between it, so. We do know they have some kind of relationship but, we we are at the place where we can understand, it and the. Way to, act when you are in that quadrant is to, experiment, is to probe so. You have to find your way in learning, what the relation is this, is why a be testing, for instance is so successful, because it's probing, it's learning about things we, are just, bad at making assumptions. So. The rest of the talk I will introduce you to how to how. To nurture, experimental. Culture because that's a hard thing to do and it's not just software development. So. This. Is what it's about, to. Improve is to change and being, perfect is to change often so, all these little changes together that. Will make you a high performer, and if you compare high-performing, companies with, lower performing, companies they, have a 200x, time more, frequent, deployments I, think, companies like Google are in, that quadrant right and. They have more. Than 2000 X times shorter, lead cycle times which is insane right and they. Have, this increased. Speed at an increased, quality level so. They, do make lesser. Errors, and they, do, recover. Faster, from failures. So. How, do we get there how do we deliver our incremental change it's, an eight lessons so, that's, what I said well actually normally, it's ten so I've tried to eliminate some, and I managed to eliminate two so I don't, know it's not enough, okay. So first, be able to safely and sustainably, deliver. Software, and. Obviously this is continuous, delivery who's doing continuous delivery already, oh that's. Super I think. It's kind of fun and beyond the hype cycle and it's moving its way up to, the slope of maturity, or something, because, a lot of more people are doing it then when I asked this two years ago I'm not going to go into continuous, delivery I think there. Has been a lot of said a lot of things about this, said. The. One thing I'd want to stipulate is it's, about delivering, incremental. Change so. You can't have an experimental, approach if, you're not able to deliver incremental. Change if your, deployments. Cause a headache and if, you if it causes overtime, and if it causes. Everybody to panic then, you're, not ready to go there but, this is only a baby step this. Is the first thing you do and then comes the rest. So. What is continuous, actually. Naming. Seems, to be still a problem in IT somehow. Maybe we'll find a way to solve this but, continuous, would actually say all, the, time but. It isn't all the time of course so, what. Is continuous, if you look at many enterprises, they are really, somewhere, around every. Hundred. Days and, some companies are able to shift towards. A day a daily release, with. The companies I worked with we were able to make this shift we. Have a multiple day release. Multiple. Releases, per day that's kind, of different um at. This moment and, it does seem to get. Exponentially. Complex, to. Accelerate. More so, I have deep respect for companies, like Etsy who are way over there, because.
It's Extremely, complex to deliver that many times, so. Anyone knows what's the deployment, record, for. Number, of deployments each day take. A guess. 10,000. Oh wow. This is the first time somebody, made a number that's actually bigger than the actual number so. Congrats. That's good it's seven, thousand, four hundred and forty eight that's once every 11 point two seconds so, you have to do really a lot to be able to to, run this fast because, at. The companies I work with the test sets will. Already, take you about two hours. As they are so big so. To be able to be able to deliver every 11, seconds, that's. You, have to do, a lot of work over there. But. Still it's worth nothing, if you're, not able to actually. Define. Something that is of value which. Is small. So. If you have a product which is this big and you can just deliver it in little particles, but. You won't release it actually, to users until, you have the, full stack. Of features, developed. Then. It's worth noting, that you deliver it it incrementally, right. It's. Only worth something if, you actually start using it and, this. Is where product development comes in so you're only a small your MVP and this EDL is your roadmap. And, this, is one of what we're facing in companies we have kind, of products, development, roadmaps. Which are lost in a year when, I started in November at in the intinerary at company, they, had this roadmap they already, told. Users, they were getting, new features, in eight, months, so. That's, terrible. This, was eight months ago but it was actually a pronouncement. Like okay we're going to deliver this at the end of the year and. Your. Are, neglecting. That you are learning on your way so, every lesson you learn is worthless because you can't adjust your plans you already told all your users what you're going to do so, that's terrible stop doing that and also, stop read sprints because. This is draining energy from the team you, make estimates, and time after time sprint, after sprint you, end up with this end pattern, where, you somehow, have, some features left and no time left so, why. Bother, if you. Just focus, on making things as small, as possible, and you. Put your KPIs. On, the. Number of things you are able to push to production then. That's an incentive for a team to make things as small, as they can and that's. The behavior we want because. Small means less risk with your soda so. You. Can just stop estimating, and say okay you get rewarded, on the number of issues you. Are able to put into production. And then, the team starts, asking do you mean that if we break this one in three little particles, we get three points which. Is three times more than if we deliver it as one and, we say yes so, they feel like it's kind of a trick question but, isn't this, is the point, so. That's, great this is just humble, he's. Used, to be from Thoth works and. He says if you have four, measurements to, measure any team. Then. You should use these ones you, should look for a lead time for changes, and leave release frequency.
Which, Is about tempo, and you. Should, look at time to restore service and change film rate which is about quality, and better. Teams do better at both they. Increase speed Wow. Increase. In quality and that's. The thing to reach that's, cool so. How do we do it we have a simple quadrant, and. We say okay. Whenever, someone, has an idea we put it in this quadrant and if. Something, is a high effort and it has a low value then we just say no that's. Obvious, if something, has a high value and it is a low effort we simply say yes that's the quick win and then. We have the other two quadrants, which, are, there's. A low effort and. The low value that's, the maybe so. We try to decompose, it, making. The effort even, lower until. The point where it's worth for a while and we. Have the high value high effort and we do the same thing we try to decompose it so. Eliminate. All things that are not really affecting value but, are affecting. The amount of effort and then. We have these weekly meetings where. Where there's a portfolio, board and. It's software development together with product. Development and we, say ok anyone can put in an idea and if, the idea is. Discussed, we say ok you have to break it down into little particles, then it goes to research. Then. We have maybe, so. If something is an idea but we don't have the priority for it we say ok don't talk about it we minimize, the amount of effort going. Into code we are not building, because. Code we are not building is not valuable and we. Put it into a parking lot and, we say well maybe just don't talk about it. And then, we have yes and yes but later and they go to the backlog and they go to. The parking lot for two months, and. This is the way to very. Effectively. Only. Work on the things we are building and talk about the things we are building because this meeting takes us one hour and that's, product, development for us. Um. Well. Then, remember you're not the only one whose process, is changing, so. That's lesson number three. You. Have to stand your ground auditing, and compliance are, used to doing major, code reviews, and then, you go there and you say okay I want, to deliver every. Hour, and, they, say okay how am I going to do the code review how am I going to have, the huge documentation. I always require. Sit. Down with them have a have a good talk they are very willing to come along with you if you do this take. Them seriously. And. We, had a nice talk and they said okay if you do everything in version control if, you, have test change approvals, and. For spare reviews so you want to make sure that there's always a second, pair of eyes watching code, that goes into production, if. You have the. Certainty that only green goes, to production so if your test is red you, don't go to production. Approvals. In your workflow and if you have conformity, by design then, we're fine we don't have to do any checks anymore, so. That's great there. Was a great outcome for us because Jenkins. Does most of these, things for us right so we didn't have to bother. Also. Continuing security, is. A major change, for your company because, also the security guys did a, penetration. Test every quarter or something and. We had to change things around because. Security is a big issue it can actually. Make. Your company. Non-existent. Sorry I don't know Dan a better word default. Or something and. What. We did is we said okay every month we're going to have a hacking session we educated, everybody how to hack our systems and.
We Made sure we, had security. Issues every month because. If it hurts do it more often and this. Was great, for our own, so, we, learned, about security. Flaws every, month now because, we were trying to hack ourselves, also we said okay anything that can be automated, should, be integrated, in our pipelines it's crazy to have known vulnerabilities. On websites and to have script kiddies like, this one over here and you, can just download, scripts. And you can actually say what's the domain you want to attack and say launch and then it goes that's, all you have to do and it's crazy if your system, is not reboost against this so. Make sure you have your automated scanners in your pipelines, to make sure, that you're not vulnerable for, these easy, kind, of attacks then. There's there's enough left and make, sure it's not about paper so, paper, lists or something kind. Of a metaphor for server lists because. Developers, don't like paper so. Make sure it's about code then it's fun and then they actually start doing it voluntarily that's, a good place to be and, make sure you address some of the business and the pattern so they were used to having fallback. Plans many websites insisting, education. For users user documentation, and communication about releases, you, should stop doing those because you can do those every 11 seconds so, try, to change, to. Something, like cannery releasing, where you have low impact when you make a mistake, co-creation. On tests make, sure they are already on board when, you define your tests have walkthroughs. Because they are very. Nice. Integrated. Within your system. Have. Embedded user insistence, and chat bots and look. At release notes and how you can integrate them into your delivery, pipeline, so, right now our developers, are writing the release notes which sounds, horribly scary, but they are learning and. Sometimes, grammars, shouldn't, be an issue like this I think so. Yes this is possible. Okay. Number four reinvent. HR management roles and procedures, for autonomy, these. Roles, are blocking, autonomy, and. Management. Doesn't skill so. You. Have to do things very differently this is one of our directors and at. A certain point he said okay there are all these things changing. And everybody's doing work which, was actually the point. Delegating, and he, said I can't, control what's happening so. He said I'm coming out of my room because he had his own office and he, said I'm going to sit in the middle of all the teams and. Actually. Try to follow what they're doing so, that was so cool, afterwards. He just let go he said okay I have to do things differently I have to set out a vision and, I. Have to take people along in this vision but, I don't actually have to look over their shoulder to see how they are doing their job because, actually, they can do it better than I did so that was a good moment for us and. Not a good moment this was just for last week and it's a big celebration for me this isn't a photo of a standard, meeting of our management team so. We, have management team of eight and they. Were used. To having these, weekly. Meetings of four hours and, I. Was, fighting for two years like okay we have to have a daily stand-up and now, it's a transparent, process where. Everybody. Can watch what the management team is talking about and what the direction is they are going and. They. Can look at the boards and they can see what's happening so they can actually see the managers do, do work, which. Was already set, that's. Great that's, a great benefit, and the. Most funny thing was management wasn't visible ever because, they were always in meetings and now they come to the working space every, day to have a daily standup and people were like the. First time they did this and everybody, made pictures so it was really funny we were in the room and everybody was crowded, around it like what are they doing so, I, had to actually explain, to the management what a daily standup is which, is bad if you were a software development company. Okay. And. We have this thing we call the Blue Room where, we say okay everything, that's a vision.
Everything, That's the path we are going we're putting it up on the walls we have to talk to people to tell them where they are going they come guess where we're going we have to tell them and tell them again and make it visible if you don't do this economy's. Worth nothing, you're just jealous, so. Try, to put, a lot of effort in it and this. Is also very nice google, it it's a manifesto, for agile HR, development, it, says ok treat. Your people totally. Different, because if you're not trusting, them and there's been enough, about it if, you're not being transparent, then, you can't reach anything then. It's really just about being starless and then. You say okay I tried to get it delegate, and they, prove me wrong because they messed up yeah, well you did that yourself if you don't treat them like you should. So. People actually. Respect. Other things the managers think this. Is a research done and. They said okay what. Do managers think, that is important, for workers and it's totally different than what they actually found important. If you ask the employees so, it's about autonomy, respects, responsibility. And it's not about career. Ladders or supervision, or clear rules so. Try, to keep this in mind with, everything you do are you in the black side or are you in the white side the, only thing in the middle is a decent salary. We. Also try to move. Feedback totally, around because. We were used, to having these performance, reviews where. We said okay. You're. Doing a super job and the. Rest of the hour was about how he could improve so, I, was, kind of not valid right so. And. Fear, induces. People to hide induces. People to actually. Prevent. Those things from happening so a lot of energy. Goes into not, doing, things, and that's. What you want to change right you want to have compliments, because they induce, endorphins. And endorphins. Are, good it's fact like getting, high for free. So. Who. Wouldn't want it, so. We, implemented the there. Are different. Systems but you can look into trick you and in praise, and. They, are about feedback fun you had just have feedback on your mobile and you can ask someone how did you think my presentation, went and you get instant feedback not. Delayed and, it's very easy to use you can send compliments, you can have a lot of those and the fiends working for you and people start focusing on strings and they want to have more of those compliments, so they start, seeking more of the right behavior, which is great that's, what you want. Also teams need to change in collaboration, there's, a lot of discussion, about how. To call teams because you have deaf ops and there, are some people who say it's be up staff because, ops is more important, or something and then, about security, they said its SEC, def SEC the up SEC because. Security. Comes, at. The start and in the middle and at the ends or something, there, are actually people reading, about this and. If, you ask the founder of the word DevOps he said okay I just needed the shorter words then agile system administration. Because there was too long there was no grand plan between behind, DevOps it's about collaboration, so. How can we have endless discussions, about the priority. Of the. Of the the the words, because. That's not about collaboration. That's the, opposite don't, waste your energy and. Learn to learn we. Totally change this around we have JIRA boards for learning events and. We said everything you want to do every, conference you want to go to every, training you want to follow every. App you want to develop. In a different, language than you're used to just put it on the board and we, make very visible, that we are learning, and. It's also work you are doing so. If. You try to hide it you won't really have time to work on anything so, we try to make it visible, and, we have Academy, started. To make sure our learning parts we have workshops. With our firm. Developers, for developers we. Have hackathons, and we go obviously, to conferences, but you're already in the place it's very good well. Designed for fast feedback and evolution, so. The, micro serves architecture, really helps, us to be able to have the experimental, approach, we. Have a lot of Micra services of around 400, or something and. If, something. Wasn't well. If. Our assumptions, were wrong we. Just killed, a micro service, and, put. A new one up with the right assumptions and it's, very critical that you have this otherwise, they have long, discussions.
Making. It the right design there's, a lot of fear putting, wrong, code into production but, you obviously will, put wrong code into production so accept, it and make sure it's it's not a bad thing to do make, sure you can eliminate it very quickly. Also. The test pyramid, we, try to reinvent it because, it was about how fast. Your tests were everybody, we're with the normal. Test pyramid or is it something new, it. Says okay there are very fast running tests and you have to have a lot of them and there, are very slow running tests and you have to have very little of them because. Your tests will be running too long and. In. My opinion you should try, to turn, this around you should have some, tests sooner in pipeline, because early, said the feedback is cheaper and further. Up in, your pipeline there's, a lot of code coming together and, your pipeline, is blocking, the other code go into production so, you have to have early feedback, on your code and how, do you do it you can say ok there. Are some smoke tests with our which would Trevon business, continuity so, I'm going to do those very early, there. Is some code that's under, development so the, chance that something's breaking over there is much bigger than code that was just sitting there right so you, can have those tests, put forward, and. You have early feedback, and there. There are some code. Parts. Where you know they're just flaky, where, you know, that's. The kind of code you know you don't want to touch and. That. Code can, also be early tested because it breaks a lot right so just, be smart about it and it's, not about kind of test but about the risk its. Addressing. And. There are also there's a big layer of too expensive tests, to run a, lot is in the UI but there are also some, other tests are just too expensive and. Try to move them to monitoring, don't, try to prevent, every breaking change, make. Sure you're, able to react quickly and if it's code, it's that's, never broken before then, maybe it's just just. Just fine, to have it addressed in production. Through, monitoring. Well, then this one branching, is your new mother-in-law sometimes, you have to go there but you want to minimize it. Very. Important, lesson also for the code and. How. Is, that branching, obviously, is not integrating, so. You're, extending. The moment where, you're learning that your code is breaking, things, and, that's the thing we tried, to quit doing so, don't branch. And as, I said sometimes you have to go there if you have a big change in lips or something well. Obviously, you. Don't want to. Bother. The rest of the team by not being able to develop so that's, a fine moment to branch but. I kind, of developed this pyramid. Where it says okay it's right a lot to. Work on collaboration, with your clients, if. You have co-creation, pre, acceptance, if you actually talk to them that, will save you a lot of work in your testing pipelines, because they can actually tell you things they can talk and. Then, you can try to had not have a front end path so, if you have your back end you can just go to production and as long as nobody, can reach that part of the code you can just put it in production there's no problem. Even. If it's breaking there's no problem as long as you can't reach the code so, be, smart about your release strategy then. We have feature Flags, feature. Flex are you. Have to add codes to make sure you have a feature flag so you don't want to do this all the time because it kind of get messy in your code and then lastly, if branching, if there if there's no other if the other tree won't work then you go to branching, and. We develop this release, strategy where, we said okay we have a lot of pipeline, before this but it's not the point we have acceptance, where. The team takes you look manually, is this really well wanted then, we have rehearsal, and rehearsal, is about obtaining a sustainable, pace because.
Otherwise Everybody's, putting things into production we can't. Well. It's not a sustainable pace for us because we don't have any control and sometimes we want to have a, launch, or something and we don't have to choice over here so. Features. Are isolated, here for a day before they go into production then, we have a cannery production, environment, we're, looking into scaling, up with narcs cannery, production. Environment but it helps us to reduce, the risk so that's, about impact, reduction if. You have a cannery production, environment, then, the risk if you're breaking things is much lesser because it's only going to in, our case 1% of our clients and lastly. We have feature flags which is about shipping, delay so. It, helps us if, there is a bunch of features and we want have this big launch or something then, the only way to obtain this in the micro-service landscape is by feature flagging, it and then putting over the Flex that's the way to go into production then. Well. Lesson. Number eight customers, actually don't want continuous, delivery that's. Very important, because, somehow, the, development team tends to talk a lot about it because it's a very interesting topic for us right but, customers, don't want it and, that's that's quite logical, because it's about broke interest this is a measurement, on our code base which. Is from one and a half year ago so things got worse and, we have 10 million lines of COBOL almost. And we. Have 3 million lines of PHP I don't know which one is scarier. We. Can take a vote on it later but, I mean it's bad and. So. We are measuring bucks, per hour and and, when, you're doing that you're, not in a good place right I mean it would be nice to measure bucks per month or something, so. You, have to take them along on the journey or traveling into getting better code. So first improved then accelerate, puh. And not push make all these cool features and get. To the point where the customers say ok I don't want to delay release, anymore can, you just give it because it's so interesting and. That's nice points. To be it and, explain your goal tell, them where you are going although. It's not valuable. To them you can explain and you can gain a lot by explaining. So. Wrapping, it all up, continuous. Delivery makes, you makes. It enables, to have rapid prototyping, at your product development is. Needed for doing small experiments, and seeking value to assert. Your assumptions, you. Have to have a learning organization, to be able to learn actually, from your experiments. Then you need a GL HR to support people to learn, agility. And to improve on. Their competitor, capabilities. You have to have autonomous. Teams to. Empire, up manpower teams to decide by themselves, and to not have a, manager, who has to oversee, everything, and you have to have micro services, to enable an evolutionary, architecture, and then, there's, the last lesson number 9 it be ready for a surprise. Because, the line of success is not a straight line up it will get you down it will sometimes, drain. All your energy but just get up and hang in there because it's worth your while so, that's me thank you. You.
2018-05-25