Podcast Ep. 67: The Nexus Framework for Scaling Scrum with the Scrum.org Team

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, your hosts, Dan Neumann and Sam Falco, will be exploring the Nexus Framework. Joining them is Kurt Bittner and Patricia Kong of Scrum.org. In their roles at Scrum.org, Kurt is the Vice President of Enterprise Solutions and Patricia is the Product Owner of Enterprise Solutions. Together with Dave West, CEO of Scrum.org, they are the co-authors of the book, The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams, which is also the topic of today’s episode.

Together, Kurt and Patricia provide a thorough introduction to the Nexus Framework and deep dive into some of the facets of it. They explain many of the whys and hows around it, debunk some common misconceptions, and share how they resolve some of the common problems that arise.

Listen on Google Play Music


Key Takeaways:

  • What is the Nexus Framework?
    • It aims to address the main problem of how to coordinate across multiple teams delivering one product
    • When you start to scale up the number of teams involved, questions arise, which Nexus helps to address
    • Its main focus is on teams and the products
    • Nexus aims to help the organizational change problem (regardless of the practices being introduced)
    • It helps people apply Scrum in a larger context and addresses scaling-specific issues
  • Can you implement Nexus without Scrum? What happens if you implement the framework without doing Scrum well?
    • There are lots of ways to fall down with Scrum—Nexus won’t make or break it
    • You should learn how to do Scrum well before implementing Nexus
    • If a set of teams isn’t doing Scrum well, there are scaling techniques that you can apply
  • How the Nexus Framework works:
    • Multiple teams work to build one integrated increment at every Sprint (usually three to nine teams)
    • There’s one Product Owner with one product backlog
    • There is a Nexus Sprint backlog, which is a representation otransparency around the dependencies that the teams might face
    • Teams still have their daily Scrums, but there is a Nexus daily Scrum before that so the unit can truly come together, understand the current issues and properly plan ahead
    • There is only one Nexus Sprint review as opposed to the individual Sprint reviews you would see in Scrum (because of the emphasis on the integrated product)
    • After the review, you have the Nexus retrospective where the appropriate people come together to address the current issues and find solutions
    • There is also the Nexus Sprint goal, which is a culmination of what the teams are doing as a Nexus for the Sprint
    • There’s a new role called the Nexus Integration team, which consists of a Product Owner, a Scrum Master and Nexus Integration team members to ensure the integration of the Nexus
  • With no Product Owner hierarchy, how does one Product Owner handle multiple teams vs. single team Scrum?
    • Understanding that they’re not looking for different job titles; it’s about a role with clear communication and autonomy
    • “One Santa, many elves” i.e. there may be one person that is responsible for the product being successful but they can have lots of help
    • Make sure that the teams understand what the goal that is being worked towards is



Mentioned in this Episode


Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]

Intro [00:02]: Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners, man leaders seeking advice to refine the way they work and pave the path to better outcomes.

Dan Neumann [00:11]: Welcome to this episode of the Agile Coaches’ Corner. I’m Dan Neumann.

Sam Falco [00:14]: And I’m Sam Falco. Today we are joined by Kurt Bittner and Patricia Kong from Scrum.org. They are authors of the Nexus Framework for scaling Scrum, continuously delivering an integrated product with multiple Scrum teams. And we’re going to talk about Nexus today. Welcome to the AgileThought Coaches’ Corner podcast.

Kurt Bittner [00:33]: Thanks for inviting us.

Patricia Kong [00:35]: Thanks for having us. That’s a long title for a book, huh?

Dan Neumann [00:38]: It really is. It’s scaled.

Kurt Bittner [00:45]: Scaling. This is about fish, right?

Dan Neumann [00:52]: We could do improv podcasting.

Sam Falco [00:54]: So we’ve been, uh, we’ve been covering on some of our other episodes, some of the other scaling frameworks we’ve, we’ve talked about SAFe, uh, from a perspective of what are the myths around it that were busted by someone who attended the class. We’ve talked about Scrum at scale and how one organization has adopted it. And, um, so we wanted to get a perspective on Nexus. I have implemented it with two different clients, um, and done so pretty successfully. But we wanted to hear from people who were involved in the creation of the course and the, and the book of Why, another scaling framework, why Nexus? What, uh, what is the, the fundamental why behind it?

Kurt Bittner [01:36]: Yeah, I think the, well maybe it’s a preamble to that. Um, I always like to talk about the, the fact that scaling isn’t just one thing and that helps us to, to understand what problem Nexus solves. So when organizations talk about scaling, they often mean a bunch of different things sort of mixed together. Um, so one of the problems basically is, is essentially how to coordinate across multiple teams delivering one product. And that’s the problem that Nexus is trying to solve. Uh, and so we’ll come back and talk more about that. But the other things that sometimes, sometimes people mean by when they talk about scaling has to do with essentially, um, changing an organization’s culture to reflect agile values and, and, and maybe more specifically Scrum values. Um, so that’s sort of a combination education, organizational change problem that may or may not involve the, the, the sort of complex team coordination problem that Nexus solves. Um, that’s important, but that’s outside the scope of what we were trying to accomplish with Nexus. Um, there’s also a problem that we’re working on with evidence based management, which is the other thing that we spend a lot of time on and that’s basically how do you, um, in a sense, um, fund teams to build products. And that’s more of a portfolio management problem. And that’s an important problem too. Um, that’s also not something that Nexus deals with, but um, you’ll see some things coming from Scrum.org, uh, over the next couple of months or so that deal with that particular problem. But, um, so that, that brings us back to the, the Nexus problem. Um, and so you know, your listeners and both of you are, I’m sure, very familiar with the problem that Scrum solves, which is basically one product, one team. And how do you work in an agile way to deliver value to customers with, with one team delivering one product? Um, when you start to scale up the number of teams involved, then people start to run into problems with applying. Just, just Scrum, you know, questions like, you know, do you have, you know, one Product Owner per team, you know, do you have more, you know, one Scrum Master per team? Do you have one Scrum Master for all the teams? Um, how did the teams work together? How do they remove, remove impediments? And so those are the kinds of questions and problems that, um, Nexus is trying to focus on.

Patricia Kong [04:20]: Um, I can add to that, Kurt, cause the, when we were looking at this about the problem, it was even why was there, why did, why was this problem presenting itself to us? So several years ago, um, with Ken Schwaber while we were talking about scaling, uh, we were talking about it because everybody was talking about, and we’re saying, why are people thinking about scaling so much? Right? And, and, and the notion of, you know, getting bigger or something. Um, in terms of, you know, bigger products and those things, they exist, but everybody was talking about scaling and all these different ways and, uh, not really understanding what their definition of scaling was. So the interesting thing there was we were saying, and it’s, you know, Sam, you said that you, you did to the implementations and they, they worked well. It was the notion, can you do that? Can you, you know, people are talking about adding all this overhead, but before you do that, can you actually say, we have a few teams working together, a few Scrum teams working together, and they can actually get some stuff done every sprint, right? And so obviously Ken Schwaber, the co-creator of Scrum said, well, let’s, let’s see what we’ve known to work over the past several, you know, the past two decades that we’ve actually been using Scrum because rarely is Scrum used in only one team. So what were all those things that worked and what did we feel needed to be formalized and prescribed in, um, in a framework? And the other component is that we’re talking about a process, right? An empirical process. But what we wanted to make sure we were preserving were the boundaries of that process, but also the notion of scaling self organization. So when we looked at the, the fractal that we were trying to scale, it was actually this notion of self organization, making sure that we preserve bottom of intelligence, make sure we preserve this notion of team and this identity of the teams and that identity of the Nexus and how could they work together without just adding, um, you know, all this overhead. So what was the minimal that we could put there? And that’s what we felt was really missing, especially when we talk about agile. Right? So, so that’s a, that’s a little bit more history for you there too.

Dan Neumann [06:27]: That’s fantastic. I just wanted to make sure I understood correctly some of the boundaries you put on it. So it was around the teams and the products, but not so much the organizational culture challenges related to scaling. Correct? Okay. And it’s nice to have a boundary for sure.

Kurt Bittner [06:45]: Um, and, and, and some of the reasons for that is, as Trish was saying, we’re trying to help organizations, which are probably, you know, hopefully using Scrum. Well, but, you know, one question is, what if they’re not using Scrum well? You know, could you still use Nexus? So we’ll come back to that later. But, um, you know, organization, you know, let’s say that they’re using Scrum well, they’ve got some experience with it and you know, how do they now tackle a bigger product? So it’s an incremental sort of increase in complexity, um, from the one team. Well you could argue that it’s, it’s a substantially more than incremental, but you know, it’s, it’s, um, the organizational change problem, you know, that that sort of exists regardless what kind of practices you’re introducing. You know, you could be, you know, putting in a new SAP system and you’re going to, going to have that. So, you know, there’s lots of experience in the industry dealing with that at various levels of degrees of success. Um, so we thought, you know, we, we have the most to say and we have some legitimacy around using Scrum. So, you know, how could we help people apply Scrum, but in a slightly larger context?

Sam Falco [08:00]: Sure. Um, that question of, um, using Scrum, well, before you scale, we’ve talked about on the podcast before and, uh, actually it was the very first episode, uh, and I saw, I heard you say that maybe we’d come back to, can you use Nexus without using Scrum well? One of the things that struck me when I read your book when I was preparing to take the certification exam was the, the scenario that was in there with that, those, that was a set of people who already knew Scrum pretty well and were doing it well. And I wondered, well, wouldn’t they have figured out how to scale on their own pretty well because they were already living the Scrum values. So, uh, can you talk a little bit more about that and, and what happens when you have teams that maybe aren’t doing Scrum well and try to implement this, this framework?

Kurt Bittner [08:46]: Right. Well, um, so the, there’s lots of ways that, that people can fall down with Scrum. Nexus isn’t going to sort of help or hurt that it might, it might cause them to learn faster because they now have to deal with a bigger set of problems. Um, so they still have to learn how to do Scrum well. And in the book we decided to simplify the problem and not make the book about doing Scrum well because there are lots of books written about that. Um, and so, you know, we, we simply chose to, to simplify it so we could focus on the scaling specific issues. But if it, if it, if a set of teams aren’t really doing Scrum well there are some scaling techniques that, that you can apply. So you know, having, let’s say one of the teams might be doing well and one of the teams is not doing well, you can start to cross pollinate and learn from each other and use some of the Nexus events to, to foster that learning. Um, but if, let’s say that the, you know, that they don’t have an effective Product Owner, the Product Owner is completely absent and all that, that’s going to be a problem no matter what. So, you know, that’s not that it’ll be exacerbated by the scaling challenge. So we generally try to encourage people to do, you know, first learn how to do Scrum well before you tried to scale it. Um, there’s not, there’s not sort of a shortcut, um, to doing that that says, Oh, you know, if you, if you want to scale, you know, you don’t really have to know how to do Scrum well. It’s like, well, you, you, you do and would be better for you to focus on getting good at Scrum with single team Scrum, learn from that and then, you know, build on that expertise to go forward. So while it’s not impossible to sort of jump straight into something like Nexus without doing it well it’s, you, you’re going to be compounding a bunch of different problems. It’s hard enough as it is without, um, uh, I mean, Scrum is hard enough as it is without compounding it with, with scaling problems. And, and I don’t mean Scrum as hard, um, in terms of being a framework, it’s hard to do well. And that’s one thing Ken said for a long time.

Patricia Kong [11:05]: It’s very much like Scrum, right? So it’s um, I made the, the, the, the as like the long name for the book. We have this long hashtag it’s #scaledScrumisstillScrum. Um, but the, the notion of you know, scaling is going to hurt know why you’re scaling first it’s going to hurt. Um, but it’ll hurt less if you have a strong foundation. Um, and if you’re using Scrum and you’re really trying to, to, to use those events to communicate. Um, so we can communicate about the dependencies we have between each other, how we’re operating, um, as a unit. Those are, those are good things. I think what what becomes interesting is a couple of things is a lot of, um, a lot of implementations I’ve seen is that there are ones where they’re really open to the notion of do we really? Why we’re scaling? Do we need to scale and actually should we descale cause it’s not working. We got too big or we took off more than we can chew. And how do we, how do we articulate those? Because those are actually very challenging issues. As your organizational issues become ego issues, right. Um, but still laying down a framework, right? That’s gonna that’s gonna unmask things. Hopefully. The other part of it is, is that, um, in the software context, they have to have a lot of, um, other practices that they’re assuming, right? That they’re taking on, that they’re learning, um, that can help the teams and a lot of that will hurt even more if you don’t have those great technical practices in places. Um, you know, has Nexus been used for things outside of software. Absolutely. Yes. Um, but one of the things you know otherwise is generally you have to figure out these other practices besides the framework that are really going to help, help make things real. Um, and Ken always talked about that as reification, right? How do you make things real? It’s only, it’s like being proactive by laying down the framework.

Dan Neumann [12:57]: Think it might be helpful is as we’re talking about Nexus, I could imagine somebody who’s listening to this going, okay, I got, I got the name of the framework, but what actually, what are the pieces that Nexus lays on top of the Scrum Framework to, to help people in organizations, you know, foster this learning, create the collaboration, deliver an actual increment during a sprint that involves multiple teams. Could you maybe give us a, a word picture and we’ll make sure to link to the Nexus framework at Scrum.org picture. So maybe it’s when folks are listening to this, they could go back to that nice little reference that shows where the different events are around the Scrum Framework?

Patricia Kong [13:32]: Yes, I’m actually going to grab a picture of it up here for myself. Oh my goodness. Um, but, um, I’m sure that besides the, you know, what’s available on the site if there’s a lot of things now I feel good about this. So obviously when we’re talking about, um, Nexus, what we’re trying to do is we’re working with multiple teams, right? So let’s start with the team. So there’s three to nine, um, Scrum teams working together and we’re still working on just building one product, right? So you have the integrated increment that you’re looking for, um, at least at the end of the sprint. But if you’re talking about one product, that means you have one Product Owner, one product backlog, right? So one Product Owner just like Highlander, um, which gives away my age. What’s interesting here is for the product backlog we have, um, we’re thinking about refinement from, um, how that product backlog as a prescribed event. And the reason is is because we are looking at making sure that we’re trying to pull apart those dependencies as best as we can. So refinement where it’s optional in Scrum, it’s mandatory in the Nexus framework, all right, so we have multiple teams working to build one integrated incremented every sprint, maybe three to nine teams, let’s say. And then you have the same things where if you’re going to be planning, you know, you’re have your team’s planning. Now, here’s the thing is if you have individuals, teams localizing that, that’s not going to give you a bigger picture. So we have a, a Nexus, um, sprint planning before. So there’s this notion that the appropriate people would come together, they’re helping to plan, um, just generally what do they think they could do, go back into their individual teams. So this is notion of Nexus, you know, people from the different teams coming together and then individual team. Now there’s an additional artifact here, which is the Nexus sprint backlogs. And that’s a representation of, you know, the work that we’re pulling for the sprint and what hopefully you have on this is a representation and transparency around the dependencies that we might face in the different teams. Right? So, okay, so we have that, which sounds really similar to Scrum. And the other thing that you have is, you know, teams obviously still have their daily Scrum. Okay. But again, that’s, you know, three to nine teams having individual conversations about what they’re planning for the day. Well, let’s put a Nexus daily Scrum before that so that as a, as a unit we can come together and quickly say, Hey, do we, um, do we have any integration issues, what’s going on? And then use that to drive that information to figure out how we plan for that day. Whether you talk before or even after that, again up to you. But what we prescribe is that you’d need that Nexus daily Scrum to come before how you individually plan, um, for, for the days for the teams. And you have one Nexus sprint review instead of the individuals for reviews that you would see in, um, Instagram because we’re interested in the integrated product. And then, um, you have the Nexus sprint retrospective. So after review your retrospective, um, appropriate people come together to say, Hey, at the Nexus level, we know we face these issues, you know, the Product Owner wasn’t available. Or, um, our cadence seems to be going off or we want to do this or that as a Nexus. Okay, let’s, let’s take those issues. Let’s talk about those in the individual teams. Come up with some recommendations and then come back again, close that loop. Right. So how are we going to adapt? So we inspect, we go into the teams and then we bring up our, um, adaptation and then we talk about those fully again as, as a Nexus. And really the last thing, last few things is obviously there’s the Nexus sprint goal. Um, I would have failed this if I was presenting the Nexus the sprint goal, um, which is the culmination of, of what we’re doing as a Nexus for the sprint. Um, and then, um, we have a new role called the Nexus integration team. So the Nexus integration team, um, Kurt, Kurt can jam about this really well, but, um, I’ll give the basics where it consists of the Product Owner, uh, consists of a Scrum Master and the Nexus integration team members, um, from the individual teams, they’re really accountable for making sure that there’s an integrated increment. They’re probably gonna do that really to help scale, um, different, um, learning points, different skills by acting as coaches. And they’re there to make sure that there’s this integration of the Nexus. So, um, I’ll leave that to, to Kurt because there’s a couple of myths that he can probably dispel quickly.

Kurt Bittner [18:07]: Yeah. The thing that I like to say about the Nexus integration team is that it’s quite possibly the worst thing ever chosen.

Patricia Kong [18:12]: Thank you. Thank you. Thank you.

Kurt Bittner [18:18]: We haven’t come up with a better one, but the, the problems with it are this is that it doesn’t do integration so it’s not, it’s not actually taking all the bits or the things from all the different teams and putting them together and building it and producing the product that that’s a common misconception. And the other thing is that it’s not really a team in the sense that you’re a Scrum team. So it’s, it’s a more, we like to use the analogy that the Nexus integration team is a bit like fire wardens is that the people on the Nexus integration team typically have other jobs most of the time. But when there’s an integration problem between the teams, you know, it’s just like a fire wardens. They’re going to put on their best and help everybody get out of the building safely. The Nexus integration team members then would come together and help the team. So it is possible to have dedicated members on the, on the Nexus integration team, but the most likely cases that is that they’re not there. They’re simply people from the, from the different teams on the Nexus who have an overriding responsibility to make sure that the integrated product gets produced. And so when it doesn’t, then they sort of spring into action, right? But they could, they could have roles on the, on the regular, uh, Scrum teams that are part of the Nexus. And that’s, um, and that’s fine. Um, so it’s, it’s some, it’s, it really depends, you know, whether they’re full time or whether they’re part time or, or virtual really depends on the degree of integration problems that you have. Not, not whether you have the, um, sort of a, a need to have a standing team. Um, and there are a bunch of anti-patterns that sort of form around that where, you know, you could see a Nexus integration team that, that, um, in some organization that consists of, you know, a bunch of managers, that’s not, that’s not a good pattern. Right? That’s a, that’s an anti-pattern um, you know, it’s, it’s also not the build, you know, the build and integration team and it’s not a, you know, some program management committee, um, responsible for bringing things together. It’s really about, you know, uh, having a focal point when things really start to go sideways that you can in a sense, pull it back. Um, but, but they shouldn’t work by sort of jumping in, doing the work. Right. The ideal mode is that they help the teams solve that integration problem themselves and, and, and then get better so that they, the integration problem doesn’t come up again. So if they just jump in a superheroes and solve the problem, then the problem is likely to come up again. So anyway, it’s, it’s really hard to describe what this Nexus integration team is because we don’t really have an analog for it in most other sort of normal daily work. Um, which is why we sometimes use the, the fire fire warden kind of idea, but that’s not quite the essence of it either.

Patricia Kong [21:21]: There’s a, um, and kinda just to add onto it, there’s a fluidity on that membership, right? So to support the Nexus and the Nexus springt goal and you know, the different goals of the organization. Um, the people who are on the Nexus integration team will probably depend on what, what work is coming up or what they’re focused on in their objectives. The, the best that we’ve come up with everything was, you know, um, squeaky clean and it was nice. The, the, the analogy you could have is essentially it’s like a Scrum Master to a Scrum team. So they’re, there like a, I’m the Nexus integration team is helping to exist. Uh, some other people have said, you know what, this is a great way to, um, bring people in. So imagine a Product Owner comes and there’s something going wrong and they can’t talk to a hundred people and 50 people you know all the time consistently. So who could they talk to? The, the next integration team are those members. Right? And that that should have representation from everyone. Um, another way to think of how we could use the Nexus integration team for the Nexus is if we’re working on something, how could we get somebody from, for instance, an outside vendor into our conversation, into our Nexus? Well, there is, you know, there’s a space for them in that Nexus integration team or maybe there’s a team that they become part of the Nexus, then they would still be on that Nexus integration team probably. So it’s always, it’s a great way to always, you know, to, to potentially bring in some people into, into our conversation. Um, working towards the Nexus sprint goal.

Sam Falco [23:02]: So something that you just said brings to mind. Um, does any of the Product Owner having to work with so many people? And so we’ve got three to nine teams and, and we don’t have a Product Owner, a chief Product Owner hierarchy, like, uh, some other scaling frameworks put in. How does, how does one Product Owner handle say nine teams, uh, how, what does it, what does it change about the way the Product Owner works versus single team Scrum?

Patricia Kong [23:30]: So when we talk about, um, we don’t, we don’t, we don’t use that terminology. Um, and we talk about the one Product Owner, right? So as that scales, what we’re looking for is that representation understanding of the Product Owner in those different teams. So there’s obviously, um, delegation that might happen. But what I’ve seen that’s worked really well is the understanding that, you know, what, we’re not looking for different job titles. This is about a role and we’re going to have a clear commute. We’re going to have clear communication about autonomy, right? So if there’s private ownership that’s represented in the different teams, this is where you guys have, you know, this is where the boundaries and please when it comes to these points, let’s have a conversation because I’m accountable for maximizing value of this product, right? So we’re talking about really having a clear understanding of the role rather than cheating things as a job title was still comes into play somehow because now we’re saying, Hey, you know, business analyst, Product Owner, tech, you know, all these different words that that make confusing about what this role, um, is, is about, um, although you know, do what works for you, but it’s this notion of really focusing on accountability, having that autonomy, the um, the communication, delegating that and making sure that that’s understood within the team. So now you have a conversation again about what’s your product, right? So it’s like, you know, having that, if you’re, if you’re able to do that, it becomes easier. It gets harder when it’s not really a Product Owner on the product, but it’s something else. And so, you know, how do we figure out what works best for us there?

Kurt Bittner [25:11]: Well, one of the things that, um, I mean there’s, there’s some patterns for solving that. You know, Product Owner can’t be everywhere. Um, and one of the ones that you probably have heard of is this sort of notion of one Santa’s many elves. Um, it’s not the season for that but, but the idea that, you know, there’s one person who’s responsible for the, the product being successful, but they can have lots of help. So, you know, the people on the, on the Scrum team can take over, um, writing user stories or they can take over talking to stakeholders so they can take over lots of things. It doesn’t mean the product, the Product Owner is still accountable, but just because just because the people on the team take over some of the actual work doesn’t mean that the Product Owner is not accountable. And in fact, sometimes things run better that way. If the Product Owners focused mostly on here’s the goals we need to achieve and here’s how we’re going to measure success on those goals. You guys figured out what the features should be. Right? You know, you, you’re probably closer to the technology than I am. Um, you know, you know, you, you can figure out a cool way to solve that problem better than the Product Owner coming up with, you know, a detailed specification. So mostly it’s, it’s a matter of building trust and competence across that team. So, you know, you might have to, you know, developers, you know, might have to sort of step out of their pure coding role and, and get a little more involved with customers. But, you know, that’s really satisfying. Usually people like that. Um, and they might have to do more with the acceptance testing and they might have to do more of these other things, but they become more, you know, sort of fully skilled, richer, you know, they, they, they acquire a richer set of skills in doing that. And, and generally people regard that as a positive development of not everyone, but, uh, anyway, so, so it’s this notion that, you know, it’s the Product Owner isn’t the one, the sole writer of the requirements, that they’re not the sole, um, you know, conduit for all contact with other external stakeholders. But the team, you know, will step in and take over that if, if they feel like they want to.

Patricia Kong [27:27]: I think there’s a couple of things to support that. So we have in our classic of a skilled professional Scrum class, um, workshop cause you really have to work in invest two days and it allows you to walk through and feel what it’s like to be in a Nexus. So we have a case study and we introduce, um, 60 practices or so, you know, take and choose what works in your context. This is where it works and doesn’t work. So there’s obviously a lot of technical things that you can do with your product to make sure that, you know, you’re, you’re, you’re getting feedback on your product. Um, and that’s helpful for the Product Owner. And then, um, Oh man, I lost the second one. Um, well I guess that that was the more important one though, is really to think about the instrumentation that you need. But um, Oh, I know what it was. Oh no, this is important is to support what Kurt was saying. Um, and we’ve been thinking about this a lot is to really make sure that the teams, um, understand what the goal we’re working toward is. There are so many times or you know, what are you working on? What are you doing? And then you go why? And they’re like, Oh, I don’t know. You know, so, um, making sure the check less right? And so it’s so easy for us to do that sometimes to fall into that and you know, really thinking about that goal and how we work toward it, is is important.

Dan Neumann [28:49]: You had mentioned this, some of the facets are on the product backlog and love that you are emphasizing the Product Owners responsible for ordering that to maximize value. You know, like Scrum and then anybody can contribute product backlog items. I wanted to go then to the other end of the sprint and ask about the sprint review for your three to roughly nine Scrum teams, is that one combined sprint review or do you have a kind of a sprint review sandwich? Much like the retrospective where there’s the Nexus thing, the team things, the Nexus piece again, do you have individual team reviews?

Kurt Bittner [29:21]: One product, one sprint review.

Dan Neumann [29:24]: There can only be one.

Kurt Bittner [29:25]: Yes. We keep seeing seeing that pattern come up.

Patricia Kong [29:29]: And that’s what we mandate, right? If they want to do something else and they think that that is a useful thing to do with their time. Absolutely. But what’s in, we’re looking at the product, we’re looking at that as, as a of um, valuable information feedback.

Kurt Bittner [29:44]: So what, what you’re asking though reminded me of, of something that we talked about in the book and we depicted it in a certain way and some reviewers, you know, sort of pushed back and said, Oh, you know, you’re, you’re, you’re describing the mistakes all, all teams make. And we said yes, and the mistake is that, um, usually what happens is when people start forming a Nexus, you, you start with component teams because that’s where the organization is coming from. Uh, but you very quickly find out that component teams, you end up with a lot of nasty dependencies between them and it’s hard to integrate. And so in the book we describe the, you know, some of the problems of, of having component teams. And when I say component teams, I mean, you know, you’ve got, you know, one team’s responsible for, you know, the overall user stories, but another team’s responsible for the database. And another team responsible for, you know, maybe some sort of, you know, disaster recovery fail over mechanism and another team responsible for security because that’s how they’re organized in the traditional organization. And what, you quickly find this, that, and the reason why the sprint review question brought that up in my mind is that, that that’s, you know, usually when you have component teams you start thinking, well, you know, I can’t, I can’t really review the whole product. I’ve got to review all these individual component pieces in independently. Um, but over time what you want to do as the Nexus matures and the people in it mature their skills and become more cross functional is that you end up moving more towards feature teams or something that’s more customer facing and, and, and in a sense the developers become more full stack developers, you know, where they, they can go in and modify any part of the code. And you know, you need to have a fairly mature unit testing and integration testing framework to actually pull that off. Um, but the, the richness of it is that you eliminate a lot of these cross-team dependencies and by doing that it ends up, um, you know, the, the integration problems are significantly lessened and the, you know, each team member understands more of what the product should do and so you end up with a better, sort of a better balancing of skills. Um, but that, that’s one of the challenges. That’s probably the biggest challenge in my mind that in, in actually adopting Nexus is to move from a component team mentality to a feature team, sort of full stack mentality. Uh, it requires some technical skills but it all, but it requires a different mentality and, and, and more cross functional teams. And so you, you know, but in the book we tried to describe how, how an organization Nexus sort of matures through that what the things that they do to more, uh, feature team oriented. Um, so it’s, it is possible to just get started with Nexus, but if you are organized in terms of feature teams, you’re going to have some fairly predictable integration problems as a result of that. And, and the key thing is that you learn and say, Oh gee, you know, you know, then this won’t work. Actually, you just need to work empirically and learn from your experience. But you’re going to have a few bumps, um, pretty significant significant bumps early on that you’ll have to learn from.

Dan Neumann [33:08]: So thank you so far for the introduction to Nexus and to the deep dive on some of the facets of it. Um, I love that the books, you know, roughly in the neighborhood of 150 pages, it’s not like a 500 page tome where I’ll, I feel like I’ve lost part of my life. So it’s awesome that you guys were concise and it does lead me to wonder though, outside of the boundary of three to nine Scrum teams, if your Nexus has to engage with non Scrum teams, do you address that and how do you provide guidance on kind of outside that three to nine Scrum team constraint?

Kurt Bittner [33:41]: Yeah, um, that’s a good question because almost everyone is going to have that problem. Um, so the, the challenges are really, um, so I’ll, I’ll focus on dependencies on outside teams because there also could be dependence on outside individuals. Like let’s say you need a lawyer to come in and review your, your, you know, um, um, sort of, you know, software agreement or something like that. Um, so in the case of, of outside individual, um, or, or, you know, sort of a very loose coupling where you just need somebody to somebody’s expertise to do it, a small task that the goal really should be to try to reduce wait time. And so, you know, to try to give the outside person or team enough advanced warning, so involving them in the, in the sprint planning to say, Hey, you know, we think we’re going to need you sometime in the next couple of weeks. Um, so that they can then, you know, dial in, you know, to, to daily Scrum meetings to understand, you know, well, we, we, we might need you today, you know, could you be available today. So it’s, it’s really one of, uh, making sure that those people who are supporting the Scrum team, and this worked for Scrum as well, may make sure that the people supporting the Scrum teams essentially have some advanced warning that they might need to get involved and then have some capacity in their schedule to be involved on a somewhat interrupt driven basis. Um, because if you, if you have a Scrum team or an or a Nexus waiting on outside individuals, all work just, you know, grinds to a halt and it’s just not very effective. So, uh, that’s, that’s one. Now, now let’s say that you, you’ve got a big piece of integration work that’s done by an outside contractor or somebody working on more of a waterfall schedule. Um, so what you can do there is you can have periodic synchronization points at basically sprint boundaries. And so the, this, this would also work if you had another Scrum team working on a different cadence from your own Scrum team, then you know, so you can align your work on sprint boundaries. And in the case of a waterfall team, they can still work in a waterfall, but you know, they might need to work in a three month waterfall and you can synchronize them with every three months. And in the meantime you might use some techniques like, um, you know, mocking and stubbing and things like that and, and service virtualization to, to sort of simulate the thing, the components that they’re providing. Usually they’re providing components or, or things or services or things related to that. Um, so, so it gets into some architectural techniques to help you deal with the dependencies and try to minimize that and then aligning it sprint boundaries, um, to, um, you know, to, to provide the integration work. So that’s, um, I look at that as not so much. Uh, it’s not really part of Nexus, but that’s kind of a, uh, a supporting practice, a complimentary practice that can help you deal with that particular problem.

Patricia Kong [36:46]: I think the question also becomes when do you think about, um, should those people be a part of our Nexus? So I was working with the Nexus where they outsourced a lot of their design work and so they were always working on that, trying to catch up. And actually what they did was at the end they’ve, they were saying, you know what, let’s just get some, some, some more staff. And they brought in that capability in house and they absolutely shortened, um, their time. So they, they went from, you know, releasing at best like once or twice a year to, you know, once a sprint, um, at least. And so it was, um, having that capability to do that was because they said, you know what, we’re not really saving money by outsourcing everything, uh, when they count, when they, you know, when they did the math. So, so that was, that was good. So those kinds of questions, you know, that’s what the, that’s what you guys are good at I suppose. Yeah.

Sam Falco [37:42]: Just as Scrum reveals problems and you’re expected to fix them that, that in this case, Nexus revealed a problem and then they fixed it.

Patricia Kong [37:51]: Yeah, yeah. It’s, it doesn’t help you stop thinking.

Dan Neumann [37:59]: And I love the goal of reducing wait times. Like I think if it could be, keep that goal in mind that emphasize a lot of transparency and then forward looking, setting expectations and all that.

Kurt Bittner [38:10]: A little aside on that is that most organizations have their priorities sort of reversed. So they want everybody to be maximally utilized. And you know, if you know anything about queuing theory and all that, then you know, they’re best, basically a formula for maximizing wait time because everybody’s going to be waiting on someone else. Um, so it’s really hard for organizations to wrap their heads around. You need to have some Slack time or some idle time in order to be able to, to deal with an essentially unpredictable demand. And that’s, you know, that’s the essence of what we’re doing with Scrum is we’re working on unpredictable things. And so, um, you know, the idea that you might have to, you know, or perhaps hire another lawyer to deal with the unpredictability of when you’re going to need to do your software licensing agreement, um, you know, it’s going to freak some people out. But the reality is you’ll get much more throughput through the organization and the benefits will, will far outweigh, you know, having to add some additional specialized people. And that’s sometimes that’s just, you know, you have to sort of start measuring things like wait time and then see what the effect of that is to convince yourself that that’s the right thing to do. It’s, it’s a little counterintuitive.

Sam Falco [39:30]: Sure. So one more question that I have is around the size of the Nexus itself. Um, it’s three to nine teams I know. So for example, LeSS has two to 18. So I’m curious about why three and then there’s really not much guidance beyond nine teams. Uh, why was the, where were those decisions made? Can you shed any light on why three to nine is the number.

Patricia Kong [39:58]: Sure. So, um, let’s start here screaming at org. messages don’t scale if you don’t need to. All right. If you have two teams, hopefully you guys can talk together, you know, and, and if you have three, then it starts getting a little bit more complicated. But it’s like when you think about a Scrum team or you know, the number of, um, people doing the work on a Scrum team, you know, it’s like you could just talk to each other. You don’t need to add that overhead yet potentially, right? You find you need to, we find that that starts at three a limitation for that. We see at nine that’s about, I’m trying to match this with the scientific theory of Dunbar’s number, but like a hundred people, right? We’re talking about having connections and being able to talk to each other and seeing that face and you know, um, knowing how to do those things. Now we do have something called Nexus plus, and that is when you are, um, more than nine teams, you’re working on the same product and Nexus plus has looked different, um, in many different places. But that question and that conversation about what are you trying to optimize for becomes very important. So previously we start, we were optimizing. Now let’s say for cost, right? So you, you find some, some really difficult problems and expensive problems to work around. And I would urge people to think about how can you break that down? So I’ve seen Nexus plus descale into a Nexus I’ve seen next to say, you know what? Actually let’s descale into two separate Scrum teams, whatever works for them. But, um, there’s no recipe that we find in Nexus plus, and I don’t, I don’t think we’d be justified. Um, and prescribing one, we know some great that work that we suggest. We certainly talk about that and think about optimization and think about flow and flow of value and flow of work in the course. And we’ll go through those exercises. But there’s, there’s not too much to be said there. We do have, there’s one interesting case study we have on a Nexus plus implementation, but it was our marketing. So it was about how did they have their all working on this marketing campaign, but they’re all working in different geographies. They formed what they felt was right to be a Nexus plus, you know, and so what did that look like? So it’s, it’s, it’s really got to have, again, those clear boundaries. What is that initiative, what does that goal that you’re trying to achieve? Um, and do you need this many people essentially to do it? And sometimes it’s just because we have this many people. That’s why we have to do it this way. But if you’re looking at, you know, from a software product, if you’re looking at your product or platform, all those things, there are some expensive conversations to be had. Um, because it usually is not a scaling problem at that point. It’s a product problem.

Kurt Bittner [42:33]: Right. And a couple of things to add. Um, so a lot of organizations we find actually struggle with defining their products. You know, the product is kind of this, you know, huge grab bag of features that does a little bit for these people, a little bit for those people, a little bit for those people. And it’s rather confused about what it actually, what the product actually is. Um, and it’s usually because they have a kind of a sense of legacy definition of a, of a product. But one thing that that helps with the scaling is if you start looking at groupings of capabilities and people you’re serving, and you could use techniques like personas or pseudo personas to do this and look at the outcomes that you’re delivering, you might find that that, really what you think is a really big complex product, it’s really a bunch of much simpler products that could be dealt with, with, with Nexuses. So although you need to release them at the same time and there’s some coordination that needs to be done, they’re not really a tightly integrated product. So that’s one thing to think about is it, you know, do you have one product or actually many products. Um, and, and in big organizations, especially financial institutions, they use the product, the word product in a, in a very broad sweeping way. Um, the second thing is that usually these scaling problems deal with, um, you end up, um, solving some of the Nexus plus problems with the platform architecture kind of approach. And so, um, you can share architectural components and, and sort of, you know, underlying infrastructure quite a lot. And then that, that is, if that underlying architecture has been in a sense rendered as a set of services, then essentially the, the teams using that can just use it and they don’t really have to do much coordination with the people delivering the platform. So, um, so there’s ways of decoupling both decoupling products and decoupling aspects of the architecture to make this problem easier to solve. And we bundle all of that sort of under the broad heading of Nexus plus, but it’s not a prescriptive methodology. It’s more like a, a set of complimentary practices that may or may not, um, apply depending on an organization situation.

Patricia Kong [44:47]: Yeah, cause I think in the end, a lot of people focus on this notion and even trainers, right? We’re trying to scale the process. We’re trying to scale the rules. No, what we’re trying to scale is self-organization, what needs to surround that to make that happen is a different way to approach how we think about scaling. Um, here. Okay.

Sam Falco [45:06]: Thank you for that. Uh, I think we’re up against the edge of our, uh, our time together. So, um, Dan, do you want to ask the eternal question?

Dan Neumann [45:16]: I will ask the eternal, at least a, we believe it to be eternal. We will see. But, uh, what, uh, what has you, uh, inspired these days? What are you reading as part of your kind of continuous improvement journey? Or maybe you’re writing something that has you inspired? I don’t know that that’s a new twist on the question for you too.

Kurt Bittner [45:34]: Well for me it’s writing. Um, so, uh, and people can, can search on the Scrum.org website for more information about this, but, but we’re working on a thing called evidence based management and we’ve got some new things that have sort of expanding that into a continuous improvement framework. So, um, it relates to how does an organization achieve its goals in a complex environment. And so in some degrees it relates to the scaling problem. Um, so we’re, we’re pulling together a bunch of different, uh, ideas from different places, both Scrum and from outside Scrum. Um, you know, and, and one of the, one of the parts of that is, uh, Mike Rother’s improvement kata, um, work, uh, has influenced me a lot. Um, in that aspect. So that’s, so that, um, looking at measurement, how measurement drives behavioral change and organizational change is really kind of foremost in my mind right now.

Patricia Kong [46:31]: Yeah. We work very closely. Yeah. We work very closely together. So the, um, the writing and the reading, a lot of it is to support this, the new thoughts that we’re putting around evidence based management. Um, really thinking about things systemically and systematically. How do we, how do we really improve? What measurements make sense? A lot of this starts to touch, Oh, what can we, what can we see and what can we actually do and remove this notion of, you know, our culture doesn’t support that we don’t have the right people. And then so you know, those, that means we’re, we’re researching leadership and culture and um, I don’t think I even told Kurt this. A lot of this, you know, with people talking about systems thinking and all that stuff. It’s a, when you have something that’s been put up in place and the people who have created and benefited from it, when you think about that they are the best people to tear that down and dismantle it. Now that works. When we think about you know, society and the different systems and the different structures that we have there and that looking at how that applies to organizations, um, there’s a lot to be thought about there.

Dan Neumann [47:37]: Super cool. Well we’ll look forward to that when it uh, when it emerges. Thank you a ton for joining us and sharing on the Nexus framework and uh, you know, some of the why’s and the hows around it. Really appreciate you guys taking time out of your day to do that.

Kurt Bittner [47:53]: Thanks for having us.

Outro [47:56]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date