 Is this not working? Yes? I was just thinking that this is... It doesn't work very well. This is my third time talking at the... Change it a bit. Third time talking at the Agile Singapore conference. And people still show up. It's quite amazing. So I'm going to talk about... Let me put this a bit higher. I think it sounds good. Is that better or worse? Better. So I'm going to talk about this before that. A couple of simple things. I'm going to pass an iPad around. Please don't take it. It has a spreadsheet. You can put your email in there. And then you'll be sent the presentation and some other stuff if you want to. If you don't want this, pass it along, please. A bit of other things because I always forget this. I'll do it before I actually start. So there's a bunch of courses in Singapore, Melbourne and Tokyo. And I'm also doing one last Scrum course. I rarely do those here in Singapore. There. Now with that, back to the real talk. This is the agenda for this talk. I'm actually going to start off talking a little bit about Scrum. Very little bit about Scrum. Then I'm going to talk a little bit about less. The kind of boring part. And then I'm going to talk about how less has been created. So Scrum. When most people think about Scrum, they think about the Scrum flow. People always associate sort of this or a variant of this picture with Scrum. And it is definitely true. Scrum is a perspective of Scrum. But at least to me, it's the least interesting perspective of Scrum. In this perspective, it only describes meetings and roles and artifacts, but it's kind of missing out the essence of Scrum. So there's different perspectives that you can have on Scrum. And this picture, much better, in my opinion, describes what Scrum is in the previous picture. So Scrum is essentially about teams that we set free, that are self-managing and self-organizing. And the teams are cross-functional and they iteratively, incrementally build up products. Which much better reflects Scrum than this picture, but unfortunately, if you see this picture, nobody goes like, ah, Scrum. This is another perspective of Scrum, which is the one we don't want to talk about too much, which is the structural impact, where it typically means abandoning functional departments in organizations and creating cross-functional departments. This is too uncomfortable. Therefore, this perspective of Scrum is usually kind of forgotten or not talked about too much. But for me, the key of Scrum is really, really simple, which is this idea where we gather a bunch of people together, who together have enough skills to build a product. And we give them a goal and a time, and they go and work for that time on that goal, and then they build something. And then after they build something in that short time, they show that to an actual user, somebody who wants it, and they get feedback. And then they think about how they worked for that short time, and based on all that input, we take another fixed time, and we give them another goal, and they'll expend on that. And that's basically it. That essence of Scrum is actually lost in this kind of pictures, which is completely missing the actual point of Scrum. So when we talk about scaling Scrum to multiple teams, then we don't really want to scale that perspective, or we need to, but it's not the interesting part. The interesting part is how can we get this perspective, this perspective of giving teams goals within time, and they're building slices of product? How can we get that with multiple teams? So less is similar. We got the similar flow picture, which kind of looks like this, and if you go to the left side, this is the first picture you'll see, that is less like the Scrum flow picture in Scrum. And this is what often people want to know, and it is the most copied picture, although it's missing some of the essences. But let me run through it really quick to give you the overview of the less flow. So in less, there's only one product owner, and only one product backlog, no matter how many teams. We do not want teams having their own product owner and their own product backlog. We consider that a horrible mistake. Then, each of the teams, they work within the same sprint. They start off with sprint planning, which the first part is shared across the teams, which each of the teams picks the work they will work on the next sprint. Sprint planning, too, is usually individual, although teams that closely work together often do that together. Then during the sprint, they build the product, and the teams do their own coordination and integration during the sprint. There are no separate roles or events for coordinating between teams. Therefore, at the end of the one sprint, there's one shippable product, which is the output of multiple teams, and we'll have one shared sprint review because we have only one product where we get feedback on that product. We have an individual retrospective per team where they improve and look back on the previous sprint, and then less actually adds only one event to scrum, which is the overall retrospective, where the product owner management scrum masters and some team representatives talk about systemic and organizational problems, the really hard problems in large-scale adoption. That's about it. That's about all there is to say to the less framework, so thank you very much for coming. The rest of this talk is a little bit different and not focused so much on the framework itself but more on how and why it got created. The origin of this talk is in the previous Agile Singapore conference, which is two years ago. Was anyone there listening to my talk? Wow, and you came back. Thank you. It's actually the talk is online, but I thought it was pretty good. So it was basically just a framework introduction, a bit longer version of what I just said. I thought it was pretty good, and then a colleague of mine, Louis from China, he invited me to talk at the AHA conference, or I should pronounce it like... Here's the... my colleague is the official conference pronouncer. So I said, sure, I'd like to do that. And he said, what are you going to talk about? And I said, I'll just do the same talk as I did in Singapore. I have the slides anyway that will be easy. And he looked at me and he said, but that talk was boring. And I said, what do you mean it's boring? So I said, no, no, it's not you. It's just that every talk about a framework must be boring. And I took that as a huge challenge. So I decided to completely get rid of it and think about a completely different way of doing the talk. And therefore that's the talk you're listening to now. This is the interesting talk. And one of the things that I asked was, what makes things interesting? And one of the things that makes talks interesting in my experience is stories. So therefore the rest of this talk is going to be only a story about how less got created. Because there's much more essence to that than that flow picture, which is kind of the result of that. So but I'd like to start off by sharing a story about my son because people will work with me, know that I always share stories about my son because we have lots of discussions, always, of conversations. So this is my son exactly the same. And as you can see, he loves Star Wars. You guys want to see Rogue One? Yeah. So we have lots of conversations. And one day the following conversation happened when we were driving back from his swimming lessons. So we're sitting in a car and we're stuck in traffic. In Singapore that actually doesn't happen that often. But we're stuck in traffic and he gets annoyed. He's in the back of the car and he says, Papa, I want to go faster. And I said to him, well, that's nice, but we're not going to go any faster because there's all these cars in front of us and we're stuck. So he got more annoyed and then he saw the cars on the opposite side of the road and he pointed to them and he said, but they are going faster. And I said, yeah, they're going faster, but they are going in the wrong direction. We have a choice here and that is we can go really fast in the wrong direction or we can go a little bit slower in the right direction. What do you want to do? So he looked at me and he said, I want to go really fast in the wrong direction. And at that point I thought it was just funny and we didn't turn around, although we did get lost once because he was sitting in the back of the car and he said, I want to be lost. We didn't turn around. But the next day I was thinking about this short story and suddenly realized that this kind of the summary of my life, my professional life, he said when I work with large companies, most of them are obsessed about going faster in the wrong direction. The company that I work with now, and I'm not going to name that one, a new lean program and the slogan of their lean program is higher productivity. And all the people who know anything about lean, they're going like, huh, that's interesting as a lean program. So you see these productivity programs come and go every two years and you learn to ignore them. But that's not what we want and that's not the goal. So the goal in less is definitely not more productivity or hyperproductive teams or things like that, but we want to focus on going in the right direction, on learning, on agility and flexibility, the things that in our opinion really matter. With that, the story of less. So the story of less actually starts in a company that now seems to have quite a bad name called Nokia. And I still work with Nokia for after 15 years or so, but not with the phone site, which is now or what's called Microsoft and now has been sold again, I believe. But with the network site that built network equipment like this one and the company is now called Nokia, surprisingly. You use their products probably nearly every day, but you don't know, except when you start looking at roofs. So this is, the picture here is a four generation LTE base station and that's one of the products I've been involved with for the last eight years or so. But it didn't start with that product. Instead, it started about, the story of less starts a bit, let's see. Not yet. So the story of less starts a little bit of, over a decade ago, when I was living in China, I've lived in China for five years, and I had the opportunity to introduce agile iterative development in all of Nokia networks. The only thing that I needed to do is move to Finland. I already said yes before they told me I needed to move to Finland. Later I realized that was a mistake and if you leave with one lesson from this talk, let it be, don't live in Finland. It's very cold over there. So we started doing agile iterative development in all of Nokia networks because it was this new thing. And one of the things I quickly discovered is that they didn't really know what they were going to do, what they wanted to do. They only knew that we want to do something agile. So the first thing we did was start working with this person, who's a good friend of mine now called Craig Larmond, the co-creator of less. The reason we started working with him was that he had written a book called Agile Iterative Development, a Manager's Guide. Has anyone ever read this? Excellent, one person. It's actually pretty good. It's one of the early agile books that talked about everything agile but then a very little bit. So that was perfect for people who didn't really know what to do yet. So we asked him and we had these large sessions with hundreds of people and we would go in a whole day, we would go over everything agile, all techniques, methods, frameworks, etc. But only a little bit. And afterwards we went to the products and we asked, well, what did you like? What did you want it to do? What would you like to try? And most of the products said, well, this extreme programming thing that you've been talking about, that is a bit too extreme. We don't want to do that. But this scrum thing sounds really easy. So let's do that. So we started working with Kent Schraber. But right from the beginning we had two huge problems. The first one was that Craig had been too successful and we didn't have one product that wanted to try this out but we had like 20 of them and we had in total one and a half coach to support that. Which is kind of tough. And the second one is that scrum at that point was described as this one team framework. And in Nokia Networks there were no one team products. The smallest products had three teams and the large products they don't know how many teams they have. It's just a lot. So therefore the key question was how do we do scrum with multiple teams? And that's kind of the originating question of less. How can we do scrum with multiple teams? Not how can we get multiple scrum teams to actually work together but how can we get the same, remember the same key point, the same effect but not with one team but with multiple teams. So what we started to do is we started to I started working with a couple of these products really close and then the other products we would visit them every now and then and we would just do experiments. We would propose why don't you try out this and I would go and try it out and we would come back a bit later and see whether it worked and what we could learn from that. And because we had 20 products one of the things one of the great things we could do is lots and lots of experiments all at the same time and kind of discard what didn't work and keep what worked. And the the origin of these experiments were our own experience but at this time we also phonetically read everything about existing product development and not the theoretical things but we loved everything that was describing how products were built so the more experience based material. And two books were particularly of a high influence which was the early work from Microsoft so Microsoft at the 90s was really good at building software development. At that time they were. And they wrote two books which are excellent debugging the development process and the dynamics of software development and debugging the development process is written by the lead of the Microsoft Excel project and Dynamics of Software Development the lead of the Visual C++ project. And especially this one talked about two practices that were essential for the first versions of C++ Visual C++ which were feature teams and daily builds. Now daily builds of course had a huge impact on the agile community because they were taken back in extreme programming to practices to the extreme so they took daily builds to the extreme which became continuous integration and now continuous delivery. But especially the feature teams was more interesting and we were ignoring that a little bit in the beginning. But then we were influenced by this obscure paper XP and large distributed software projects by Colson and Anderson which worked in Ericsson and just so you know, Ericsson is like the number one competitor of Nokia at that time. So when your competitor publishes that paper you pay attention. And so they talked about how they, in their flagship product, how they applied daily builds and feature teams. Exactly the same thing. And we read this paper once and we thought it to be uninteresting. And then we read it again and we thought it to be still uninteresting. And after the third time we were like hey, wait a second, they are onto something. This is really, really important. So the thing that they were onto was the structural change of organizing your development from a component team to a feature team organization. Between the two? Some. Let me give you the shortest version of component versus feature team. So most traditional projects or product development, they are organized around components which means that the architectural chart and the sorry, the architectural diagram and the org chart, if they look anything similar, you're using component teams. This is after an obscure paper from 1968 or so by Mel Conway. That's why it's sometimes called Conway's law. He observed that. He also mentioned that it's not necessarily a good idea, but that part is unfortunately forgotten. So to take the simplest component team structure, if you build a web application, you tend to have a front-end team and a back-end team. So your architecture is a front-end and a back-end, so we form the teams around that. So let me do that. Let me get off this awkward stage and put people in teams. So we got here four people. You are now a team. Do you want to be a front-end or a back-end team? Front-end team. Sorry. You guys will be the back-end team now. So, and we need a customer. You look like a wonderful customer. But our customer is a bit annoying because she unfortunately doesn't give front-end features and back-end features. In fact, she doesn't care about whether the features are front-end or back-end. And therefore the features that she gives means changes in both the front-end and the back-end. Now, that doesn't actually matter too much as long as she would make sure that all the features would require an equal amount of front-end work and an equal amount of back-end work, but no. She doesn't do that either. Instead, what she does is she prioritizes features with lots of front-end work first and then the back-end features a lot later. And the effect of that is, of course, we have first of all, we have dependencies between these teams. And originally, I thought dependencies between teams is the key problem for scaling. And I've learned that that is not true, and I was wrong for years. But what happens is what I call asynchronous dependencies between teams. And that is the real problem, because what happens now is that this team will work very hard on front-end features, whereas this team will work very hard on back-end features, but on different ones because of the different prioritization. So therefore, the feature that they work on, the back-end parts, they also need work from that team, but that team is not working on it at the same time because they have more important things to do. So therefore, what happens is that this team they're part of the feature, they integrate it within the codebase and a couple of sprints later, a couple of iterations later, this team will do their part, and they integrate it with the work that that team did a couple months ago. And of course, that doesn't work. So therefore, this team starts interrupting that team, and this team will be annoyed because they're done with that. They're working on something else, right? If they have an over-enthusiastic scrum master, he will kick them out and say, no more kicking. Sorry for that. Does it work again? Good. So, kick them out because it's an interruption. And that would be a really bad scrum master. So, you've got all these conflicts between these teams and these asynchronous dependencies, that is the real problem when you try to scale up and work with multiple teams on the same product. Now, does it work still? So now, the idea of feature teams is basically not to organize your teams around the architecture, but to organize your teams around the value that you're trying to deliver around your customer. So, therefore, making feature teams is really easy. Let me just show you how you do that. Can you guys stand up? No, no, you sit down, please. You two. Two there and two. Can you stand up? Can you sit there? It's permanent. Done. See, it's that easy. As long as they're in the same location, at least. So now, we have two teams, and both the teams have front-end skills and back-end skills. So now, we can take a customer feature and give it to the team and the team will work on this feature and everything that they need to do, they can do it in the team. And when they're done, we can take another feature and give it to this team again. And the same with this team, and there's no more dependencies between the teams whatsoever, except that they still work in the same product. So now, they work in the same code, the same components at the same time. The front-end people there, and the front-end people there are in different teams and will work on the same code at the same time. Now, traditionally, that problem was much harder, but that problem has been solved with agile development techniques. Remember why feature teams and daily builds in the history always came together. There's a reason for that, which is the daily builds and automated tests enabled multiple teams to take a shared code ownership and work on the same components. Now, there's still dependencies between these teams, but these dependencies are very different. They are what I sometimes call synchronous dependencies, and they are good. They're not bad. Because the only time the teams have a dependency with each other is when they, at the same time, make changes in the same code. Because if this team works on a piece of code, one sprint, and that team work on a piece of code, another sprint, there's no dependency. And because they work on the same thing at the same time, therefore, there's no interruption. If that team goes to that team and says, hey, you're working on the same code, and we're making changes there also, then that team won't be interrupted, but they will go like, oh, wow, what are you doing there? Hey, maybe we can use some of the stuff you're doing. So therefore, synchronous dependencies are actually not a bad thing, and they enable this collaboration of multiple teams together. So we started trying out feature teams first in I'm losing it again. I should not move. I should I'm going to talk like this now. So I'm not moving anymore. I can't do that. Anyway, so we tried it out in a product with three teams, and it worked really well, and 10 teams, and it worked really well, and 50 teams, and it still worked really well. In fact, the larger you get, the better it works. For two reasons. First, the component team dependencies become worse and worse the larger you become. Two, because we give the team similar features all the time, therefore they start still specializing at different parts of the system and will be able to talk directly with customers because they speak the same language. So this worked really well. Oh, these are component teams and then these are feature teams. So after living in Finland though for two years, I had enough of that, and I wanted to leave it was too cold, and there's too few people. So I first moved back south to Hangzhou, which was where I was living before, and I joined the management team of this product, which is a third-generation telecom product, and we changed the whole five, 600 people organization to start using what we would now call less. At that time we simply called it large scale scrum. It didn't have any catchy acronym yet. And I did that for a year. We changed the whole organization from component to feature teams. I did amazing things with test automation. And then after a year I moved here to Singapore, where I've now been living for the last eight years, where there's no winters ever. Excellent. Except inside. It's freaking cold here. So and at some point Crack came to me and said, let's write a book. And I didn't know that the answer should be no because writing a book is a real pain. So I said yes and we started writing first only one. Later we ended up with two books. Has anyone read these? For those who didn't they're really good. I'm a bit biased. But what they are is simply catalogs. They were catalogs of experiments. So the first one just said, you know, we tried this in this context and it worked well, but there's no guarantee that it will work for you. Or avoid this. We tried it out. It didn't work, but it might work for you. And the second book we added, what we call the try avoid. And the try avoid was we tried it in this context and it didn't work and we tried it in that context and it did work. Good luck. And the feedback was really positive except for some negative feedback. So we ignored the negative feedback and we called the readers not smart enough to understand our writing till we realized that's not the way to deal with feedback and we started looking at the not so positive feedback and we started recognizing this pattern which was basically thank you for your books now I have 1000 of pages of ideas but not once did you tell us what we should do right? Not once does it say you should start with this. So now I'm stuck. I don't know what to do with all of this. And then we reflected on that a bit and eventually put that in the the Shu there, Shu Ha Ri learning model. Was familiar with Shu Ha Ri? Shu means beginner which means you need to follow rules Ha means expert beginner or beginning expert we kind of learned to break the rules and re-means you kind of make the rules. It's the most simplistic explanation. And we realized that the books we had written were Ha Ri level. They were great for people with already a significant amount of experience because it gave them lots of ideas to try out. But people without a lot of the Shu level people would just at the question how do I scale up agile development. They are lost because there was too much stuff. So what we needed to do was create that starting point. Create rules create prescription. But you know there's a reason why we didn't create it then. And that is we don't like prescription. Because usually if you give people the prescription this is what you should be doing. Then they go and follow that. And they stop thinking. And that's not what we want. Instead we want people to take ownership of what they're doing and think of it themselves. So therefore we don't want to give any prescription or rules. But we have to give prescription of rules because otherwise people don't know where to start. They're kind of stuck. They've got all these ideas and they don't know what to do. But we don't want them to give sorry let me try that again. We don't want to give them prescription or rules because they'll just follow it. And then they don't experiment anymore. But if we don't give them prescription or rules they don't start and they can't even experiment. So we're stuck with this conflict. And suddenly we realize this is solved. And the answer was right in front of us which is Scrum itself. Scrum is extremely prescriptive at times to the point where it becomes boring. Like you need to stand in a circle every day for 15 minutes answer these three questions. It can't get more prescriptive than that. But on the other hand it leaves things completely open. And if you think about Scrum what it's trying to do intentionally or not it's adding prescription around the points where it creates transparency. It's adding prescription around the points where the team gets enough transparency so that they can inspect and adapt. They can take this empirical process control. And we were like that's what we need to do. We need to figure out what are the points where we generate that transparency. We need to add prescription through there and the rest not at all because we want the people to take that ownership and figure out themselves how they should work. We created the less rules which is free pages which is basically the things that you must do when you adopt less. But now we have a problem because we have free pages of rules and 1,000 pages of experiments. And the gap is a little bit too big. So Craig asked do you want to write another book? And now I knew the correct answer so I said no. And he said this one will be quick. We just copy things together and it will be two months. It will be I said okay then the goal would be for me to publish it before my second son was born. The book got published last month. My second son is now three years old. So we kind of missed that line slightly. But the third book which is this one is kind of contains what we call guides. They're in between the here's tons of ideas and these are the things you must do. In fact most of them explain how to adopt these rules in organizations. What effect it would have in your organization. And to complete that we've also added 10 less principles. The only difference between the less principles and most usual principles is that they're added retrospectively. We didn't think what principles are great but we thought what principles have we used over the last 10 years. Which were most influential. And in a moment I'm going to talk about one principle the more with less principle because this is one of the most significant one. And it kind of explains the essence of less. But before that, so this is a whole picture of less we call this the less complete picture. And we originally started with scrum. This talk started with scrum and the different perspectives of scrum. And less is the same. It has all these different perspectives. We started off with the most boring perspective. The deflows of meetings etc. We talked about feature teams versus component teams. Which is the structure. Less talks a lot about how do you structure your development. We talked about the less complete picture the experimentation and the same goal of trying to set teams free. But the last thing I'd like to talk about because he's waving this big sign end. So it must be the last thing. Is the more with less principle. Which is kind of the essence of less. And I always like to start introducing this by this quote. This is a quote from a book called Balancing Agility with Discipline. Has anyone read that? Good. Don't read it. It's an old book and was published by Barry Beam. And that's what makes it interesting. Because Barry Beam has been in the industry forever. And it's probably the inventor of waterfall development. And he writes a book about agile development. Which is what makes it interesting. But when you read it you discover he doesn't really understand it very well. But at some point because of his traditional perspective he comes up with these really insightful points. And this was one of them. Built your method up. Don't tailor it down. What he basically said is that we've been wrong in the industry for a long time. And the thing that we've been wrong is that we create these huge massive processes with multiple layers and many roles. And if we give it to an organization and said here you go, this is the process. But don't worry. You don't need to use all of it. You just need to tailor it down to your product. And he says that doesn't work. And I'll get to in a moment why it doesn't work. And he said instead one of the things we need to learn from agile development is that you want to create that minimum core that you must do. And you give that minimum core and say this is what you must be doing. And if you're in pain and only if you're in true pain you add to that. Now let me go back to the tailoring down why that doesn't work. The reason why it doesn't work is if you think about it pretty obvious because usually you need to tailor down when you start a new product with new people with a new customer etc. So at that point in time you have the absolute minimum information and knowledge. So with what knowledge are you going to make those decisions? You have none. So what happens is that somebody will say look at the big process and will say in our product do we need a release train conductor? Well we're not quite sure maybe. So therefore let's keep it just to play safe. And what happens is all of these products they end up with too much processes roles and artifact. And one of the reasons why they end up with it is because people in organization think that too much processes roles and artifacts is no harm. But that is a mistake. It is very very harmful. Because if you have too much let me start off with roles. If you have too much roles what does it mean? A role means that I take a set of responsibility and give it to a particular person. So therefore if I give that responsibility to one person I will not give it to the team. So therefore more roles leads to less responsible teams. More artifacts tend to be the interface between the team and the customer. So therefore if you add more artifact it leads to less customer interaction. If you add more processes like I mentioned before people are going to follow those yes I know it's the end. People are going to follow those and we get less ownership of the process. So therefore you don't want to have more artifact roles and processes because that will ruin your development. You need to have less artifacts more customer interaction. Less process more ownership and less roles and more responsible teams because with less of that you'll be able to get more output and better product and that's what we mean with more weight less. And that's exactly 40 minutes. So I'm going to end here. Thank you very much. Do we have time for questions? You can take questions. Sure. For less or large scale scrum is this also applicable for an organization that is not practicing ideal scrum? So teams distributed across the globe different time zones and product owners not co-located with their teams? Well unless there wouldn't be product owners there would be only one product owner. So that would definitely need to change. So the short answer is yes and the longer answer is no. Because let me take the simplest one one of the things that less has in the rules says co-located teams. Now that doesn't mean you can't do multi-site development like the product I work with now is I think 30 different sites but each individual team must be on one site. But of course you can just change that anyway and if you do it up less you will it will require in any less adoption that I've seen structural changes to the organization. Without those structural changes you won't be able to it up less if you are making those structural changes you will be able to do that. Does that answer your question? Yeah. So No it's actually the opposite. Component teams lead to duplication and horrible code practices. The reason is that nobody is looking at it. It's like we got our own team and we can make a mess of our own component and nobody will notice it. And this happens all the time because then the people leave. I'm sure all of you have experienced it and somebody looks at the code for the first time and they go like oh no. And a feature team that tends to not happen anymore because somebody looked at it and they go like you know it's really crap. So it's really painful because it exposes these kind of poor development practices throughout the organization really quick. And similarly because we work on the same code we know that that team has already built something. So therefore we take that out and make it reusable. How do? Is there any other interaction between those two teams to say that yeah I know that other team is in the business but will that be missed in a long run? Oh well then the answer is no. Any other question? It won't be missed. It's the amount of interaction between teams tends to make sure. Because what you're looking, what you're really asking is is there a role of an architect in less? And the answer is no. There's no role of an architect that doesn't belong to the team and doesn't write code. It's extremely harmful practice. Does that answer your real question? Thank you. Hi Bask. I had a question. I was looking at the different case studies that you had for less and I was interested in what is the largest I think it's been like the last year or so tracking different case studies and kind of posting them up. What is the largest implementation of less and successful one? What did that require organizationally in order to achieve? The largest case study is my favorite one, which is also from Nokia. Not because I wrote it. I didn't write it. But because the title is your second less huge adoption won't be any easier. So it's actually about two less adoptions. One of five, six hundred person product and one of three thousand person product. And the case study spends ten years. And it's very rare to get case studies that spend ten years. And it's still ongoing. And I made lots and lots the organization completely changed within those times. So yeah, that's the largest one with the most significant amount of change. Does that answer your question? So the we recently had the first less conference in Amsterdam which is a wonderful conference. Yes. Are you speaking next? Oh, okay. Yeah. Last thing. So there were four case studies and one of the things they had in common was all of them removed a layer of management during their less adoption. Every single one of them. Now it doesn't mean you have to do that but that's just the effect of adopting less in those organizations. And now it's really the end. No more questions. We'll ask one more time for a very lively and entertaining talk.