 Good afternoon. Thanks for having me here. A bit of a question. Whom of you is designer? Good. And whom of you is more in the engineering side? That's going to be a bit of both. The story of today is basically from doing the things right to doing the right things. And I think for me, it's basically the same as stating from agile to design thinking. I think the true value in agile is that you do the things right and if you're not careful, you do the wrong things right. And you know, we are a master in that. That's why I came and have the experience with you today. In order to do so, I'm going to start basically running back a bit of the time. I'm going to explain what happened to ING and why did you make the change. Oh, I'll interrupt myself a bit. I'm the CAO in the Netherlands. ING is a large bank, one of the larger banks in Europe. We have served in Asia as well, in Australia, in Thailand. And you know, it's a typical large monster. And then about seven, eight years ago, we were quite challenged. And why were we challenged? We were challenged because our IT projects basically very often failed. And you know, and if we would be the only one, then it would be okay. But it was a bit of an industry problem. And we saw a lot of failure. And the question is, why do we see all that failure? And I thought, let's start with a bit of an explanation how our ING worked, that you get a bit of a flavor of what happened. So imagine, imagine what happened seven, eight, ten years ago. You want to do a new mortgage system. So what do you do if you want a new mortgage system? And you know, mortgage systems are complex. You have 30 years of mortgages in these systems. You make a business case. And with a business case, you go to the board of the bank. And these business cases, they were really, really fantastic. In PowerPoint, consistent font sizes. You know, the fonts were great. Everything was nicely aligned. And basically, we always made two big promises. And the first promise is, if you give us this money for this new mortgage system, our revenues will explode. And the second promise was, our cost will implode. Well, who's against those two promises? And basically, you go to the board. And the board, they don't believe half of what you say on the revenues. And they don't believe half of what you say on the cost. But if they take out half on both sides, still NPV-wise, it makes sense. But the problem is, they have a totally different question. They only have one question. And the simple question is, why do you think you can manage it this time? That it's going to work this time, after the failures of the last years. And then, we always had a very good convincing story. We have a new project director. His name is Peter Jacobs. This guy is fantastic. He has been doing projects for his entire life. He has never failed a project. Execution is his middle name. Look at the suit he's wearing. It's just unbelievable. With this guy, it will not fail. And everyone understood that it's big, big nonsense. But how often can you say no? You can't say no forever. So basically, you see what a board of a bank does. They say, okay, you're allowed to do it. But this time, we want to be in full control. This role is his second middle name. No worries. And they'll do it very structured. We'll apply a process that is so structured that we will not do before we think. We will set this up in very strict phases. And we call this the waterfall model. And the first step is that we come up with all kind of requirements. And then we continue from there, and we will not continue until everything is perfect. Well, doesn't that sound great to an executive? But what happens? On Monday, Peter Jacob starts. He's the project director for the project. And what he does, he hires four project managers. And the four project managers, they come and they start. And what is the first thing they do on Monday morning? They go to the internet website. And they are going to look, how do I become a project director? And the HR website. Because they're only project managers. And what does the HR website say? The HR website says to become a project director, you need to manage people. So they know I have to manage people. So they all recruit four guys. So at the end of the first day, we don't have one Peter Jacob, but we have a nice Christmas tree. How about 20 guys who are going to make this project succeed? And then day two starts. And then day two, they have the kickoff of their project. And then they make the biggest mistake you can make. This is real life. So what they do is they give the project a name. They give the project is globe. I can tell you everyone who calls this project globe should have been fired on the same day. Because you're overscoping from the start. Your name is already overscoping. So basically what you do, you go to your commercial colleagues and you say to your commercial colleagues, you say, we've got the money. We're allowed to make this happen. But we're going to do it very structured. And the first three months, we're going to do a requirement analysis. And then the commercial guys make the biggest mistake in their life. They think this might actually work. And why is that such a mistake? Because they asked the question, if in three years we are ready with the commercial launch of this fantastic new system, will there still be money for me? And the honest answer is no. No, after three years mortgages, we're going to spend it on savings or we're going to spend it somewhere else. So this is basically your shot. What I know is I better ensure that all requirements known to mankind are going to be put on the wagon. Because this is the time for mortgages, so it's going to be all requirements that you can ever think of are going to be put forward. So for months and months and months, the smart people in Amsterdam, the ING internal staff is coming up with all kind of requirements, gigabytes in requirements, in PowerPoint, and then the day that finally arises and someone presses on submit because everything is shipped to India. Let's hope for the best. Then it comes over here to a group of people with a size of this team, about 400 people, something like that. They don't know what Netherlands is. They've never heard of Amsterdam. They don't know what banking and analysis is. No ING never heard of what ING is. Looking at all these requirements and thinking, okay, let's start. But basically the project is going quite well. So we report on progress and we have 20% and we have 40% and we have 60% and we have 80% completed. The executive board is finally really pleased. We have 90% completed of the project. 91% is completed. 91.1% is completed. 91.1% is completed because we received the first CD-ROMs coming back, you know, and we don't get it integrated and this is not what we wanted and our competitors have taken a total different route and is this what we needed? And basically we're in deep trouble and you don't know what to do if you're in deep trouble. You fire Peter. You don't fire him. But you circle him to another project and you get the other project manager who's also in a difficult situation. You get him over to your project and basically then you find a young guy 30 years old who with his young kids out of Amsterdam is going to move to India because he's going to rescue the project among 400 people who have tried to do the outmost to get code working but still don't understand how the Dutch tax law works with all these collateral mortgages and how could they even until someone is so proud that I would say that he has the guts after six or nine months later to pull the plug and yet another project failed tens of millions down the drain no code in production and then, you know, we start all over and the problem is, you know, if the problem is stupid people like Peter Jacobs or the entire IG stuff it's simple because you could try to replace them but, you know, we have the good educational systems we have the bright people, they're ambitious so it can't be that and it's not that the other industries in IT do such a big thing so basically it all came down that we understood our way of working is not good and this is the rationale for the change the rationale for the change is let's change the way of working and why? because this entire concept of waterfall this entire concept of first thing first then deliver that is by far the best way of making software if you can meet three simple conditions number one, you know up front what you want number two, engineers know up front how to build it and number three, the world doesn't change while you're doing this and I think that if we look at our language from architects to blueprints to we see that we've borrowed the entire way of thinking our own vocabulary is all borrowed from the civil engineering fields and now let's look at the city of Bangalore if they built a bridge over a river they know up front what they want I have two lanes here, I need two lanes there an engineer knows how to build a bridge and the most beautiful thing for them is that the river doesn't change its course while they're building the bridge and if you look at the mortgage system none of the three are true and luckily we saw that the market changed and agile was introduced so then for those that was basically the focus on doing the right things and we'll get a bit further on the road what are the agile promises and beliefs I'll tell you what agile is agile is, and I don't know in India if I look around I don't think it's the same but in Europe agile means having a beard and a cap and having soccer tables and being cool with cool furniture that's at least step one that you have to take so that's why I took my suit I thought today I'll do the opposite but at least that's number one, that's agile and agile is basically what is agile I think that whatever you do in life if you've never done agile or you want to do it or you want to do it more zoom out of the practices and start to understand the principles and even the beliefs and what are now the two biggest beliefs for me I think that there are three but the most relevant let's come one by one the first important one is the top left one no handovers basically if you look at Henry Ford with his assembly pipeline the guy who created all these nice cars for us he created the assembly pipeline and was able to scale out his production facilities since then this entire concept of an assembly pipeline has been introduced even to banks from the marketing division to the design division to the engineering division to the test division to the QA division and we basically have an invisible assembly pipeline where we are handing over stuff and handing over is very cool and good for repetitive processes if you go to the Kingfisher or the Heinecke breweries you will expect an assembly line filling bottles of beer but if you make software which is not a repetitive process you will see that in these handovers you constantly have to guarantee that the next guy does not basically that he does not fail in meeting what you intended so you write more documents then everyone who knows CMMI knows that it's one big document misery but the only thing you do is try not to break down what the guy next to you should be able to do so kill all the handovers handovers are wrong basically make people sit together give them an end-to-end responsibility the second one is don't focus on what you want to have in three years don't focus on the mortgage what you want to have in three years that they would like to bring to production those are my minimum viable products and minimum viable product does not mean let's do the functionality and forget the security minimum viable pyramid is not that we have a pyramid where we take the top but a minimum viable product is a slice so for example when ING launched its mobile app we just started with the current account so we almost in terms of functionality and non-functionalities especially in non-functionals they were perfect so we worked really our best to make it really perfect but we had no savings we had no investments, we had nothing no mortgages, nothing and then basically after six weeks we introduced the next slice and slice by slice you basically build out and why do people in the waterfall go for the maximum viable product are those people stupid no but it's very much also driven by funding you fund the change of mortgages so the entire discussion this is my time now it's my turn I get now three years in which I get to invest and basically also because people know that impact will come in three years they better ensure that everything what they potentially could meet in three years is in the on-bed wagon so people don't dare to go for minimum viable if you basically say whatever it takes I will invest six teams in mortgages for the next 200 years then people get relaxed because the budget is not gone, the people are not gone they can come in a flow and really try to build this further I think individuals over interactions over process and tools so I think that we over invested in all kind of IT support tools and I think that just having the open debate you've all seen how much we struggled to get even the beam up and running so we should be careful with all the tools and helping that I think this the debate giving people a phone call and a why board help I think working sort of code counts code counts is an important one impact to the powerpoint impact to the code customer collaboration I'll come to that especially of course this is this is the entire design thinking concept and listening to the gentleman from Walmart and he really inspired me today this morning I'm glad that I did not put user in there but customer feels like human so that's these better and I'm responding to change always keep on changing so these are a bit of the edge of these problems no handover focus on what you need next week and not next year so that was our that was the primary pillar of what we wanted to do in IG it's simple many people want to do it and it is we didn't invent anything by the way we just copy we bought the book read the book and said let's do it but then we felt there were a couple of impediments and one by one by one I will go to the impediments the first impediment that we felt was basically zero automation in our IT zero automation in the way we make software if you have zero automation in the way you make software you're in deep trouble give you one example that we had we have a core banking system imagine these are software the core bank with all the accounts and it's a US owned company who sells it to us and we basically got five releases per year and then you ask the guys how much time does it cost if you get a new release to actually test it test environments and then basically the people said it costs us a full team about 11 days and then you think you know I'm so glad that agile sprints are 14 days because at least three days are left in which we can do the design thinking and the development and everything because it takes 11 days to test before we can actually go to production and of course everyone started to laugh a bit because it's total nonsense you have to start automating the pipeline this is all about zero touch deployment and I know that there have been courses last week on the same topic this is all about decent software versioning systems where you put all your configurations in so also your deployment scripts your infra settings everything should be version controlled all your tests need to be automated and this has brought us a lot so basically we went from a couple of 100 changes per year those change weekend with these monstrous changes where everyone even the CEO has his mobile phone next to his bed he's informed by as a mess twice or three times a day over how the change weekend is progressing on Monday morning cake for everyone because of the big success at lunch you see the first failures and no one talks about them at four o'clock there are so many failures that no one can not talk about them those kind of weekends so basically we saw the solution in this book called continuous delivery continuous delivery is a fantastic book for everyone who does IT and it's a couple of years old especially the world of mutables was very important but to read this book this has helped us tremendously so today in ING 20,000, 30,000 changes per month and everything is being automated build the flow build the ability to experiment with software the third one is we copy the governance model we needed the new governance model this is an org chart and we basically copied Spotify's org chart normally when I talk to executives in org charts and managers like to talk about org charts and governance for me it's of the four pillars the least interesting one but at least we copied one and you could take anyone we took the Spotify model and then the last one and I think this is the most important one the most important one is if you go agile in an agile world you're with small teams and these small teams five, six developers but with us all the business people are in there there is no one out so the teams for us they do the development and the operation they do the prior one incidents in the weekends but they also do the design thinking the entire team does everything no handover so basically it means that you have five, six developers max, you have three, four guys doing marketing and product management and channel optimization so all the commercial guys and the IT guys together in a group of nine making this happen what do you get? you get job broadening in the world where we have very narrow jobs in the world and we go to very larger jobs if you go to larger jobs you need better people people who can do it so I think that there is a tremendous, tremendous focus on talent, talent, talent, talent we come from a world where IT guys were offered as resources almost by the volume if you take 100 you get this kind of 10, that kind of discussions and I think that we 100% appreciated that that is a lousy model and I think IG we are only looking for talent and I think that the productivity of talent is so much higher you see that we at IG apply a productivity metric of one to eight between a novice and an expert in our business review we read a lot of articles about one to 64 so basically and this entire concept of drivers we copied this from Netflix and the two brothers of drivers they were basically university professors having the observable behaviors and the quality of people I think it is extremely interesting for everyone in IT to understand what is your view on talent how do you grow talent how do you reward it and how do you get out of the situation that basically you are looking at large volumes without too much impact great people have an amazing impact so those are basically the four elements that we had and you see that today we are at a level even a bit further when we started three or four years ago we said we don't want this pyramid anymore with a few expensive guys per hour that are extremely productive but that we forget and we compare them with less expensive guys at the bottom and therefore less expensive is good to any CFO that model should change that pyramid does not allow anything we want to go for a diamond structure you see the novice about 5% advanced beginner 25 competent 55 proficient one and expert 5 should be guys who write books and who are known in the field technologies whether it is Kafka or engine nicks or polymer or whatever you do Pega or I don't care what you do but at least you have been known in order to get there and you see the talent attracts talent therefore we are growing more and more to the apple side and in all our partnerships also with our Indian colleagues the only thing we care about is talent people who work themselves and who have the full ownership they don't hand over we shall never have an external not producing code and bring that to production so talent is the one key thing so these are the four things so overall now the question is what did it bring if you look and there are many many movies and many sessions and many debates and there are many discussions about what makes people stay at the company you most likely all work for a company or yourself employed but lets for those who work at the company why do I stay and I think that for everyone who basically stays we came to the conclusion that there are three big drivers for you to remain part of a family and that is the autonomy, that is the craftsmanship and that is the purpose and now lets see if you compare ING 10 years ago with ING today to what extent do we see shift I think that there is a tremendous shift in autonomy, I think that the agile mentality has pushed for great levels of autonomy that the reason is we make teams independent and they can together decide on how they do it and make it happen and the impact is also there if you are a tester and you have done four days of testing on the new mobile solution and then after 16 weeks it goes live together with some other large complex changes do you still feel that this is your product I think that is so basically I think that the autonomy the levels of which you can do it it has gone up quite well if you look at craftsmanship you see that in ING if you don't produce code your support and you don't need that much support so I understand that I'm supporting two engineers so basically in normal companies you start as an engineer you become an architect and you grow to become a manager basically if you didn't make that in five years then your wife might say it's not going well how can I help with kind of discussions it's a bit different the guys at the top are the engineers and they're supported by architects and if you really lose you become the CIO so basically I think that the respect for craftsmanship is enormous and it's going enormous but to be honest in terms of purpose agile does not help that much if you're really honest I think that there are some downsides of agile that relate it to your maturity but relate it to the way agile works agile is so keen on minimum viable products that if you're not careful these autonomous teams will come with incremental innovations they will remain incremental and you will see that the orange color of ING on the button might change every six prints with two pixels or I don't know with two RGB colors so I think the risk of agile is that if you don't organize it well one risk is that you basically see that you become incremental in your innovation and the other risk is that this autonomy at least at large scale we have hundreds of agile teams that they basically strad out and if you're not careful in six months we would have opened a restaurant because people drift towards a purpose that there's no relation anymore with a corporate strategy so how do you deal with that and how do you make the right environments to basically mitigate the intrinsic risk of minimum viable products focusing on incremental innovations and a lot of autonomy taking you potentially to a course that's not what you want to do that's a bit of the challenge that I think that is our challenge and that we're addressing these days and that's where we make the shift basically from doing the things right the agile to doing the right things do that. We basically have three blocks on which you focus. The number one is the QBR, the number two is design thinking and number three is the OBEI. We'll go one by one and I'll hope that I'll bring you basically a bit further. The QBR is for a very important one. Again, we copy this so you see IG doesn't event anything. You basically get the knowledge of many companies by one guy. So basically what did we do? In the QBR, so how does it work? We want basically alignment in our strategy. So what does the board do? I'll go to the first one. What do we do as a board? We basically ask people for a quarterly business review. And many of you might have used the same term, but perhaps for a different process. So let me explain you how we do it now at IG. Basically we say a month before there basically the quarter starts, so T minus 30. We as a board in IG present to all colleagues basically what are now the key priorities on the entire board level. So it could be about asset growth. It could be about liabilities. It could be about primary accounts. It could be about IT risk. It could be about compliance. There can be many, many key topics and we try to come up with the key topics. And the way we do that and I think we want to express basically what is the impact that you want to see in 12 months. So not what are the activities we hope to do next, which is also cool but it's irrelevant. Not what capabilities you want to build. So not the activities, not the capabilities but the impact. So we try to come up with a photo that basically states if we would fast forward time in 12 months, this is what you would like to see on the photo in terms of impact. And you know, we want to see at least a growth of one million primary customers. We want to see that the market share in savings goes from 6% to 9%. I don't know. This is impact. So what we then do is we have these departments in this Spotify organizational model. The department with a purpose is called a tribe. And the tribe basically is the end-to-end delivering the purpose. So we have a mortgage stripe. We have a security stripe. We have, you know, we have different stripes from different components of the bank. And they're all groups of a couple of hundred people. And then we ask the tribe leaders, guys, you've understood our priorities. So at T minus 30, we want to give you two weeks, three weeks, 20 days, something like that, to know individually you as a tribe, we would like you to come up with your QBR documents. And in your QBR document, we have some very strict rules. Number one, we would like you to write it in Microsoft Word. Because we feel that PowerPoint is potentially a bit too fluffy, we want to see it basically in text. And in text, we would like you to answer three basic questions. What was the impact that you realized as a mortgage tribe over the last three months? What is the impact that you will deliver in the next 12? And what is the impact that you are going to do in the next three? So from 12 back to three. So then at team, so the teams are for three weeks to get a working with it. And they get a page budget. A page budget basically means you write it in six pages. If it's more, we won't allow it. Because if you need more than six pages to answer three questions, then your answers must be fluffy. So basically, and otherwise it becomes too much to read and you don't get the rhythm. So basically what you do, 10, 15 of those tribes at T minus 10, they all publish it at a kind of a share point. And the share point is open for commenting. So they start to comment. So after a period of 20 days where they, from the bottom, with all the power of their craftsmanship have been writing together what they want to do, all of a sudden the tribes start to basically see each other's documents. They start to online comment and online reply on those documents. And we as a board do the same. And basically it's very often, it's other questions, I don't understand what you mean. But it could also mean, hey, I thought we agreed, you would do this because I'm hoping that if you have that, I can build on it and go further. So that's the kind of dependency. You see horizontal alignment taking place. Then we go, and that happens for 10 days. And then at T is T, we basically have the QBR day. And at the QBR day, we basically have this kind of carousel where people can try to overcome the unresolved challenges. After they've done that, then we as a board have seen what are the independence strategies. We have basically seen what are the dependencies that have to be resolved. And then what we do is we allocate budgets. And budget allocation is no longer anymore about projects. No, it's basically agile teams are like Lego. They're about, you know, 10 people each. You can all figure out how expensive they are. And we basically, we divide the teams over the different tribes. We say based on the commercial strategy, based on our competition, based on this, we allocate four teams from mortgages to securities. And that can only happen if you have great guys who can learn, basically, how securities work. Therefore, once more, you see that the roles of IT, especially IT people, we don't look at what technology you have. Whether it's Engler or Colm or Kafka or Flingy Colors, whatever you do, Java or Scala or APL, it's a language I have to read over the weekend. I've been influenced. But basically, these kind of, it doesn't matter what you do. We want great people to make great software. So this is how we cascade as an organization, and how we try to get consistency in a kind of a corporate strategy towards how the teams see the objectives and materialize this themselves. Then we go to the second one. And the second one is, for me, it's about design thinking. Design thinking is magic. And, you know, I learned a lot today. I'm a nerd. I'm not a design thinker. I'm just a software guy. But I start to learn more and more and more. The one thing that, you know, I'm not trying to preach to people who know much more about the topic than I do. But what I would like to give to the people who do IT is if you look at the risk of agile, that you are always continuation your existing path. And at least what design thinking has learned to us is that you first have to broaden out. You have to go really broad. You have to divert, basically before you converge. So this kind of, you know, this kind of the fact that you, in order to rethink what shall we do next, that you're very tough to yourself, that you don't basically continue with what you had. Start to rethink about what could I have been doing and what is now serving the purpose, I think makes an immense sense. So you have the objective in your QBR. And instead of just continuation, you go broad before you converge to allures. And the second one, I think that this was published, I think 20 years ago already on design thinking. There are the four big principles of design thinking that I liked, that I like most and I will never basically forget them. So design thinking for me, it's human centered. And human centered is the most important thing there is. So it's the personas, it's the entire philosophy of what does it do with an end customer? And basically, how does the flow work for this end customer? So making a human centered design, I think especially in the digital service sector where we as a bank are, it's very, very important. The second one is ambiguity. Try to really ensure that you see all the concepts from left to right. Don't follow the obvious. Doing the obvious has made us feel. And I'll give you an example on where we absolutely failed. It's always nicer than the good stories. Then design thinking should be called redesign thinking. The word redesign at one of the pillars means you redesign because for some reason you are not happy with what you have today and making explicit with what you're not happy with is, I think, an extreme strong starting point. And then tangibility. Here you see the design thinking and agile meet because tangible tangible means code counts. It means build it. There is a prototype. Some of the people together with me today in the Walmart session have been using, how do you call it? The dough and pens and papers, but make it tangible. Tangible is, I think, very, very important. That's for design thinkers and that's for engineers. Build it and then test it and see it. So I think that that is a very, very important topic. But I promised you that I'll show you a failure. We had a fantastic, fantastic proposition. A fantastic proposition. I won't go into detail because a bit too complex and too Dutch. But it was basically an easy way to do payments. An easy way to do payments triggered by a webshop. A webshop can trigger you to do payments without a credit card, a bit of a PayPal-like thing. And then someone in our organization came up with the idea, if we as a bank would portray ourselves as a company selling money, and we would allow our customers to put the products in our shop. It's all a bit complex. But then we can use this technical route for people to send a webshop to a friend with a payment request, as if Amazon would do a payment request for a book. And you send the payment request and you pay the payment request to the bank and then we'll bring that back to the actual customer who owns it. So we basically had the negative payment, which is extremely easy. If you go and have drinks and food and whatever you do, you can just send a webshop to your friend. If you have a webshop group, you send one webshop and nine people get the payment request, they press on the button and the money is at the receiving end. It was great. And it only failed. Why? Our competitor saw it and after three weeks decided, why would I only offer this to my existing customers, not to the Dutch society? So basically, they published it not for their customers, but for the Dutch society. They gave it a bit of a better brand name. They called it Tiki. And now Tiki has become the Dutch word for payment requests, like you have Xerox in the US for copying. And basically, it was our total lack of being as smart enough to understand that ambiguity and going diverse and questioning yourself and don't go too fast to the convergence, the fact that we did not do properly design Tiki. Well, you've been, you know, competition teach you how to do better. So at least it makes you aware that next time you do it. So it's very, very important. Then the third one is the third one is that design thinking and I think also in the session we just saw from BVVA, it starts with the redesign understanding what needs to be redesigned. Why should you redesign something? You can only redesign something if you know where you stand. And I think that for us it has resulted in this concept of obey our rooms. And that came from Japan and obey our rooms basically kind of a war room where you basically use all four walls. And in these, you know, I'll show you both the structure and the process. What you do on a weekly basis, the entire core team 20 or 30 people come into a physical room. And on the physical room on the left side, you see the performance. The performance role is extremely relevant. There you show impact. In mortgages, you might expect market share, you might expect true impact, impact on customer, customer satisfaction, basically what you want to see. That's impact. Then you go to the portfolio wall on the other side, discussing basically what are we doing in terms of our epics in order to improve on what we do there? You initiate basically your design thinking flow because you have to define there what you want to redesign. And then that leads into some action boards that's just for managers who also need to do something. They get the impediments that they can clean out. And this basically this turnaround then takes place. And what I like best in large organizations like ING, we do that on a cascaded thing. Because if there are impediments that we can't resolve, we go one level up. And the overall performance of our entire board on the lower level becomes one line or one chart in the one level up. So you get this cascaded point of view. And if you do it nicely, and that's what we are trying to do now, we'll basically see that you can do that in a couple of hours. So from 9 to 10, all tribes have their independent OBEA session. Then from 10 to 1030, all the impediments and the progress and the reports are brought up. And for example, from 11 to 12, we as a management team, as a board of the bank have then our OBEA session. And all the impediments are resolved. And before it's lunch, hopefully the organization knows how we basically took the decisions and where we help the organization to mature. So a long story short, I think that ING has done a lot to improve its way of working, doing the things right. Agile has helped us tremendously. In order to become Agile, we focus on continuous delivery. We focused on basically the Spotify governance model. We've introduced real, real talent model that's all to become Agile. And then we understood that, you know, you might be doing the wrong things very right. That's not a situation where you want to be in. We have to focus more on doing the right things. And that's for us basically getting a cascaded perspective on how to get strategy down. That's ensuring that whenever you start something new that you apply the design thinking with its four principles in terms of making sure that you do the right things and that is measuring progress, discussing progress and getting the impediments out. That was the discussion for today. But I'm more than hoping to question. I don't know how I'm doing in terms of time, but so let's see. Four more minutes. That's nicely questions. Good.