 Welcome to this session. My name is Yuta Eckstein and I'm based in Germany and well I'm the track chair as you heard in the morning for today's conference and I work as an agile coach consultant have written several books today this talk is about How I think that CD should actually not only stand for continuous delivery But also for cultural differences and let me start with a story a real one so A few years ago. I think it's about five years ago GM had a problem. It was this Chevy Silverado, I think is the name of it When when running idle it ran on eight cylinders instead of two so that led to overheating and the eventuality and some cars did the catch of fire and Because of that GM had to recall 370,000 of those cars in order to fix that so they had to go back into the garage into the workshop and being fixed The repair actually was a software update Okay now same year different company Tesla So there the problem was that the adapter when charging Had the problem also of overheating and some of the cars caught fire. So kind of a similar problem, but different now But Tesla did was well, I heard this already somewhere there Providing a software update over the buyer OTA and Ellen must got really really upset when the media was telling everywhere like oh Tesla had to recall 29,000 of their model s and Ellen must had well no single car had to go into a garage or a workshop for that fix Because the update was done over the air Right, so they just checked is the car at the moment driving or charging and if not we can safely do the update I'm providing these stories because what they tell us is on the one hand that software is really Making a huge difference to the products that are out there right now And it also means if we do continuous delivery It really means we have to look at this from different angles There are different aspects we have to consider for continuous delivery And the aspects that I'm seeing there are and that's my agenda on one hand the technical Then the organizational and the market aspect Let's go to the technical one So for technical I think most of the stuff that we talk about here is often about like tools and technologies It's stuff like also like what chess talked about it touches sometimes also different aspects But it's really more about okay, which technology can we use what what is helping us to really be? Enable to do continuous delivery and it could start with automatic testing or Pair programming like the great workshop that's in parallel to this session which I miss or Using Kaiba net is or whatever However, what I also see with all those tools and technology that are used right now that sometimes continuous delivery is actually more like a shipping continuously patches and It's not really delivering something real and also here I want to give you an example So this is one of my passions actually basketball. I'm Really tiny in a small way sponsoring a team in Germany as well We had this story. I think it was also a few years ago And not too many maybe three years ago where a team in the second league of Germany had to win like their last game in order to stay in the second league League if they lose They would have gone relegated and downgraded to the third league, right? Now during that game what happened was that one of the servers started a Windows update and For whatever reason and I don't understand but anyway, they couldn't stop it and on that On that server they had like almost anything connected to that So like the timer or very important as well the the monitor so the display where you see Who is leading and who is trailing and who has how many fouls and timeouts and all of that, right? And what I didn't know and that might be different from country to country but what I didn't know until that time that if Game comes to a halt for longer than 15 minutes Then automatically the guest will win And it will win by 20 oh, so 20 is not really a lot of points in basketball But still winning is winning and especially if it's about relegation or not, then it's a big thing. So That that was a big thing It was like Windows update causing that team to lose and being relegated Actually, what's also fun. So this went through the media media What's not really going through the media was later on that they rolled it back and that was to me at least funny as well They said we are rolling it back because a Windows update is kind of an act of Nature so out of control or in legal speak. It's a act of God Okay, now we know where we are with Microsoft and Windows and so on so that was kind of funny So it the end was good for that team, which wasn't my teeth by the way because of course we are playing firstly, right? Good so my point here is one problem with continuous delivery is often that that we Just think everyone is happy by having a new Feature software patch something however what we really require is to Really allow the customer to pick and choose to say like I want that feature I don't want that feature and I wanted now I wanted later or whenever and This is actually something that changes a lot in the way. We well work with with our software, but also in the way we work with the customers and It also requires us to really understand Multiversioning and multiversioning. I don't mean like the real technical side I think version management we have all kind of figured out how this works But more in a way that if the customer says oh, I don't want to use that feature But then several months later saying I want to have that other feature But we thought as software providers that the one feature built up on the other So that we kind of think well, there's no way of using this without that So we really have to provide more possibilities and configurations in order to really allow That the client for himself can pick and choose on what he she wants really and needs So that's a really different request Technical wise and how I look at this is really Thinking of the client being really mature So not that we define stuff, right? Okay looking at Organizational aspect what I mean with that first of all is looking at the process which Brings me to a question that I heard in marriage talk this morning here I'm not sure who was here, but there was a question at the end where somebody said well, how does continuous delivery really? fit into the cadence of the process so Because we have here at the end this shipping of an increment, right? Similarly actually with something like that. Oh, that's XP. It doesn't look as clean as crumb But still And here we are there So how does continuous delivery fit there if we have that cadence and I went back to like in both cases Looking at these pieces only look for example again in the scrum guide and the white book from came back and None of them is saying that you are only allowed to deliver at the end of an iteration or sprint It doesn't say so it only says like for example scrum says in the review retrospect if you're looking at what you have been able to Complete during the sprint, but he doesn't say well you can only ship it at that point You you are absolutely welcome to ship it whenever it's done So the process is definitely not in the way so sometimes we think so but it's not now Something else about the organizational aspect is that we look at continuous delivery in terms of making delivery more efficient and This is actually out of one of the books which I also oh, yeah Yeah, you see it here, which I also recommend so practical guide to continuous delivery by ever had worth So he looks at well what's happening after the commit and if you see the peaks to the top It means like something work gets done if the peak goes downwards then it is meaning that we have to wait and So it's waiting time nothing happens there and and so you see well probably this team can still Do some stuff better by maybe not losing five days before they go into acceptance testing Maybe they can also speed up acceptance testing so all of that so they can still do better and really Delivering continuously However, actually the real problem that I'm seeing nowadays is not that part. It's actually more here So looking at the holistic view because most of the time we are losing Way before Committing so this exemplars. There's maybe a request coming in because we have a new regulatory regulatory requirement or The customer wants something and then we approve maybe well the the request is submitted And then we approve it at some time like four weeks later in this case then two One and a half weeks later. We look at oh what this actually Effective what kinds of stories are in that and so on then we might have a customer sign off and only then it gets into a backlog really and So we are far away from that commit part we had seen earlier So in tier we lose already almost three months. Oh, I think it's about three months So really having the holistic view is what would help us way better to To really get more efficient here. So what this requires is actually What I call seamless collaboration Seamless collaboration across different roles hierarchies teams Departments all of that because otherwise we will never have the real benefit from continuous delivery now looking at the last aspect right the market aspect so There is one one problem that I think we often overlook which is deployment isn't the same as release and the Terminology that I'm using here is the one that Goyko Archie came up with Let me tell you so what's meant with that deployment means that technically we put the code into production Release means it's a marketing event. It's something where we surprise our customers And it can be at the same time, but it doesn't have to and as this example from that Basketball match. Well, sometimes the customer doesn't want to be surprised. Maybe not in that way at least, right and Just if you have might not have seen it with this terminology There are also other Terminologies floating around I know that I have used for many many years always internal release versus external release Or then there it's called a technical versus a marketing release That's Eric Reese terms so there they're like different terms for that But the important thing is to really be clear and differentiate which is rich and if you Yeah, right. So this is one aspect of the market aspect Market perspective. There's another thing and going back to Tesla. So now that the Clients kind of figured out that there is this over-the-air Update coming up. Tesla fell into another trap, which is also something you can fall into Which is how to deal or manage expectations? So I think it was even the same year as that other incident I was talking about So in that year Tesla came up with a new model S In that new model S they had this unit for autonomous driving, but at the time it didn't do much so it did like lane control or distance control of course cruise control and Tesla said like okay, but we promise you if you buy that car you will get over-the-air updates and Probably there will be a time where that unit really allows you to autonomously drive Now everyone else who had like the model before Then was really angry because they said well we want that as well We have bought a Tesla model S and we want that too right and we know that you can do that And they even started a petition and so they had some people signing up for it But actually we're not enough probably it's because it's still a too small community here and test that then said well The thing is because it also needs a hardware unit and that's why we can't do it However, my main point is with continuous delivery you also kind of create expectations you have to deal with and manage Another thing is now you deliver the stuff You also need to ensure you understand how people are using the system you are building So I think what we really need is to monitor and test in a different way which features are actually used and maybe We features had been used and over time they are not used anymore And therefore the system should also adjust to it and we shouldn't be Still maintaining it and carrying that waste with us. So we need to learn from the deployment as well. So that's another different aspect from the market point and And Yeah, so actually it is more about outcome versus output So it continues delivery shouldn't be so much about well just shipping stuff It's being it should be ensuring that what we are shipping makes a difference for the customer So it has had an impact in the customer's role now the question is how do you decide on Delivery so what shall be really shipped? The one question is is it usable and that's more the aspect probably we talk most about so is the quality good enough? And so that we can ensure everything so we can ship it But also is it feasible really because maybe you want to package it with something else together in order to really make a difference and Lastly is valuable which is more as something that can be answered by marketing or sales so that now this way we make a difference in our clients world and I think well, I'm impressed by myself. How cool is that because I manage really the time so I'm wrapping up So tools and technologies is still a thing However, I really believe we need to look at it at CD from a different angle in order to really benefit from it And I want to close with the quote of a friend of mine three That's really his name Roman three Unfortunately, he passed away two years ago And I was sitting with him at a like a small gathering and we were having lunch in a room Where before us there was a meeting where people it seemed spoke about the actual Principles and three always kind of a I don't know He liked to outburst something and so and so he saw that principle which said Working software is the primary measure of progress. He looked at that I'm not sure. Does this really make sense shouldn't it be rather Effective customer is the primary measure of progress. I thought this is extremely smart And I'm not suggesting we change that to manifesto, but maybe in some way we want to change our understanding about some of the things and to really Yeah, benefit from that. So with that, thank you very much and it's really on time Thank you. And actually my two latest books That's the retrospective one and the company by agility one They are still at the bookstore if you want to check them out. So thanks Yeah Yes, I do. So this one. Yeah, is that time for questions for one question? Oh, how cool is that? Yes, any questions? Yes, talking about the cultural differences the last one this one, okay The cultural differences when you talk about are we talking about cultural differences of the Customers who are receptive to the continuous delivery or cultural differences that like for example the GM used by Different countries of different nature and then you start losing trust Because trust is more important than the look and feel of the vehicle. So yeah, my things come to my mind Yeah, so the question is what do I really mean with cultural differences? Actually, I don't in this way here in this context I don't think of like different cultures in terms of nations countries or so that's not the thing But more like the way we develop software. We do it with the specific Projects of our development culture and this needs to be changed in order to really benefit from CD Yeah, thank you for this question Okay, thank you