 So, my name is Geronimo. I work with Scrandotor as a professional scrim trainer. I have my own company and I've been an agile coach for eight years. So if you want to tweet something about this talk, I would like to ask you to tweet me. And before I completely begin, I want and I need your help, okay? Let me explain you this story. So, at the office in Boston, Scandotor office in Boston, there is a woman. Her name is Patricia, and he took care of all the luncheon of the scale professionals scrim program and everything. So a year ago, I made a bet with her. And you know, Patricia is very fashionable, okay? She's very, very fashionable. She loves fashion, and especially she loves shoes. So a year ago, I made a bet with her that I would be going to conferences and clients all around the world to introduce a scale professional scrim in Nexus. And if I could get enough tweets, she will have to pay dinner for me the next time I'm in Boston. But if I don't get enough tweets, I had to buy her shoes. These guys can tell you that her taste is not cheap. So have you ever seen in Facebook this photo of, help Brian, he has a kind of disease, just press like, and you will help him save his life? Well, that's a scam, this is not, okay? So now you can help someone with doing something online for free. So if you're gonna tweet something about this talk, just please use the hashtag, scale the scrum is still a scrum, okay? And help me win that dinner or at least not have to pay for those shoes. Okay, let's start with the question. Have you ever been engaged in efforts to scale scrum? Raise your hand. So, raise your hand is your organization defines scale as multiple teams working together, working one product. Okay, multiple teams working on their own individual products. That's scaling, okay? Multiple teams working on a suite of integrated products. Okay, or one team working on several teams in parallel. Okay, or the complete IT organization adopting scrum. Okay, so first thing is defining what scaling means for us. We are a scramble tour, we focus this, we divide or we see the organizations in two parts. The part that belongs to organizational development and the part that belongs to product development within that organization. So, a scale scrum focuses on this part, on the product development part. Why? Because there is better frameworks, there is better ideas out there. There is different ideas and we have experience in product development. The scrum has been out there for 21 years and it's proven that it works. There is no end of that. There's a reason 90% of the teams in the world use scrum. So, the definition of a scale scrum is any implementation scrum where multiple scrum teams build one product or a standalone set of product features in one or more sprints. So, if you're working in several products with several teams in parallel, you probably shouldn't use the definition of scale scrum, okay? And the second one is any implementation of scrum, where multiple scrum teams build multiple related product or sets of product features in one or more sprints. This is the scrum DNA, a scrum comes to its core in two parts. The self-organization means autonomy for the teams are letting them decide what they have to do and how they have to do it, okay? And the second part is the empiricism. A scrum is based on empiricism. It's empirical control process. So, basically, if we do something, we get feedback, we decide what we're gonna do next. And we inspect and adapt. The three legs of scrum, and many people don't know this, are transparency, inspection, and adaptation. You need to have these three core things. If you're doing a scrum, I never thought about why the scrum meetings are done that way, why the roles are done that way. They all come down to these three things. Keeping transparency, inspection, and adaptation. So, in a scrum, we have a product backlog, and we have scrum teams. And the scrum teams deliver a done increment at the end of every spring. Okay? How many of your teams deliver a done increment at the end of every spring? So, that's the first point that you should be addressing when using scrum. So, people think it's about the people. It's about doing better retrospectives. It's about having more product owners, or more scrum masters, or more experienced people, but it comes down to that. It comes down to a done increment at the end of every spring. This is the vision that scrum has. There's so, so many books about scrum that talk about different things about scrum. But almost 50 or 60% of the people that come to my classes, they don't remember that one of the main artifacts, one of the three artifacts of scrum is an increment. A done increment at the end of every spring. And some people will say, but it's really difficult for us. We cannot deliver a done increment. Then you have impediments. You remember what is the role of scrum master? What is the responsibility of scrum master? Removing impediments. But you know, as a scrum master, I cannot remove those impediments. Because those impediments belong to the rest of the organization. But that's your responsibility. And this is how scrum improves organizations. Organizations that actually implements scrum and that have scrum teams working and delivering a done increment at the end of every spring experiment, an amazing and incredible increase of their happiness, of their customer value. All the things that you come and hear here to say, to listen to. All the things that you can hear and listen to. You experiment all of that. So these are the consequences to have a good implementation of scrum. Then we come to professional scrum. We as scrum.org, we like to call the scrum we do professional scrum in contrast to mechanical scrum. Mechanical scrum is when you have the role, the artifacts, the meetings, and everything, and you do them. And have you ever been in an organization? Is your organization sometimes asking itself, why we do all these things? Why we do retrospectives? Why we do spring reviews? And that's mechanical scrum. When you just do things and you don't understand what you're doing then. So professional scrum is the scrum mechanics. Plus a technical excellent, plus values and principles. And again, it all comes down to those values and principles that support scrum. Yeah, there is a scrum, okay? And the way we promote scrum as scrum.org is a professional way of doing scrum. That's the reason we call it professional scrum, okay? We want to improve the way people do software development. That's our mission, okay? And we can only do that through professionalism, okay? Sorry, I thought we had, okay. So when it comes down to technical excellence, I remember going to clients, and this happens every time. And when we talk about, what is your delivery pipeline? Can we route your delivery pipeline? And we start with something from the beginning to the end, okay? And we start adding things in the middle. And then when we think we've done, then someone else comes and says, oh, but you forgot that we had to go through this gate. And you forgot that we had to deliver this. And you forgot that we have the engineers that do this and actually deliver the software. And at the end, some organizations look like this. So there's actually little people that know how to deliver things. And then what you know is just the part of your thing, okay? So when you have poorly maintained code bases, then also you have the Medusa effect. Have you ever seen that thing of we have 101 bags? We sold one bag, and now we have 115 bags? So we have one scrum team doing work, okay? And that scrum team comes to the part of the organization. Because they want to do scrum, because the organization wants to do scrum, okay? And we try to solve all the impediments, and we try to improve, and we try to deliver, and we deliver an increment at the end of every sprint. But we get three scrum teams, okay? Thus, those three scrum teams covert the part of the organization. That is now a black box, okay? Things are happening. We don't know what's happening. There is transparency. We can't know how that's happening, okay? But things are just working. And this is the experience that I got with my clients when we implement scrum. Is that, okay, this has been a difficult journey, very difficult journey. But now we get things done very, very easily, and very fast. We deliver, in my last client in Malin that I left just a few weeks ago. We deliver from a feature, from imagining a feature, testing with clients that may be a good feature. They'll implement it, and have it deployed in production. It took us three weeks. Three weeks, and of course it was small company. But I've seen that happening in bigger companies. Companies with 200 people. 200 people that were delivering new features for customers in just a month. And you know what happens then? That the customers stop complaining. That the customer happiness increase. That your team happiness increase. Because let me tell you something about happiness. The best way to increase the happiness of your team is let them do their work. They're engineers. They're business analysts. They're UX people. They're UI. There are a lot of people that form those cross functional teams. And they will be really, really happy and really, really excited when they see that at the end of every spring, what they've done is deployed to production and is ready to deliver to a customer. And no matter how many workshops do you do, how many off sites, how many things you do retrospective, how many Legos do you buy for the retrospectives, that that will be the single thing that will change your organization having a dumb thing at the end of every spring. So we have nine scrum teams doing work. What happens then? That we create a lot of dependencies. You probably have seen that. If you're working with scrum scale, you will find that you have a lot of dependencies among teams, okay? And this is something that we want to address with Nexus. So there's two kind of dependencies or two dimensions of dependencies. The first type of the dependencies are those dimensions. The people, the business domains and requirements, the technology, the software, the infrastructure. These are structure is usually a huge dependency. And these dependencies may happen in the team. And because in a scrum we have self-organizing teams, they solve those dependencies among themselves. So scrum that already solved this. It can happen cross teams and these are more difficult to solve and more difficult to keep track of. And these can be external dependencies. You've probably been in that situation where you want to do something, you have to do something. And then you find out that there is someone else that belongs to the other part of the organization that has to sign something to tell you how you can do it and that dependency. That's something, some work for the scrum master. When I was working at Capital One UK, Capital One is bank. They have, it's a US bank, but they have a subsidiary in the UK. Something funny happened. We created a scrum studio. We hired people to form brands from the scrum studio. And we had two mobile teams. And the thing is the mobile solutions of Capital One had been outsourced to a company outside the bank. And it's taking a year and they haven't delivered anything. Oh well, they deliver 70% of it. And 70% of it, let me tell you, is not done. It's not ready for the customers. So we start working with a scrum, okay? And after three sprints, we have a mobile solution working in both Android and iOS, in a bank, okay? Everything done, ready, okay? You know what happens next. That branding, and the department of branding, there was a department of branding. I didn't know that there was a department of branding. Branding says, well, you cannot deliver that to customers because you haven't gone the branding to diligence, whatever. And we had to solve that. But now they are delivering. And they deliver new features every spring. And I know that because I'm a customer. And I see that every time I open my phone and I open my Capital One bank account. How we deal with dependencies. We deal with them in two ways, proactively, okay? We try to identify them. We try to minimize them. We try to ask people. And by ratification. Ratification means make something real, okay? Bringing something into being or making something concrete. How we do that? Through frequent integration, through acceptance testing, through continual bill and delivery, and minimizing our technical debt. At this point, many of you may think, okay, this sounds great. But my organization, we cannot. I mean, we have a lot of this stuff. And we cannot deal with that. So give me another solution. A couple of days ago, I was talking to some people here in the conference and came to my mind a concept that probably is not new. But it came to my mind the concept of transformation debt. Let me tell you something. I've been in several digital transformations, higher transformations. I have lead them. I participated as a coach. If you at some point don't think, and sometimes is feeling a solution, let's find a solution so we don't have to deal with these things. And you implement a cookbook recipe or something like that. Oh, these guys are doing this, I'm gonna do this. These friends will say this, I'm gonna do that, okay? You will have, you will get to a point. And it will take you probably a year and a half where you're stuck and you cannot do anything else. And that point you will start, you need to start thinking, okay? And take this as a way of, we need to improve this now or we will be paying a high interest later on. Your ability to scale, it's gonna depend on continuously identify and remove dependencies, integrate the work across all levels. So integrating work is not integrating only with your layer or your component. It's integrated from the beginning till the end. And create and inspect verified increments. Nexus. So the definition of Nexus is a connection between something, between people, between things. And when we do scrum for multiple teams, we have a product backlog, we have several teams and those teams are working on their stuff but they are delivering one integrated increment. If a scrum team delivers one-done increment and Nexus delivers one-done increment. So three to nine scrum teams working together deliver a single increment at the end of every spring. We have one product backlog, we have one product owner, we have one vision. I know that there is different frameworks that say, oh, you have to, you need to have different product owners. Also, people scale in a scrum, say if a scrum team is a product owner, a scrum master and a development team, we should have that for every team. Well, definitely you can have people that help the product owner, okay? But you need to have one product owner because when we scale a scrum, we find that we have five product owners or nine product owners, they have different visions. And when you ask them their visions, they will give you 10 answers. So it's one product owner, one product backlog, one product vision. This is the Nexus. Nexus is an exoskeleton from three to nine teams. Does it sound familiar? Does it look familiar? It looks like a scrum because a scale scrum is still a scrum. So when the Nexus came up, the idea was to add the minimum things that you need to scale a scrum. So the same when scrum was presented 21 years ago in 1995, was it didn't tell you about the technical practices that you need to do. It didn't tell you about many things. And many people say, oh, that's not enough. I cannot do that. I need something more complete. And now 19% of the teams in the world, they use scrum. Why? Because it's flexible. This is the minimum set of things that you need to do. And it doesn't change much. We have a product backlog. We have a Nexus spring planning. We have a Nexus spring backlog. We have three to nine scrum teams. And Nexus spring review and integrated increment. Some new elements that you may see, and I will talk about them, is the Nexus integration team and the Nexus daily scrum. But the rest, you already know them because you're already using scrum. So when you have two teams that are using scrum, that are delivering a don't increment at the end of every spring, using Nexus is just a breeze. So you can scale up to five teams to six teams as long as you are continuously integrating, okay? You cannot add all the teams together the first day. But the whole Nexus will tell you when you can add teams. Are we delivering a don't increment? It's working software. Then we can add more teams. Do you think, yeah. Well, the Nexus spring planning has two parts, okay? The first part is where the product owners, scrum master and appropriate representatives from the team meet. And they see how much from the product backlog which team take. Will each team take, okay? And the second part is all teams gather independently, okay? And they find any problems, any dependencies. They do their breakdown if they want to. And then there is a meeting at the end of the Nexus spring planning where the appropriate representatives from the team meet again with the product owner, scrum master. And they see if there are new dependencies that will affect the Nexus spring goal. So the answer is you can do it that way. You can gather 90 people in a room and you will have to have facilitation skills. Or you can do it the other way. We don't tell you how to do it. We tell you that you have to take care of seeing which part of the backlog each team work on. And make sure that the teams see that, work on that, find out what they're gonna do about it, okay? And then you identify any new dependencies that happen. So there's two ways. The first way is the refinement. So by the moment that you get to the Nexus spring planning and refining is now part of the Nexus, okay? So scrum told you that you had to have a refined backlog but there was not a meeting for refinement as such. And in Nexus, there is a meeting for refinement. So the first thing is that the teams will have worked with the part of the backlog before the Nexus spring planning. So they will have an idea of what's coming, okay? And the second way is gathering the appropriate representatives from the team and these are how to be together, okay? And the Nexus spring planning needs to happen in the same day, at the same time. Doesn't have to happen at the same place, okay? But you need to gather all the representatives from the team so they all know what all the teams are doing, okay? And any problems appear before going into the spring, okay? Any dependencies? Does that answer your question? So do you think the scrum is not enough? So one of the things that we heard is that the scrum works for single teams, for single teams. And that scrum is not enough scale. Now we need to use all the things to scale. We wonder if scrum through the Nexus is still a scrum and if the Nexus officially a scale. The Nexus augments a scrum, okay? It takes the scrum that you already have that is working and then it augments it and it makes it possible to scale using just the scrum, okay? So we use the same values and principles and definitely if you have scrum working, you will have the Nexus working because when something is not solved in the Nexus, it will come down to scrum. When I deliver the Nexus classes, the SPS classes, the scale professional scrum classes, people ask me, but this is not in the Nexus guide. So I have this question that is not in the Nexus guide. Well, when it's not in the Nexus guide, then a scrum applies and this is what it is. Oh, but there is no answer for my particular question. Yeah, because the world is diverse and organizations are diverse and they have different problems and they face different problems and each organization is unique. And let me ask you a question. Do you have a competitor? Can you think of a competitor of your company, okay? That is in the same industry, okay? And roughly the same size of you, okay? Do you think they do things exactly the way you do it? They probably do things in a different way, day to day. Then why would you want to use the same recipe they're using? It's like using the recipe for making a main course to prepare a dessert. Maybe you are a dessert and they are main course, but they are both Indian food, okay? I don't know if this is, does that understood? Did I explain myself? These are the Nexus roles, events and artifacts. So we have three roles that we already know, the development team, the product owner and the scrum master and we have one new role, the Nexus integration team. The Nexus integration team is a team that may be virtual or maybe a real team. When I say virtual, it's maybe a team that forms from members of different teams within the Nexus or maybe a real team and the fine team, you have a big Nexus and it's accountable for integration. They are accountable to make integration happen and to deliver a done increment at the end of the Nexus spring. Does that mean that they have to do the work themselves? Well, no, they couldn't do the work for all the teams, but they are still accountable. What a paradox. So the paradox here is the Nexus integration team needs to work to make sure that integration happened and they have to use different skills and facilitation skills and training skills and coaching skills and keep an eye on dependencies and make sure that things happen. Well, that's difficult to understand and I see that. How many of you had trouble to understand the role of a scrum master the first time you heard about it? And the first time I heard about scrum master, I thought, well, this guy's a project manager and then I thought he was like a product manager and then I thought he was like the people's boss and it took me a long time until I really came to understand because when you introduce something that is new that no one has heard of before is difficult to understand. But I say, give it a try. They banned, we have the spring, we have the Nexus spring planning, we have the spring planning for the teams that happens just after the Nexus spring planning. We have the Nexus daily scrum that happens just before the team's daily scrum. So in the Nexus daily scrum, appropriate representatives from the team meet together with scrum master and product owner and they identify what we did yesterday towards the spring goal and we, what dependencies did you have? Oh, we have dependencies with the team three on five. Why? Because we're working in the same piece of code. Oh, we need to solve this. And then those representatives come back to their daily scrums and they say, oh, we've been in the Nexus daily scrum. We need to solve this now because we're blocking team three and five. And we're gonna work together with them. It's all about collaboration. We have our Nexus spring review where we show a done increment for the Nexus. We don't show independent pieces. We show a done increment. There is challenges. The challenges are, oh, how we do a Nexus spring review if I have 90 people or if I have two Nexus, I have 180 people. How do I Nexus spring review? Well, that comes to the practices that you use. The Nexus doesn't tell you which practices you have to use. And let me stop here a bit. Nexus is a framework to scale a scrum. It's an exoskeleton to scale a scrum. And a scrum.org, we have a scale professional scrum. So the Nexus is free. You can go and download the guide and try the Nexus and find some practices that we already published and try to work out your way on the Nexus. And if you want, you can come to scale professional scrum and learn about practices for the Nexus. But these two are two complete independent things. That's the reason the scrum is so successful because scrum was not the son of Jeff Sutherland and Ken Schwabber. And they tried to sell it through their own company. No, they gave it to the world. And again, scrum.org and Ken Schwabber, they're giving Nexus to the world. And you can use Nexus tomorrow without having to attend anything. And you will have to find out your way through the practices. We have a new artifact, and this is the Nexus spring backlog. The Nexus spring backlog is just a reflection of all the teams spring backlog together. So you can keep track of dependencies and what's happening about the Nexus integration team. This is scrum team. If they're not doing or they're not facilitating integration work, they still pull work from the backlog. This is not a team of bosses. It's very easy to think, oh, Nexus integration team is the project manager and the product manager and the chief architect and whatever. No, this is a team that has to facilitate integration and sometimes will be those people and sometimes will be someone else. Sometimes you will have dependencies problems and sometimes what you just mean and say, oh, everything is going great. We're keeping track. We're transparent. Things are going great. We don't need to do anything. The Nexus interconnects three to nine scrum teams and exhibits scrum principles and DNA. Yeah, what does it say that they have to be full-time? So if you, what the scrum guy says usually about this and I don't know it's actually wording, but it's better to have full-time people, okay? And it will affect your productivity if you don't have full-time people. But it doesn't tell you you have to have this or that or you should or you must. I've seen many scrum teams that were sharing people across and they shared people across because they needed to because they have a person who had a single skill and it was an important point to deliver a product, to deliver an increment. What happens if you have a DBA in one team and you have three teams and then another team faces a DBA problem? What you do, you hire three DBAs, you hire three mainframe engineers, you cannot hire everyone for every team. But they expected, who said that they expected? No, doesn't say that. Doesn't say that, doesn't say that. So the thing is, but even if you say that or doesn't say that, let's have some common sense. They're expected. Someone say they have to be full-time. Yeah, it increases productivity. It helps a lot. It helps a lot that they are full-time, that you don't share them across teams. And it helps with the team formation. It helps that to build identity within the team. That's, I agree with that, do those ones. But don't follow things lightly. If you have again a DBA and you need a DBA helping another team, what do you do? You hire another DBA. DBAs are expected to work across. So, and who else is expected to be full-time? Don't take this the bad way, okay, what I'm gonna say. But I came with an exception and I can came with another 24th section in the next 10 minutes, okay? Because I have experience. And what I'm saying is that there is no release of roles that are expected to be full-time and a role that are exceptions. It's about delivering and on increment. It's about collaboration. Yeah, it's a guideline. Yeah, definitely. It's a practice. It's a practice. Again, our vision is that these are practices, learn of them, read of them, practice them, put them in practice. And if they were for you, keep them. But build your own practices. And what we're saying here is that members can be full or part-time. Yeah, definitely. And you can change composition between spring because your integration needs will be different in two sprints that they are now. How you can build a team, a Nexus integration team, that is gonna cover all your integration problems forever. That doesn't make any sense. So what can happen is that in retrospective, you find that on next spring, we have DBA things. We need a DBA in the Nexus integration team. We need database things and we need a DBA in the Nexus integration team. And then that DBA incorporates itself to the Nexus integration team, to solve dependencies, okay? To help solve dependencies. And at the end of the spring it's a, oh, our database problems, they're done. So that person can go. So what we're saying is, be flexible with your Nexus integration team so they can incorporate members and lead members. How you can... Okay, so the only meeting that a developer may need to attend that is new for him, okay? So this is, you remember, spring planning one and two from the scrum guide? Spring planning one, spring planning two. So it's the same. You got the Nexus daily scrum, so as a representative of the team, yes, you may need to attend to your Nexus daily scrum. May take 15 to 30 minutes because there is no times preset for the Nexus, okay? And you will still have your spring review. And if you're part of the Nexus integration team, you may need to attend the meeting before to identify dependencies and solve problems, okay? And again, with the retrospective. But that is an hour and a half more for one person of the team. Just to avoid, do you imagine the cost of not delivering? So when you have five teams and each of those teams cost you $100,000 every spring. And you're not delivering. It's like, your hour and a half may help the company solve and get value from those $500,000. And about the meetings in scrum, I always hear that. We attend so many meetings and we have these refining meetings and we have this thing. And I lost my presentation, don't know why. Yeah, there's no power here. Okay, let's hope that it comes back, okay? So people, oh, I got it myself. So it's my fault. People say, we have to attend to so many meetings. How many meetings that you do at value? In organization that I was product owner of, okay? I took over from the previous product owner. And the first thing I did was eliminate all the meetings. You know what happened? Nothing, nothing. Because sometimes you're not meeting. Sometimes you're fulfilling other people's time. If you are not fit toward today, if you're not able to work today, yes, set a meeting. Then everybody will know that you've been there in the office and you've been doing something productive. Okay, so scrum meetings, they are enough. I know that they could be less, okay? And you can reduce them. We have had spring reviews that take 30 minutes. Retrospective that I've seen 20 minutes. Without facilitation, the team just gather together, say we have a problem with this, we have a problem with this member. And maybe they did two retrospectives in a row of 20 minutes and then they needed a retrospective of two hours. And they came and said, we need a retrospective of two hours now because we have a problem on the team. So don't stick yourself. And the scrum guide, what the scrum guide tells you is you should, in a general way, you should use, you could use, sorry, not shoot, you could use 10% of your springtime for refinement. And sometimes you will need 10% of the team and the other springtime for refinement and sometimes you could do the refinement within the spring planning. Of course, if you're breaking every single task that you're gonna do in a spring before the spring planning, you need a lot of time. But sometimes time will be better spent, working instead of breaking things down. But if you do that, then maybe someone is out of a job. Yeah. I see that. That happens a lot with scrum. Yeah. The next spring is three weeks. Can you refresh the question? Because I think I didn't get it. Sorry. Okay. Okay. We are almost done and I still have 20 slides. So that, I would love to answer that question in the scrum.org booth that is over there. So please come and talk to me or Steve or Dave. They will be happy to answer any questions. But I would love to finish my presentation. Sorry. So managing a scale scrum. Some questions when managing any scaling effort about the processes and about the cost. We introduce some scale professionals from practices. And again, is this is Nexus and these are the practices that we recommend for the Nexus. But if you are smart enough and you want to come with some new practices for the Nexus and write 10 books about that, you are very welcome. You don't need to go to scrum.org. Just write a book about your practices for the Nexus and we will love to read it. Because Nexus is about going and trying it. And yeah, I'm sorry. We have no cookbook. But this is about becoming a cook, not to follow a cookbook. Some dependence, some practices for dependencies, some practices for ratification. That you can see probably will put the presentation online. But these are pretty standard practices. Automatization, test driving development, frequent builds, frequent testing. And if you're interested in learning more about these practices within the Nexus, we also will hold an SPS workshop on Saturday and Sunday. So Steve will be delivering Sunday and Monday. And if you're interested, you can go to the workshop. That's not the point of the talk, but go to the booth and talk. And we dedicate two days, two practices to scale the scrum with the Nexus. Some of them are practices like this scaling. Some organizations just need to scale. So when you're not able to deliver, adding more people to produce more code is not gonna help you deliver better. That's something that anyone can think of. If you're not able to deliver to you a don't increment to your customer, this don't add more people. A scramble is a practice where you get to a point where your productivity goes down. And some companies need this. Some companies need to stop. I had a client that was in this situation and he's like, well, we're not able to deliver our software. They were doing management software for tribal agencies and stuff. But what we will do is to have some people trying to make it happen and then the rest of the people will keep doing stuff. Yeah, that's gonna be bigger. So you should stop doing it. Yeah, but what I'm gonna do with 180 people that have no work? Well, they can train themselves. They can go home. It's gonna be a, you can take them for a ride in a bus, whatever. But they should stop and they should be ready to help the people that is trying to deliver your software. And once you solve it, this you continue. Because we get to think that, oh, this is a problem. We will solve it and then the problem is bigger. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. That's the way you measure velocity in a scramb. You don't measure velocity through story points. You don't measure velocity through gummy bears. You measure velocity by the lever software to your customer. So if you're not delivering software to your customer, your velocity is zero. And that's a reality that many organizations think, oh, that's not more story points. Yes, multiply the story points for 10, by 10. Nexus Plus. So, yeah. It's a piece of? A speed of the team. So, the speed of the team. Yeah, that's the thing. Yeah, that's exactly what I said. So Nexus Plus. So let's say that you have more than nine teams and then you need to deliver. Then you can use the Nexus Plus. My recommendation is that you shouldn't use it. Because the bigger, the more difficult to deliver. And 90 people trying to deliver software is a lot of people and they can do a lot. But when you add another Nexus, then you can use the Nexus Plus and you can add three to nine Nexus, managing in one Nexus Plus to deliver one product. No, there's no recipe of this scale. Your organization is unique. It's already unique when you put 90 people to work together. Okay, but at that stage, seriously, it's not going to help you. Any book, anything that we do, there's a lot of professionals around the door thinking and sharing a lot of experiences. I work with organizations with 1,300 engineers working together in three products. And that recipe, what we did there, don't apply anywhere else. That was their recipe. And in Nexus Plus, you have to take a lot of care of integration. And that will be a lot of effort. And the more you add, the higher the cost. It's a rule. And it increments exponentially. It's not linear. You will have to address organizational and architecture adequate into the complexity. Developing software is a complex thing. So when people come to comparisons to a factory, a factory is not developing software. So the right analogy for that will be if we build a factory that builds one screw every time. So we do the complete thing one time. So software is complex and you should be addressing what it is. Close him. This is a phrase from Scrum Editor. This future state of Scrum will no longer be called Scrum. What we know called Scrum will have become the norm. And organizations have reinvented themselves around it. This is from Gunter. He's our chauffeur for our professional Scrum series. This is me. If you want to know more about me, you can ask me. And scale professional by Scrum. There is a workshop on Sunday and Monday. If you're interested, you can go to the booth and ask. If you want a poster of Nexus, you can go and get one at the booth and you can connect with us. And thank you very much for your time.