 My name's Kurt Bittner. I work at Scrum.org. I've got a couple of colleagues here who have been wearing the software in 30-day shirts. He probably have talked to them. What I thought would be interesting today is to talk about something that I don't see too many people talking about. So hopefully it's an interesting topic. And that is that there's actually two different, when people talk about scaling Agile, they actually need a couple of different things. And I find it's useful to tease those things out and treat them as if they're separate. Because they're actually, you take different approaches depending on these two different dimensions. And so when we talk about scaling Agile, we mean actually a couple of, specifically a couple of different things. One is that, and usually when people talk about scaling Agile, and you might have been in here listening to the talk about less earlier today. So things like less, and I'll talk a little bit about Nexus, which is Scrum.org's approach to scaling vertically. What that means is basically you're dealing with large complex products trying to coordinate multiple teams to deliver a single product to a set of customers. And so that's what I call vertical scaling, because you're dealing with more complexity. But there's another kind of scaling that we'll talk about in a moment. But in vertical scaling, some of the challenges are just trying to get a common definition of what that product is, trying to get everybody to agree, getting everybody to work off a common backlog in a way that allows them to do useful work, to share work across teams, to get adequate velocity and adequate productivity out of those teams. So that sometimes involves sharing a common code base. Usually if it's a single product, single code base, could be just trying to get that increment tested and delivered. So there's a bunch of challenges related to that that have particular solutions. But when people talk about scaling agile to an enterprise, there's certainly an aspect of vertical scaling. But not everybody in an enterprise is working on the same product. So there's some other things that you need to do to try to get consistency across that entire enterprise. So that's what I refer to as horizontal scaling. In other words, you're trying to get breadth across the organization. So you might have lots of agile teams, some of which organized working on a single product. And some of them are just working on something small and simple. And you need consistency between most teams as well. And so that horizontal scaling has some different concerns. And it's basically doing things like trying to build the agile skills across the whole organization. By the way, I'll share the slides. They're available on the conference site. You're free to take pictures as well if you like. But ensuring that everybody, when you talk about agile, when you talk about scrum, does everybody mean the same thing? Do you call it? I mean, this is trivial, maybe, but do you call it a daily standup, or is it a daily scrum? Do you answer three questions, or do you talk about the things that you're doing and the things you might need help on? There's no right answer to that, in a sense. It's what you agree on. But it ought to be consistent across the organization so that one person can maybe lead one scrum team and go join another scrum team and not have to go relearn everything. Expanding the agile culture into the business, into legal, into other parts of the organization so that they can effectively support the agile teams. Things like adapting funding and governance models so that they don't not just get in the way, but actually, in a lot of times, sabotage the agile team's work and then being able to form new teams quickly. So these concerns, in a sense, are the foundation. I think of these as foundational. You really can't scale vertically unless you can do these things horizontally. Now you can do it in pockets, and we'll talk a little bit about how that works. So I'm going to sort of tear these apart a little bit and talk about what kinds of things you can do to effectively horizontally scale and then talk about some different approaches for vertical scaling. So if you want to think about this in a kind of Venn diagram sense is that vertical scaling is a subset of horizontal scaling. It's got all the aspects of horizontal, but it's also got some extra additional things. And depending on what you're doing, vertical scaling may be more important. If you're building a big complex product, vertical scaling is really important. And if you're the only team in the organization or the only group of teams in the organization doing that, then you may encompass all the horizontal scaling within you. But generally speaking, most organizations have the mix of both. So normally, you probably can't read that quote. Normally I don't focus on the quotes, but I think this one's an interesting one. So this is a Buckminster Fuller quote. And he says that you can never change things by fighting reality. To change something, you build a new model that makes the existing model obsolete. And in a sense, that's what we're talking about with horizontal scaling. We're trying to figure out a way, how can we make agile work in our organization, not by adapting agile to the way that our organization works today, but by creating a kind of little safe pocket for that agile to exist within the organization and then gradually expanding that. So the change in focus, it's worth talking about why organizations are adopting agile practices to begin with. And so there's been this shift that's going on from being very company-centric, being very focused on basically the hierarchy, how am I going to move up the organization, how do we get consistency and control and processes, to focusing on what do customers need and what do we need to do as an organization to serve those customers better. So it's a kind of moving from an inside out to an outside in perspective. And the reason why that's important is because a lot of organizations adopt agile practices to get a more customer-centric focus on their products. And so to do that, it really ships the way that the organization works. So John Cotter is a professor at Harvard and talks a lot about organizational change. This isn't unique to agile, but the observation that he's made in the broader business community is that the structures and the way that we manage traditionally are over a century old. And they date back to the late 1800s. So it's really, in a sense, how can we use 19th century management practices to essentially serve 21st century customers? We really can't do that. So the reason why people need to think and act differently is because, and Jess Humboldt had some great comments about this this morning, is that we really don't understand customers very well. We have a lot of theories about what might work. We actually need to build things, deliver it to them, measure the result, and then see whether are we building the right thing? Are we satisfying their concerns? So agile software delivery is a mechanism for doing that for digital products. And increasingly, it's being applied to other areas as well. So it can be applied to traditional product development. But I'll focus on the software piece. So one of the reasons why agile works better than traditional is that the traditional organization is hierarchical. So when you have this person here, if they want to talk to this person over here, or this team needs to talk to this team, you have to kind of go up the hierarchies and down to navigate that. You might have to get permission to make a change. You've got these well-defined areas of responsibility that you can't cross over. But everybody's got to work together to get something to a customer. In an agile model, it's really a network model. So you've got centers that deliver value to customers, and then people who, in a sense, orbit around that. So keep that in mind. You can think about the structure of the organization being more or less inverted. So the traditional organization, CEO at the top, down through line employees, and finally, you get customers. Line employees deal with customers. But in a more digital organization, you basically have customers everywhere. CEOs talk to customers. Customers support people talk to customers. People building product talk to customers. The products themselves are a major conduit for talking to customers. So to deal with this, we have to have a different kind of organizational structure, and that's where agile comes in. The problem is that we have organizational cultures that are really based around that 19th, early 20th century model. And Peter Drucker here says that culture eats strategy for breakfast, and we can modify that and say that culture eats agile for breakfast. So when you're thinking about adopting agile practices in an organization, you almost have to think about the organization being like an organism. And the agile practices coming in are treated as an invading antibody. And the organization's immune system, in a sense, unwittingly, often, just attacks that invading thing. It says, no, that's not the way we work. We work in this other way. So in a sense, the secret to horizontal scaling is to, for at least some part of the organization, suppress that immune system and allow agile to sort of take root. And I don't want to say that agile's an infection, but it's kind of like, it's a virus, certainly, and it changes the way that the company works. So the way that I've seen this work is that you've got this agile team and it's trying to do its work, and it's got its task boards, and it's got its plans, and it's doing its daily scrums, and it's really working well. But there's all sorts of things in the organization that are kind of trying to tear that apart. And it's just the way that the organization works. It's not an intentional attempt to sabotage. Sometimes it is, but often it's not intentional. But you've got things like, let's see if this will work here. If the organization has a project model, people tend to be spread across multiple projects simultaneously. Well, what does that do to an agile team? It basically causes the agile team to stop. If you've got a critical team member who's working on something and they're not doing something else, you're stuck until they get back. And so we've got to help that team deal with the resource sharing problem. If you've got project-based governance models, they might say, great, you're working in an agile way, let's see your milestones. And we're gonna have regular reviews and milestones. And you try to explain to them that we don't do that. And they might say, where's the project plan? We don't have a project plan. And so you have to have a way of sort of suspending that kind of stopping that immune reaction and saying, okay, there's a different way to governance, that's okay. And we're gonna work that way. You know, there might be initiatives that are focused primarily on cost reduction that might be manifest themselves in terms of we've got to keep everybody's utilization really high. Well, what happens when you, you know, if you read things like any of the lean flow kind of materials, you understand what happens when you have high utilization on a machine is that you queue up behind it. So if you've got mismatched rates of utilization, then you end up with queuing, which translates in people terms as waiting. Process standardization, you know, that sort of defeats self-organizing teams who wanna make decisions to improve the way that they work. That may not be the way that everybody else works. And so these various outside forces and there's lots of other ones that they cause the teams to slide backwards. So many, many times we'll see organizations where, you know, team will adopt scrum for a while and things are going great. And then things change a little bit. Somebody earlier today mentioned the effect of a leader, you know, leaves, moves, gets promoted, something else. That protective environment, you know, gets stripped away from the scrum team and all of a sudden they start sliding backwards. And two years after the initial adoption in introduction of scrum, they're back to doing something that's more looking like waterfall. Maybe it's water scrum fall or maybe it's not even that good. So these various forces pull teams off into sort of back into the old behaviors and we wanna try to prevent that. So, Ken Schwabers talked about this in the Sovereign 30 Days book where he talked about this concept called scrum studio which I don't know if that's the best name in the world but it's this idea that you wanna set up a kind of little sort of microclimate or a little environment in which the scrum team can work and it's sort of protected from the outside. So we've drawn this as, you know, think of this as kind of an amoeba that it's got an outside, you know, cellular, you know, sort of the cellular membrane and within it, you know, there are various product teams. And so the cellular membrane protects that scrum environment, if you will, the team environment from the rest of the organization. It sort of suspends the rules for that. And the intent is that it supports these values of, you know, building commitment to each other, to working together in a better way, building trust in that team, having transparency with not only your fellow team members but the business and the product owner and really any kind of stakeholders and important thing is using inspection and adaption. So these various values within the environment are the things that shape the behaviors of the environment and the things like, you know, we've got to have high utilization, that gets suspended for these people. They're not measured on utilization. They're measured on, did you deliver customer value? You know, and the question is, you know, it's not, are you on schedule and on budget but are the things that you're doing are useful? So in order to do that, this sort of management leadership has to kind of establish this sort of protective environment around these teams. And so there's not, you know, this, they said the studio concept is really a concept. It's not, there's not a process. There's not a bunch of roles. If you think about a role, the main role is management. It's got to provide this protective environment you could think about as, you know, providing air cover for the teams if you want to use a more military analogy. But the purpose of that is to nurture that innovation and also though to remove common impediments and provide common services to the team because each team doesn't need to invent, you know, reinvent continuous integration, for example. So if we think about this, there's a couple of different services that the traditional organization has to do to provide that supportive environment. And so one of them is basically, think about it as leadership services and, you know, things like acting as servant leaders for the agile teams. Instead of telling the teams what to do, you, you know, help ask them, is there anything I can do to help you become better at what you're doing? It may be areas like portfolio management and funding, providing a clean flow of work into the teams so that they don't have these sort of start and stop gaps. Or probably more importantly on funding is that, that you've got a small, a stream of relatively small chunks of work moving through the system instead of big, huge chunks of work that are, you know, year-sized. So that helps, you know, it's essentially feeding the teams with work, helping them develop skills, you know, basically providing a different kind of governance model that satisfies the needs of regulations and other kinds of internal controls, but doesn't subject them to the usual, you know, sort of monthly status review kind of thing because there are other better mechanisms for doing that. The second thing that ends up being important is providing some kind of engineering services to the team. So if you think about, you know, you're working on a scrum team, you're trying to get backlog items done, you're trying to deliver value out to customers. If you don't have a good continuous integration environment already set up, you're gonna, that's gonna stall you out and you're not going to be able to deliver value as quickly. So, you know, not every team has to figure that out separately. So having a common sort of CI environment or at least a common way of teams getting to that. If they wanna provide their own, if they wanna go use something in the cloud, you know, you circle CI or Travis or something else, you know, maybe that's an option for them, but not having to basically reinvent the wheel every time. API management and test, well, let me talk about API management first, is that there's lots of things, you know, there have been a number of talks today about the importance and sometimes not importance of APIs, but one of the things that APIs do is that it insulates you from the internals of what's inside that component or inside that service. But one of the things that becomes difficult over time is that if you, especially if you're using microservices, is that you end up with a lot of APIs and you don't know which ones, which ones are the right ones to use. If I need to talk to somebody about it, who owns it, you know, and so just having an API management strategy in place is one of the things that helps remove frictions for the teams. Even if they're just developing one product and you've got four or five teams, you end up having to have some kind of API management strategy and then some kind of test automation infrastructure, whether it's having a way to run automated API tests, I don't so much mean things like selenium and UI-based testing. Here I mean mostly, you know, driving it off test harnesses and being able to integrate that into the continuous integration infrastructure. So that's another set of services the organization can provide to this sort of studio or to this agile environment. And then the other piece is that it's really, so in theory, every team should be able to kind of decide how they're going to report out. But when you start getting multiple teams in the organization, it gets confusing for stakeholders if everybody's reporting in a different way. And so having, being able to come to some kind of agreement on how you're going to provide transparency into what's being worked on. And it might be, you know, if everybody's just using sticky notes on a task board and working that way, it might simply be that, you know, we're gonna essentially take periodic snapshots of that and post it on a, you know, in a Wiki page or something. It doesn't have to be incredibly complicated, but it does have to be consistent so that the stakeholders don't have to go to a bunch of different places to find out what the status is. And then there's a problem of shared services that basically surfaces. There's lots of different things that the team can't do for itself. In some organizations, this might be changing databases in other organizations that might be the actual pushing of things into production. And so having a way that basically supports the services that the Agile teams need that may potentially also be used by non-Agile teams, and doing that in such a way that it doesn't stall the Agile team out. So, you know, the worst thing that can happen here is, for example, I was working with an organization and the teams had just started using Scrum and that's great, and they're starting to make progress, and then they needed to basically create some new databases so that they could store information persistently. Well, that had to be done, you know, the organization had adopted Idle, so it had to be done through submitting a ticket, and the average queue time on getting a ticket responded to was 20 business days. Getting a test environment was 60 business days. So, the main goal for shared services is don't make the teams wait. Figure out a way that they can either self-service or that you basically have resources available, people available that can meet their needs when they need it so that they're not waiting. But anyway, the reason why I bring these things up is that these are things the organization has to do for the Agile teams in order to make them really effective. And so if you're talking to a leader in an organization and they really, for some reason, want to adopt these practices, then you have to say, well, then your commitment has to be, how are you going to answer these things? How are you going to support the teams? Because if you don't, these teams will fail, guaranteed. They'll end up finally just giving up because they run into so many roadblocks and so many different barriers that they simply can't be successful. So, one of the first things that you can do to help a team is to help them figure out, and here when I say team, I mean, including the business, why do you want to adopt something like Scrum? Is it because you're threatened by some sort of external commercial threat by competitors or are you in a relatively safe industry? Or you basically don't have a very good idea what customers need, so you need to do more exploration of different alternatives or it's totally predictable. We know exactly what they need. Is your bias towards efficiency, towards reducing cost, or is it towards innovating? And these things are sort of at opposite ends of the spectrum and what you find is that the closer you are to the edge on this kind of diagram, the more basically susceptible you are or the more attuned you are to using an agile approach. But if you say, let's say take your typical mainframe application, maybe it's relatively safe. You don't have like a general ledger or an MRP system. It's not the things that our customer are facing. You want predictability, the requirements are stable. You want a deliberate low cost. The decision-making tends to be more top-down and again, you want to reduce cost. So that's a bad choice. But if you're dealing with essentially some sort of digital initiative, it's almost always pegged on the outside of this where the management can't make decisions. They have to work bottom up. They're focused on growing revenue. They're threatening the market. They've got to explore because it's totally new functionality and innovation. So you can use this model to try to figure out why does agile tend to be used in sort of digital initiatives and why does it often struggle in a sort of back-office kind of application? And it's basically because the overall drivers behind it are more aligned with the back-office is basically doesn't really take advantage of agile. And agile isn't, the number of people today have said, working with agile processes is not about being efficient. It's not efficient. It's about inspecting and adapting because you have uncertainty about either what you're building or how you're building it or some other aspect of things. And that uncertainty, because of that, you need to have frequent feedback. And so that's a way to think about this. So another thing that can help agile teams is that they struggle sometimes with some of the technical excellence factors. And so this starts off with things like continuous integration, might be test automation, test harnesses. Sometimes it's architecture and refactoring. So not everybody has all the skills that they need. And so sometimes it helps to have somebody come into the team, become part of the team for a couple of sprints and help them deal with these things. And overall, then that effective is reducing technical debt. But if you've got a team that doesn't have the right skills, then you need to help them. And sometimes that means adding some other people to the team temporarily. So those are some of the examples, maybe helping them establish continuous integration environment. Not everybody does that. If somebody really wants to spend their free time investigating it, that's great, but oftentimes they're too busy. And so it never gets implemented because people don't have time. Or they don't get effective test automation because they don't have time. They need some help in getting over that. The other thing, and I'm sort of cherry picking a few different topics on this horizontal scaling to give you an idea how these things work, is that it's really important to connect people across teams so that they can share knowledge and experiences and learn from each other. And so the community of practice model or if you read a lot about Spotify, they've got tribes and these different kinds of guilds and things like that. But the community of practice model is a way for people to basically get together outside of their normal teaming environment and say, hey, I found this great CI tool and it's really helping me and I've got some things set up on it. If anybody else is interested, I'm happy to spend time and share it. Or it might be, Steve and I do something similar for our own community around different things. So we ran across a really interesting forecasting tool recently that helps include statistical probabilities in the forecast so you can get a better sense for not just what data are you potentially going to be able to ship this functionality, but what's your probability of shipping? It's like, well, we don't have a, our chances are slim to none based on, let's say the probability distribution. It's not zero, but it's, so sharing information across this community ends up being really an important way to grow people. It's sort of, you can grow people within the team by pairing and by doing other things, but this is across teams. And so this is one thing I've noticed that people struggle with, organizations struggle with, is that they'll get these pockets of good agile practices, but they don't really have an effective way to grow that and they can't really rotate people through teams, but communities provide a reasonable way for them to do that. If you take it to its extreme, you can do things like even having peer coaching and career development discussions within that. So, it sounds like an oxymoron, but it's not, there's this concept called Agile HR, which basically is more where you rely more upon peer networks to help do career advising instead of the traditional manager approach, which if you just have your own manager giving you career advice, that might be great for his or her personal experience, but if that's not the area that you're interested in, it doesn't help you very much. And so communities of practice can help people grow. So the communities could be things like developers, could be scrum masters, could be product owners, could be even business people. In organizations where we've seen the business start to really embrace fast delivery cycles and inspecting and adapting, then the business people get together and say, hey, how can we get better at getting customer feedback? And utilize maybe some of the concepts out of things like Lean Startup and Lean UX and other kinds of books that give you, basically it's not really a technical perspective on something like Scrum or Agile, it's a business perspective on it, using that faster delivery cycle to get better information about what customers really need. So, the typical horizontal scaling challenges that I've seen is that you can push teams too early. This is the classic case where a manager or a leader goes to a conference, maybe not like this because you're all practitioners, but they go to some business conference, they see Eric Reeves up talking about Lean Startup and goes, yeah, we gotta do Agile. And they come back and they try to push it down from the top and all of our teams are gonna be Agile, but they don't really fit that sort of Pentagon characteristics that I displayed earlier. And so, it falters because the teams don't really want to do Agile, it's being pushed on them. So ideally you want teams to self-organize around adopting Agile. And you also want really to get them to have some mastery of the engineering practices. So if you've got a team and they, let's say it's a mainframe team and they've not delivered working software in years, somebody else's job, that's gonna be new to them. They're gonna struggle with that a bit. So you have to figure out ways that you can support them to get past that. So pushing change on teams were not really changed and pushing change without investing in growing skills. So one of the anti-patterns and Scott sort of touched upon this in his talk earlier, that it's not sufficient to send one person in a team off to a two-day Scrum Master class and expect them to be a change agent for that whole team, right? I mean, they have a rudimentary understanding of Scrum and its basic practices and principles. But if they've never done it before, they're gonna be learning too. And if they're trying to teach a bunch of other people who can't even spell Scrum in a sense, then they're gonna struggle. So having everybody have a baseline of understanding about what this means, what the commitments to each other mean, how to self-organize, these are all fairly complex things. They take a while to do. And so organizations who really want the results of getting fast delivery cycles and that feedback loop going, need to invest in building the skills of their people. And it's not just one person, don't put it all in the Scrum Master's head. Even if they were totally awesome, God-like in their capabilities, and they're still going to struggle with having the rest of the team hold along. And then the top down, and one of the things that I wrote this in my notebook a couple of days ago, and it struck me that a lot of organizations basically use a waterfall adoption practice to adopt Agile. They set forth the plan, they're gonna have milestones, they're gonna train a certain number of teams, they're gonna have regular reviews, and you say, wait a minute. If Agile is so great for delivering products, why can't we use it to do, to adapt it to our organization too? And so, you know, that's, so if you see, a few of you laugh because you've been through, I've been through that too. And so it really has to, you know, we have to inspect and adapt and everything, not just product delivery, but our whole way of approaching change. So that scaling horizontally gave you some ideas, some of the practices. I love this quote, good judgment comes from experience, most of which comes from bad judgment, right? Resonate. So scaling vertically. What I'm gonna do here is talk about Nexus, which is our approach for scaling vertically, but if you were in the talk earlier with Baz, the less is very similar, there are other approaches very similar. So I'm just trying to give you an idea of the kinds of things that you need to do to scale vertically, not trying to give you the sales pitch on Nexus. But it's the thing I'm familiar with, so it's easier for me to talk about. So if you think about, the problem with scaling vertically is cross team dependencies. If everybody was working on independent stuff, then there's no problem. You know, you just have this nice, linear, you know, improvements and I picked story points. I mean, you could use whatever measure of progress you want to use there. And, you know, it's gonna be nice and somewhat linear, but the problem is, is you add teams, you know, you go, okay, so this is going pretty well. Two teams doing pretty well. Three teams, not so bad. Oops, you know, added four and five teams. And productivity, you know, went down. And you notice this, is that actually we're, it's not that it's slowed down, it actually degraded. You know, we're getting less good than we were before. And it's because the teams are basically, to put it in a simple way, they're stepping on each other. They're getting in each other's way. They're delaying each other. They're people waiting on other people. Maybe somebody's rushing ahead and so I'm just gonna go, I'm gonna go work on this product backlog item. And I know that it's got a dependency here, but we'll sort that out later. And everything that they did on that was just waste. And so that's not very good. So another way of visualizing this is that you've got all these communication dependencies between teams and the more teams you add, you know, this goes up basically exponentially, right? So the communication complexity goes up exponentially. The teams only go up linearly. And so that's why productivity drops off. So there's one thing you can do though, before you assume that you have to scale vertically, is that there are ways of refactoring products so that you don't have to scale vertically. And so, you know, here's an example. Most products that I've looked at over a longer time than I would probably like to admit are really kind of complex messes of functionality that serve multiple people. You know, they've got a little bit for everybody built into it. And just think about something like Microsoft Word and what percentage of functionality of Word you use. But if you asked a bunch of other people, you might find they use a different percentage. And so one of the things that you can do is if you can use user experience modeling techniques like Personas to sort of identify, well, who are we serving and what are they doing? What value are they getting out of the application or the product and say, well, let's refactor that into separate products that are Persona specific. And if we do that, then maybe, you know, these two teams can work on this Persona. And that's a good thing because they start to develop empathy with the customer. They learn more about the users. They become more expert on that. So this kind of refactoring is a good thing. You end up with a bunch of more independent products that don't have the dependencies. And then you basically have, in a sense, feature teams. I've just organized the feature teams here around Personas. And then everybody operating off a common code base. You can eliminate a lot of the complexity without having to use the vertical scaling techniques that I'll talk about. So, you know, things like Nexus then, there's one product backlog for the whole product. One product owner for the whole product. There's a group sprint planning exercise where the group goes through and figures out what are we going to deliver in the next sprint? And then each team breaks that down and says, what does this mean to us individually? And that may have some back and forth. But generally speaking, you break that down. Each team then produces their own sprint backlogs and you have an overall sprint backlog for the entire product for the sprint. And then you go through the usual sprint cycle. You've got a daily scrum for the whole Nexus and then you've got a daily scrum for each team. And the daily scrum for the Nexus is basically an optional event. You know, if there's nothing to discuss, you go, hey, is there anything to discuss today? Nope, okay, we're good. Or it might be that, hey, you know, I've really got this problem with this thing that you're building and I'm not clear on how we're going to work together on that. Can we just get some people from your team and my team to work together on that and they resolve it? So it's really kind of a quick check-in on how the teams are going to work together that day. There's a thing called the Nexus integration team, which in many cases is just a virtual team of team members from the various scrum teams in the Nexus. And it's really there to just say, you know, if things really hit the fan and they're not working, do we have a way, do we have some people who are accountable for making sure that we get back on track? Because if we leave it open, if we just say, ah, you know, we're just going to collaborate between teams and kind of figure this out, that's not quite focused enough. And it might be that, you know, collectively the people on the Nexus integration team, which I think, you know, Steve and I have talked about this is like really bad phrase because in a sense, they're neither a team, they don't produce product backlog items that go into the product, but they don't develop product backlog items and they don't do integration. They're not the integration, the people who did integration for the Nexus. It's really more like it's a good analogy. It's like they're the community of firewardens where if there's a fire, they're going to get everybody out of the building or, you know, something analogous to that anyway. So then there's a sprint review for the entire product. The integrated increment, there's one thing that gets produced. You don't have a separate product for each team and then you've got a retrospective for the whole Nexus and then individually. And we happen to do it in three parts because you say, you know, what are our issues for the group? Then, you know, each team goes off and says, what are our issues individually? And sometimes you find out things there that have to be filtered back up to the group. And then, you know, the cycle repeats. So the reasons for doing this is that it's, you know, it's just scrum really with a couple of additional control points added. Not, you know, nothing really complicated. We're not trying to solve the portfolio problem. We're not trying to solve the HR problem. We're not trying to solve the, you know, system architect problem. We're just trying to say, okay, what does scrum look like for that team? And, you know, the advantage is that if you're already filled in with your scrum, it's pretty easy to adopt and you don't have a lot of overhead. Doesn't cover, you know, Scott talked about a lot of great things this morning with dad doesn't cover those things. This is really just focused on vertical scaling, pure and simple. But, and I kind of talked about these already. I'll put through those. And so the biggest problem is, you know, too many cross-team dependencies. So, you know, if you can't do refinement on that backlog to break it down, to minimize the dependencies and then sequence them over the course of the sprints, you'll struggle. So that's one of the reasons why we have some of those events like sprint planning to do that. But refinement ends up being continuous. Inability to balance work across teams, you know, usually caused by lumpy skills, which is usually a symptom of component teams versus feature teams, but it may be due to some other things. Like there's a really, you know, you're doing Hadoop and there's only one person in the whole Nexus who really knows Hadoop and they're, you know, you can't really, you know, you need to basically maybe use pairing or some other technique to get more people. And then, you know, external dependencies or other kinds of limitations are always a problem. And that's really more back to the horizontal scaling difficulties. So, you know, product owner being too busy, also a big problem. But as you get more and more teams, the product owner can interact with all teams. And so they might have to delegate. They might have to bring in subject matter experts or have other people. But, you know, we don't say that there has to be a hierarchy of product owners and, you know, one for each team, et cetera, that, you know, because that doesn't always, you know, it may be true for some products and not for others. So we try to keep it relatively open. But, you know, so you can see the kind of things that you need to deal with vertical scaling, regardless whether you're using Nexus or less or some other framework. It's basically, you know, how do you break down the work? How do you have teams be able to self-organize to do that work and minimize cross-team dependencies while you're doing that? So, couple things. So, horizontal and vertical scaling are generally both important. Horizontal scaling ends up, you know, the irony is that most of the time when people talk about scaling, as I said earlier, they mean vertical scaling. And horizontal scaling actually ends up being more important to solve that cultural problem because it's going to be removing those impediments that are going to drag people back into the existing behaviors. So, you know, horizontal scaling you can think of as providing a nurturing environment for agile practices, making it less risky for team members to do what they need to do. And then vertical scaling is really dealing with it's kind of a workflow management across multiple teams, but keeping the aspect of self-organization so that you don't lose that benefit. So, vertical scaling usually builds on horizontal scaling. You sort of jump straight into vertical scaling, you'll end up having to solve a lot of the vertical, a lot of the horizontal scaling problems anyway. So, with that little plug there's nexus guides that available on scrum.org resources, nexus guide. But the main thing I want you to take away or hope that you take away is this difference between horizontal and vertical, how that might influence your strategies for adoption, what the leaders in your organization need to do, especially in horizontal scaling, to help the teams be more productive and to be aware of the fact that the rest of the organization, they're not intentionally trying to hurt scrum or hurt agile, but they don't really know better. And so, it's really up to leaders, and this is why leadership ends up being hugely important. It's up to the leaders to provide that safe environment and provide those various kinds of services in support of the teams that are adopting agile. But that, I think we're on time, but I'm around for questions if you have any questions. Otherwise, thank you, you have questions. Yeah, yeah, so I don't know if you heard the question, but basically, I'll summarize it, and you can tell me if I got it right. The teams are sort of gravitating toward kind of many waterfall approach where they do requirements analysis, design, implementation, test in a sprint, right? And so, the problem with that is really that the velocity of that team will be really low because they're sort of single-threading through that. And if different team members are able to work on different product backlog items all simultaneously and collaborate, you'll get much more work through, much more throughput through. The team will be more cohesive, it will be more effective. And so, you can almost answer the question in terms of, it's just not a very effective way to work. You get a little bit of benefit by having a smaller batch size and more frequent feedback, but you don't get very much feedback on very much functionality because of that. It's very constrained with that single-threading through analysis, design, implementation, test. And so, I would just say that your overall results would not be very, you would not get feedback on very much fast enough to really make a difference in terms of the overall end result. So, I would just maybe challenge the team to say, could we try working on a different dissident in a different way for a sprint and say, let's not do strict analysis design, but let's try to maybe interleave those activities more so that we can get basically more feedback on a bigger chunk of the product. Yeah. Yeah. Well, so the difference there is that sprint planning is really on the what to do and not so much the how to do it. The how to do it is going to be the team working day by day on, as they execute the sprint. So, you're not planning out every single day's worth of activity when you do sprint planning, you're really saying, what product backlog are we going to work on? And we're basically saying, that's what we're gonna work on and as we do the work, we're going to figure out how to balance the workout. So, that's the purpose of, in a sense, the daily scrum is to say, okay, what are we working on today? Do we need to work a different way to get this done? And so, you're planning how to do it in a much more interactive as needed basis. And so, that may be the other piece that was missing for them. Anyway, thank you very much. I hope this was useful.