 Good morning, everyone. My name is Marek Tizayardis, and I came here from Finland. And I have the privilege of sharing some of my lessons and stories and things that I have gone through at work. A lot of times, I find that when I go to Agile conferences and I listen to so-called gurus, the people that I have read books from, like the morning's keynote, I feel like a total imposter. I've been only doing Agile since 2001. Like, you know, I'm completely new to this. 2001 is a few years back. And, well, I've been around in the software industry for 25 years, but it still feels like it was yesterday when I started. And a lot of the stuff, kind of like what I read in books, I get inspired by that, and I try very hard to apply that at work. I do stuff around continuous deployment, continuous delivery. I'm a huge fan of more programming. That's absolutely one of the most biggest favorite things that I have. And I do things like what I talked about yesterday, things like having no product owner so that the team holds all of the power. So I do many things around Agile in the organization. But still, kind of the thing that I have, because I work as part of a team, usually my title is the lead quality engineer, but for the last about six months, I've held the title of a senior manager. So I'm managing a team of 12 developers and we are delivering software together. I'm a manager with very hands on roll, so I still test with my team most of my time. I just have to do certain procedures around growing people and making sure we make notes of having had discussions about their career path and growth. But a lot of this stuff, kind of like, you know, working in the real project and particularly being stuck in one organization. I don't actually think of it as being stuck. I think of it more as than like choosing to be stuck, choosing to spend a relevant amount of time with a particular organization. Some of the things that I feel in that case is that I can't do all of the things as the books say. I have to actually suffer through things that are, you know, I hear things on the stages here that, you know, other people say that they have gotten rid of it. But I actually have to, you know, do those things and that's kind of one of the motivations of this talk here today, that I keep on striving for better. We keep on striving for better. We keep on trying to change things. But the change, sometimes it's costly, it takes money, but especially what I find is that it takes patience. It takes time, it takes continuous, small changes, mentioning stuff that you would like to be different for multiple people and just not giving up, being persistent, being, you know, driven towards whatever change you're trying to drive in your organization. And again, I kind of tell these stories that I tell here from the position of my title was one of a QA engineer. So that's not the highest title in the organization. And still I'm telling stories, usually, around things where we could make a relevant change starting from something that I initiate as just someone working in the team. So I hope that's part of the story and inspiration that you can take home today. But I believe that, you know, all of us with persistence can do stuff like this. So we're gonna talk about an experience of moving into continuous delivery. This is actually an experience that I have had in multiple organizations when I have changed jobs. I enter a place where we don't quite yet get it and then I try to get us to move there and then kind of like, you know, take us through that route. And it seems to be a repeating pattern and it's a journey that is not always, well, never completely there. So when I talk about continuous delivery, what I mean is that we have probably still somewhere in this overall pipeline, a person involved. So it's not automatically from checking something into the baseline that we get it all the way through. There's usually still in my processes, there's someone at some point doing some kind of decision at least, if nothing else. Nothing else and we're still striving to get to the other CD, which is the continuous deployment part where all of the decisions would be made as the code is being created. So that's the world that we're talking about. So I worked in a company called F-Secure. F-Secure does cybersecurity software and my team in particular is a corporate endpoint team and we do Windows endpoint protection clients, which basically means, you know, simply said antivirus, firewall, that type of things. So different mechanisms of keeping a personal computer safe. And I joined this particular team and this particular company two and a half years ago. It's now my second time around in the same company. I also used to work there 12 years ago when that company was starting to implement Agile in the first place and it's actually a really fascinating thing to kind of like, you know, going into a different organization or actually a couple of different organizations and then coming back home, so to speak. And I'm looking at kind of like, what has changed while you were gone? And I'm looking at some of the things where kind of, you realize that you were some of the blocks of progress while you were there. So it was actually good that you were away for a while. But again, when I came back, I came back still at 2016 into an organization that told me that in the team that I joined, delivering frequently would be impossible. So we had usually, typically, we would have smaller, we call the maintenance releases about quarterly and then a major release about two times a year. So every second one of the releases was a major one with some cool new features. And every second one was kind of like patching it. And we were very used to that rhythm of working. And as someone who works a lot with testing, I know how painful it is to be in that kind of project. The last weeks just before release are awful. And having been in better places, I know that that's not the life of a human being. If you can have a choice, you do not want to have that. But you would want to have this steady pace of getting a good night's sleep and not having this rushed feeling in the end, trying to get the right information together at the right time. It should be, every day is the good time to get that information. And I knew from my past experience in other companies that had implemented things like continuous delivery, that it was a complete game changer for testing related stuff. So again, doing smaller things was a lot easier. So I started having this discussion around like, well, why is it impossible? Like I believe we could do it. And I got a couple of answers that were kind of relevant and foundational. The first answer was that, well, the type of software we are doing, no one does continuous delivery on that type of software. So even Amazon, they have whatever, 30,000 computers. That's only 30,000. We have five million. We have to install in millions, basically. Like any time we deliver, we talk about millions of computers because we're talking about home PCs, not servers somewhere. So while the usual stories around continuous delivery that I could find were around this idea that your users in masses were somewhere and they were connecting to a service with some interface somewhere, the world that I was now joining again was a world where an individual computer could basically have whatever in it. If it was a consumer's computer, your home home computer, I can't prevent you from installing a VPN client there that maybe doesn't work together with our software. And I have no idea which VPN client you're gonna be using. Same thing with other antivirus software, most networking applications, and a lot of the programming tools that we actually use. Conflict with antiviruses, because there's so much file editing going on in the way that we work that depending on how your environment is set up, I just cannot have all of your computers at my work. I can't build that kind of environment. So there's no docker image that I can take out of all the millions of different kinds of computers that are completely under someone else's control. But of course, the situation that I came into, the team that I came into, is a little bit different. So I don't work with all of our products. We have a shared code base, but I don't work with all of our products. I work in particular with this one product which is oriented towards a service, security as a service. And that, since it's for corporations, also means that corporations have this habit of just at least a little bit having a more similar environment within their company so that their admins don't actually have to see the whole scale of variety. But the basic software that we're building, it's still essentially millions of different computers. Whatever flavor of Windows, it used to still be Windows XP that was supported. All of the different ones that have come out ever since you could have any of them in your computer. And that was the environment we were building for. So I started looking for others who had done things like this. I wasn't actually able to find many, but I found many that had done similar steps in some scale at least. So I was sure that there is nothing that would completely block it. So we just needed to kind of like invent and figure out what the practice is here would look like. And the other thing here, what people would say is that, well, since this is a corporate thing for businesses, no user, no company, no admin would allow us to deliver frequently. So again, all of the interruptions, like maybe you need a reboot. That's kind of a bad thing. Every time you deliver Windows software, you know from your own Windows machines probably by heart that it's super annoying that you have to be rebooting all the time. So we had all these considerations of like we don't want to cause so much trouble. Like what if we would do this even once a week? Like they would just remember us as the reboot engine that makes everyone reboot regularly. So that's not really a perception that you want to have. And the first thing that we actually could come up with on this one is that in the recent years, we've actually been implementing a completely reboot-less way of introducing new updates to that. And it's not that special in that sense, but we were just so used to the idea that there would be a reboot here and there and there's nothing that we can do until we learned that, of course, there's something that you can do. The reboots are always caused by locked files. If you don't have a locked file, then you don't need a reboot. So if you figure out a way of going around that, it's just a technical problem. Then it's all possible. And the third thing that everyone kept telling me on why this would never work is that, well, to build a set of installers so that we could make a release, it took us five days, usually by at least one person fully working on it, but usually by another person, at least occasionally supporting. So it's probably more like seven-man days that it was taking. And there were some aspects of testing in it. So not only the building, but some aspects of testing that needed to be done manually. But that was actually quite little that needed to done on that side. But the big part was all the different things on getting the right executables together into the right kind of package, having them sign so that there's different people signing. They have to be actual people involved in that signing process. Because if we end up releasing software that somehow gets compromised and someone can fake being our software, that's kind of a serious thing for a security company. We do not want that. So all of the signing mechanisms related to Windows, we had to have those in place. And that was a really, really slow process. And even though we have made it a lot faster, it's still the process that makes us from, keeps us from having continuously deploying things automatically because there will always be that manual step. Unless I managed to complete my so far two-year project of trying to get the practicalities together so that we could have automatic signing and the proper trust relationships, technical trust relationships in place. So the people's stuff is now okay, but the technical implementation is still kind of on the way. But this was really the case where I went. And a lot of the discussions that I needed to have were kind of like, funny that you should say that. It seems that other people are able to do it. And even other people inside this company are able to do it. Like why are we not looking around at all? So first of all, in an antivirus software, it's not just that it's one layer or one component. It's actually a lot of components. It's 54 components that we are building within my team and the teams who build into that system. But also there's these, what I call service components, basically databases that need to actually be changing every single day, multiple times a day. Because otherwise, if someone comes up with a new virus, we don't have a detection for it. We don't have a removal for it. We need to actually be moving just as fast as any of the bad guys in this area. So we had actually been doing this, this kind of continuous delivery, even continuous deployment on that area for quite many years. I didn't even realize that we were doing this already before the whole continuous delivery, continuous deployment became a big thing because it was so kind of like separated from what I was doing on the higher levels of the product that I wasn't or many other people weren't paying proper attention to it. We also, during the first year of my return in FCQ, we completed a long, long project that had been going on for quite some time, which was basically introducing a kind of, there's the databases part, which is on the bottom, then there's an engine kind of framework somewhere in the middle, and then there's whatever I'm building with my teams on the top. So the middle layer, they had decided at some point that they wanna go versionless, basically, so that they don't have to care about which version it is there, so all the APIs need to be compatible to different directions and all the stuff that we talk around how to make these fast deliveries possible. So we were just about to do that, and I was there for the first year to complete a delivery of the clients that included the change into the versionless. Versionless engine framework, and it didn't really feel like we would get the full benefit out of it if we didn't really follow with the whole product into the same mindset. And also, we had figured out with some of the newer technologies, I don't know how many generation of technologies we're right now in, it's still the same product, we've been building it for 30 years now, but it has completely been rewritten so many times that I think nothing of the original is there anymore. But in the current version, there's this possibility and we have figured out how to do rebootless upgrades, which was a big, big blocker. So having these kind of discussions, and like, you know, we could actually do this, we maybe could try what if, you know, in some scale we would start doing this. Maybe we can figure it out, maybe we can delay the actual decision and we can try it out first. That's how we kind of got together. And really, why would the product facing part be so different? It's not actually that different. So again, as a security company, we realize that, you know, since we are working in defense against so-called bad guys, we really cannot be moving so slow and different threats around how people are trying to get on the computers and how we are even detecting if something bad is happening. They've been changing so much that we can't really wait three months to have a fix available. We need to somehow figure out on how to be just as fast as the other side, so to speak. So we didn't really put together any project. It was just something where in the development team that I worked in, back then in the lead quality engineer role, we talked, I talked in particular to my manager and I got the manager convinced that he needs to put one goal into everyone's annual goals. And the one goal said, you need to be able to release in two hours. That was a one year's goal. And everyone was a little bit grumpy first of that. I'm like, oh, we get these insane goals. Like it's, you know, so much work. Like if we start practicing these five days every time, we don't do anything other than releasing. And after the, about the week of grumpiness, it's like, okay, fine, we have to do it. Let's just take care of it right now. And, you know, a few months later, it was almost like magical. When I got over the team, got over the idea of not wanting to do this, it didn't seem like it was such a big deal after all. It wasn't super expensive. It was just that we needed to be very structural and think through what are the phases in our releasing and have everyone in the team implement bits and pieces that would help the flow. So that we would have test automation that we can easily run on different environments, different combinations, different products. And we would have all the different tools on building a package in a reliable way out of the trunk. And it wasn't that big of a thing, but we got to not two hours, but actually three hours in that timeframe. Another thing that is kind of good to understand around in these, what we were doing and what kind of things we were practicing is around the way we're building things. So a lot of the practices, kind of the originating point even for us to do things is we think of as in like, we're not doing XP, extreme programming, even though we're an agile house, the technical practices are not in that side, but our technical practices are more of once like an internal open source community. So all the code is available for everyone. Anyone, in any role, has access to the code and can make pull requests. Pull requests are usually out of a branch that lives less than a day. So it's a very short lived time. There's a rule, well a rule of saying that I keep on quoting to people who have trouble getting their things merged in is that you should be the burden of the statue. When you do smaller things, you usually suffer less. So if you're staying in a place, you usually get it stuffed by the passing birds. And that's really a lot of the experience in the version control. But we're basically, for the Windows clients, for the 54 components that we're building, we are sharing them with teams in Helsinki. There's several teams in Helsinki. So mine is just one, mine is 12 people, but there's other teams as well. Then we have teams in St. Petersburg working on that. And we also have an office in Poland. And now, this year, we are moving also to have some of that development into the same code base from South Africa. So our practices have to scale to the idea that we don't get to meet everyone every single day. But we're putting things into the same code base and out of that code base, we are making a release basically by taking out whatever is in the trunk right now and making it available for our clients. So my side is that's the little sauce for businesses thing, the orange one. And all the numbers are only from that perspective. But since every other direction into this kind of bubble that we have is also committing code into the exact same code base, we need to have common rules on how to do that. And basically, it is to never break the trunk always have test automation, unit testing and the higher level test automation and make sure that it stays blue, blue all the time. And I don't even consider that a release practice. That's just a way of how we work together so that we have any chances of knowing where we are in all of that. But I just checked that we had 42 people contributing lines of code into the code basis last year for the components that my team is responsible for releasing. And one component had 19 contributors. So mostly we're actually being quite successful with the idea that anyone from any team can go and make the necessary changes in whatever component. There's just a guardian available in the other teams. So for us, this all meant that we needed to find a new way of delivering. So that we would have not just a cadence, like not every two weeks on or Friday, we would make a release. We didn't want that. We wanted that whenever something valuable was available, something that the users could benefit from or where we would want to see that it's not risking the users. We would want to deliver that, throttle the release a little bit so that we could see that the first computers, the telemetry shows that they are getting it nicely and then only open the channel completely so that all of the millions get updated. And the releases when they were tiny, the testing effort, even the manual thinking testing effort around that is much more manageable than if you have this huge, huge thing that you need to work on. And we kind of focused all of our energies into making something valuable and estimates is not something we consider valuable. And that's something we kind of got rid of as we were starting to do this faster releasing as well. So I find from my experience, having gone through this now with two different organizations where I have worked in, that this whole getting to less than a week, preferably daily releases, it's a complete game changer. And sometimes when I have then discussions with people around like, why would I think of it as a game changer? We're still testing, we're still developing, we're still releasing, we're still managing, we're still doing the same things in many ways. There is nothing new in the world in the last 20 years. I need to kind of go back and say like, why do I then feel like I'm living in a whole different world right now than the world I lived in 25 years ago when I started in this industry. Like if it's nothing new, why is it that it feels so different? So this whole continuous integration, continuous delivery and the fast feedback cycle, it has clearly changed at least my profession, the testing profession completely. And talking to my fellow developers, I find that it has changed their life quite relevantly as well. So what I didn't try to kind of explain to people and try to figure out on how to kind of say this is I find that metaphors are maybe the best way that I can try to approach it. I find that if you think of two things that look kind of the same. You have a pool, swimming pool, or you have a bathtub. Both of them are containers of water. Well, one of them has a little bit more water, but it's still water. Just like it's still testing, it's still developing. It's still water. Why are these different? And it's really easy sort of for us to see that of course a bathtub and a pool, they are a completely different thing. There are things you can do in a bathtub and there are things you can do in a pool. So I don't know, looking at the bathtub we have in the hotel yesterday and my daughter here in the first row, using that bathtub and drinking some soda in that bath next to that bathtub and seeing all the cans dispense. I was thinking maybe she was having a party at the bathtub, but usually normally we would think of a proper party to happen rather on a pool side than a bathtub side. So that's really not a thing. We have things like lifeguards. We need lifeguards when we have multiple people in the same container of water. But we didn't need them when we had the bathtub and we were just using that as the container of water. So there are things you do in a bathtub and there are things you do in a pool and they allow you to do very different things. And this is how the continuous releasing, the fast small slices of delivery changes our world. That it enables us to do things that work. So one of the materials that I really, really enjoy on kind of using as a frame of reference on where we are is, well I have to read from here because I can see from there, by Paul Hammond. So I'm definitely just a practitioner and these kind of like great thinking pieces are really, really helpful in understanding kind of where we are going. So when I say that things change when the rapid releasing starts to happen, practices have to look different. We can do different kind of purposes. It gives us a very different environment. So you would branch differently. You would probably test differently. You can't test in the old way anymore where you would have a release every three months. You can't test in that way when you're doing a release more frequently. Your architecture needs to change. Your releases cannot be scheduled and planned and kind of like taken as a plan and being made to sit in a release train which is a safe version. But they're kind of organically flowing through the whole system. Probably also the practices around infrastructure and databases are gonna be changing. So some of these words here are much more relevant for the web-based services type of world that I don't live in. So I find that when I'm trying to kind of place us on that map, we're somewhere more on the right side but in many ways we're somewhere in the middle because we haven't yet figured out all the ways to get all the way to the right or how it would actually be different in this kind of environment. But again, if we have this, we need to make a release right now. We take the trunk and in three hours it can be out. It's not a bad solution that we have in place. So it's definitely something kind of nice that we've done. So all of this kind of leads me to this idea that even within the same organization, we are not all safe. So I mentioned 42 people. My team is 12 people. Not all the people in my team has actually committed anything last year because some of them identify still as testers who don't do automation. So they might not have any commits as such but they're more like, you know, preparations, participating in discussions, bringing in certain perspectives. So I find that I really, really love to be in my team. I really enjoy it there. I like the fact that we can work without a product owner and we get to make decisions about the health of the product. We get to do all the operations stuff. We can look at the telemetry. We know more about our customers from what they actually do than the theoretical part of what they say they would do. So I find that kind of like right now, my team, that's my good place. But I don't always get to just work within that one corner. We sometimes having that common code base, I need to go and work with some of the other teams and then I've given them these really loving nicknames. I call one of them a soul sucking place which basically means that they have very, by the book, agile practices where they stand up every day and have discussions around things and very like team inclusion in everything, sharing everything, almost feels like they talk about what they eat today, that you need to share that in the team. And it's a little bit different place and I feel like it's using a lot of my energy, not of the value that we want to deliver, but more on certain kind of like risk aversion practices. That's what I would call it. So risk aversion practices nowadays, they seem to be sucking my soul out. So that's why I call it this name. And then we still have, sometimes, someone comes up with all we need to build a new product completely and we set up a project and we give it a date, it's gonna be out in September, that's when it needs to be out there. And we might not have even recruited the people to do that project when we say today that it's gonna be out in September. And that's the style of projects or delivering that I call the insane asylum and it is kind of targeted towards this idea that we would only release once in the end. So in my good place, we release either daily or weekly. So any day of the week could be that release day, but our idea is that since it is a relevant size of a package that we will be updating with the changes from the 42 teams, we still do not want to deliver that. We're figuring out a way of still splitting it in smaller pieces, but we don't want to do that more than once a week. Once a week, but we wanna be able to do it on any day of the week, not just on a particular day. Then with my soul sucking place, we usually work with two week cadence. So the day when we are doing a release, like everyone knows that it is really well scheduled, like it's gonna be every Thursday. So there's a planning and then all of the moves towards releasing. And there's this kind of like joy, boredom, boredom, boredom, but little bit of joy, pain, pain, pain. And that's kind of like a profile with the two weeks. So again, the pain isn't as high because it's only two weeks, but the pain, you can feel the peak of pain there always. And in the insane asylum, I really wish these wouldn't anymore exist, but even with what I do, I still live through this. In the end of the project, we're supposed to have it all available. And we are sometimes still struggling with having 20, 30 teams working in this project. Get them to the idea that we should, at least for ourselves, be delivering continuously, even if we didn't give it to the customers. You don't have to share the link, that's fine, but make it available. Don't keep it on your development machine only in the CI environment. The attitude to quality is often very different in these three places. In the good place, we usually talk about like these kind of concepts, and like I really care about production. What's going on in production? How can we make production a little bit better? And for example, right now, my team has less than 20 tickets in Jira. Out of those millions of customers, we have only 20 tickets because when a new ticket comes in, we try to take care of it, fix and forget. That's the basic idea. So we care about the production and how the feedback and things in production are a lot in that type of a model. In the middle ground place, where we still work on an agile cadence, it sometimes feel like we need to get together and plan and move a little slowly and think of things, and let's make one more plan and the kind of rapid whiteboarding and the production orientation isn't quite as much, but it's kind of like a risk aversion, it's a little bit more there. And in the insane asylum, when they're trying to get control over it, I find that the motto we use mostly in the organization is, I care about my feature up to production. And we need to repeat this a lot of times for every single developer, care about your feature all the way to production. But it's not enough. You need to care about the feature beyond, well, in production, actually, that's where you go into. So these are easy to see when they're serving different kinds of projects. The way we deliver in the good place is that we start together, we finish together, and it's a very organic discussion-oriented way of doing things. You go on a whiteboard when you wanna have a discussion. You call and do a remote whiteboarding session if you wanna have a remote discussion. And when you are about to be done, you're never delivering anything all by yourself. You're never alone. So there's always the safety net of other team members. So you can pull whoever you want and make sure everyone is always available for others. But there's no strict process saying that this person is approving your work. It's just you need a second person because we don't want you to be alone. The solar sucking place does a bit of this Jira roulette, like who gets which ticket. So it's in this state, these people take it. I really think that Jira stuff is one of the things that mostly suck out my soul. And the insane asylum is anything that you can think of, you create a new ticket in Jira and then someone is trying to make sense out of those tickets on how they are, like how many of there are, like is there any progress on where we are? And then at some point of the project when someone is worried about the schedule, then comes the managers, usually the high level managers, who force everyone to sit hours and hours in the meetings scheduling all the tickets so that we know if we're gonna make any schedule or what the schedule is gonna look like. And I just look at that kind of like, why are we still doing this? Like we have managed to not do this in so many projects. Why some still end up like this? So it's a long path for us to grow in our organizations. Maintenance, also very different in the good place. It's a fix and forget and when things go wrong, things break in production. Like you can revert it, but a lot of times it's actually faster to fail forward. So you can stop, in my world, I can stop the impact being any wider, but I often cannot revert an individual person's computer. But I can make sure all of their hundreds of colleagues or thousands of colleagues don't get to experience the same problem that the first one saw. So failing forward and fixing that one computer and fixing the overall deliverable is much more of the way. In the soul-sucking place, usually we spend so much time with estimates that we don't have to deliver as much. And in sale and asylum, it is really building these maintenance projects. There are about half of the effort that we generally use. So there's always the cycle of new features and then maintenance, so going through that cycle. And we're so used to it that sometimes it's hard to avoid it. Uncertainty in the good place. You know, I feel quite tolerant with the level of uncertainty. I get the colleagues together and we have discussions. Even when I'm here, I can have a discussion online with them. Also, well, I'm lucky enough to be here and not having to be there at the same time. That's part of the way we are trying to work so that there's no dependency on an individual person. I kind of enjoy being at the conferences. The soul-sucking place, well, uncertainty is managed, but sometimes I say that we use about 70% of our time into the uncertainty and 30% only into the value. So there can be a lot of practices around that. And in the insane asylum, it feels like you put a gun to your head and there's one bullet out of six and that's how you kind of like deal with it. Like you just have to take whatever comes because the risk is so large that it's hard to manage anymore so you haven't split it up. So all these different places, different projects, none of them are hopeless. They're just on a different place in the path. And we need to keep telling the stories within our organizations to get us, get the other teams, get everyone onto the path of having the lesser pain. The practices do change, the development practices, testing practices, product management and management practices. Jeff talked about all of these different categories actually in the morning keynote. And it feels really like you're in a completely different place. So the good place is one where you somehow end up with a reputation of flaw. Like, you know, things just go through your team so no one even asks you of schedule. You know, they tell you of things of importance and you will say like, oh, I acknowledge this is important. They just assume it comes out. They don't ask how long it's gonna take you. They know that you will do it as quickly, you know, in small pieces as possible. And that's what I get to experience. So it's a completely different relationship with the business people when they don't, you know, ask you how much is this gonna cost us at first. And they don't really care about that answer. That's only for them to say that they can't get trust your delivery ability. So they don't want to pay for the estimate. It's a comforter for them. There's a lot more effort available to put into the impact and the value that goes out of the whatever engine we have that is delivering this and less into the all kinds of padding risky oriented management practices and change control boards. And there's things where you realize, you know, you put a list of things you're doing where that's, you know, time to take care of this right now, fix and forget. And then there's things where, you know, time takes care of them. Like some of the things just aren't as important as others. And you start seeing these patterns a lot more when you have the continuous feedback cycle on what is pressing in the production right now. What would be the thing that you would look at right now? The code base is your ultimate truth instead of all of the documentation that you try to wishfully think that you would have. So that's a nice thing. And testing really kind of flows together with all the rest of the team. So it's a very nice and collaborative and close relationship. It's not only automation, but it is only the, you know, thinking through all the things that might break because of this that we're doing together. And finally, when you have this continuous feedback loop, it is like you listen to that feedback and you get a little bit better. If you keep on being the same, you're same in a year. But if you're a little bit better, 1% better every single day, in a year you're actually 38 times better than you are right now. So learning, listening to feedback that is absolutely the winning way of working. So we talked about this idea that a bathtub and a pool are two different things. They're both containers of water, but they serve completely different purposes. And in the sense of continuous delivery and continuous deployment, delivering all the time, it enables you completely different practice. Thank you. I have time for a question. Anyone feel like asking a question? There's a couple on that side. I can repeat the question if I can hear it to here. So you had as well, okay? I can hear you and I can repeat your question. Hello. Actually, just wanted to understand, like you just mentioned that in your team, there is no PO, right? So I just wanted to understand how the user stories are coming in and if there is a change or manipulation in the user story, how as a team you're taking care of all those activities. So can you brief me something in that sense? The question is, since we have no PO, how does that work? I spent 45 minutes explaining that yesterday. So there will be a video with a long version of that answer. But it's really the same way as business people would get those. They fish them around and they put them in some kind of a list. They have some idea of what's most important. We do that, but we also know that technology impacts of whatever we decide on doing that. So it's very similar. It's just that the belief system is that serving the customer's right is the most important thing that we should do. And the most important thing should not be left for one brain. It should be every brain's problem. So that's basically the summary of the no PO. Also I have one more question. Like it's related to continuous delivery. So like you just explained how have you implemented the continuous delivery in your team. So for example, if I want to implement the same thing which you are implementing in your team and how to make sure like nothing is breaking when it is going into production. Like we should take care of test automation or continuous testing. How you're making sure of all these activities. So this is again, I find it difficult to answer some of these. So having test automation is a good thing. My first project in my before this company when I went to continuous delivery we did it completely without test automation. So there are other practices that you could apply as well. So I think we should have a longer discussion about this after that. Yeah, I have a question. Oh, that way. So basically you spoke about variable frequency time boxing. Yes. But will that not break the cadence if there are multiple applications going into release at the same time. So there are variable frequency time boxes. Time boxes. So it's again, what I mean by that is is like if we want to do one release on this week it might be any day of the week instead of having a particular day when you're scheduling doing a release. And I do work still towards figuring out ways of changing the product so that this could happen different times of the day so that whenever it is ready it is not, you know, you could deliver that application right away. My question is, as you went through this transformation journey what was your project management strategy? Like. Project management strategy. Yeah, because how do you convince those people who are with this 1980s mindset to accept this? And what are the new matrices that you came up with instead of the old ones? I'm not sure if I have an easy answer for that. So we usually don't have project managers for most of the things. Like we are very team oriented and the teams kind of work in a network manner. So that's kind of, we've organized this like a network way of co-managing whatever we are delivering. But yeah, the lean practices are very heavily there definitely in many of the things. We can have a longer discussion about this so that I can understand the question better. Yeah. Thank you. So thanks everyone. I think it's time to take a break. And I'm gonna be around all day today so I would be happy to have more discussions on any of the topics that, you know, pique your interest. Thanks.