9 keys to understand the Nexus Integration Team

This is a good and helpful article. I suggest that clarification might be needed regarding one point:

"The way the Nexus Integration Team achieves its goals is not by doing actual work but rather facilitating that integration exists across the different Scrum Teams on the Nexus.”

Yet it is also stated that "it may pull and work other Product Backlog Items that are relevant for producing the Increment'.

By my reading of the Nexus Guide, a NIT which doesn't do "actual work" would be a valid and reasonable way of implementing one, but it is not a condition of its operation. In other words, a Nexus Integration Team can pull work from the Product Backlog if doing so would facilitate the integration of work across multiple teams. That work would not necessarily feature in the Sprint Backlog of a member team, and could be the work of the NIT itself.

There is a clear implication in the Nexus Guide that not every NIT member has to be a member of a separate Scrum Team. The advice is that they *may* be on other teams, i.e.:

"Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary. If this is the case, priority must be given to the work for the Nexus Integration Team.”

also:

"If their primary responsibility is satisfied, Nexus Integration Team Members may also work as Development Team members in one or more Scrum Teams."

This suggests that, conversely, members may reasonably belong to the NIT and to no other team, and may draw and action work from the Nexus Sprint Backlog directly. Having a NIT that actions no work is just one valid configuration, even if it is arguably the best one to aim for in most situations.

Ian: I see your point, but what do you propose that work drawn from the Product Backlog (not the Nexus Sprint Backlog) is? What kind of "work"?
One practice we discuss in Scaled Professional Scrum is that of putting infrastructure, operational and architectural work, affecting multiple teams, in the product backlog. This practice, which is nothing but a practice (so you need to think about how this applies to/in your context, if at all), could perhaps hint towards putting some "integration" types of PBIs that the NIT may execute on, in the Product Backlog.
And yes, in short: the NIT can operate in a range of ways, very similar to how an Scrum Master may behave differently depending on the context, such as a team's skills, understanding of Scrum, overall mood, autonomy, ... The same kind of "ScrumAnd", or "different shades of grey", that applies to a Scrum Master, I see applies to the Nexus Integration Team.

How far should a NIT go in order to mitigate integration risk? For example, a poor architecture can make it difficult for teams to integrate their work. Should a NIT address this, such as by performing architectural refactoring? To validate their assumptions, might they implement a PBI which exercises critical paths through the architecture (e.g. a tracer bullet user story)? Perhaps that's a PBI which they would action themselves...it would be planned into the Nexus Sprint Backlog but not into the Sprint Backlogs of any member team.

Having said that, I'm not comfortable with this idea of a Nexus doing actual work, because it fudges accountability. The idea of a Nexus facilitating and enabling, while Dev Teams do the actual work, is cleaner and neater. Yet it is also more prescriptive, and the Nexus Guide doesn't seem to make that prescription.

Agree, I'm sure we're on the same page as to how we would prefer the NIT to operate!
Except perhaps one thing: if the NIT actually pulls work from the PBL, I would expect them to have their own Sprint Backlog, as any of the other Scrum Teams in the Nexus. The purpose of the Nexus Sprint Backlog is not for the NIT to manage _their_ work, but for the Nexus to manage/bring transparency on its work, progress and dependencies.

I also would agree with this. The way I coach the matter is to say that if a NIT finds itself in the position of having to do work, then the members who are doing that work are de facto members of a Development Team, even if it is an ad-hoc one, and should therefore have their own Sprint Backlog.

However, this is just an implementation practice which I am recommending. There's nothing in the Nexus Framework which says it ought to be this way.

You're right that there's nothing explicitly stating "should they pull work from the PBL, the NIT will employ a Sprint Backlog of their own". However, it does say that the NIT is a "regular" Scrum Team in itself - ie regular Scrum "rules" apply: if they forecast doing some work during a Sprint Planning event, an output should be a Sprint Backlog.

But now we're splitting hairs. :-)

Great article! Thanks for providing this helpful insight.

However I still have some questions where the guide is rather inconsistent with the white paper.

Please clarify: Under which circumstances is the Nexus Integration Team also a Scrum Team? The Nexus-Guide states that it is a Scrum team, while the NIT Whitepaper states that it is typically not a scrum team, (but in exceptional cases such as in fail-mode can be one).
In my understanding the Nexus Integration team operates as a Scrum Team to solve specific integration issues that the Nexus is faced with. This means that the Nexus has to perform some concrete tasks to ensure that it will produce an integrated increment. The people carrying out those tasks fulfill the role of the Nexus Integration Team - they are part of it. Is this what it is meant by "the composition of the NIT should change to reflect the current need to address the integration issues at hand"? Does that mean it could change every Sprint? Or even within a Sprint?

By the way, what does the term "the services of the Product Owner role are represented on every team" mean?

Last question first: There is only one product in the Nexus, thus there's only one Product Owner. Each Development Team requires the services of a Product Owner, but it's very unlikely one person can do all the product ownership work needed by all teams. So you'll have to figure out what your context needs in terms of "scaling" the Product Owner role. (In contrast, other interpretations says you can have one Product Owner per team, and a hierarchy of people pretending to be Product Owners.)

Regarding the NIT - nice catch! :-) The language here needs improvement (and at some point likely will be updated, just like the Scrum Guide is updated every now and then). A Scrum Team has a PO, SM and DT. The NIT have these three roles as well, and thus can be seen as a regular Scrum Team. There's a range of "but ..." which makes it less clear in my opinion, but it'd be a series of blog posts rather than a short comment here ... Based on the fact that you're catching this, I'll simply say: be prepared to inspect and adapt, and you'll be good to go. :-)

If the NIT (in fail-mode) identifies that it lacks some skills that is needed to produce an increment, they'd better resolve that impediment and adjust members mid-Sprint. Integration is a key factor for successful software development - having lots of people involved adds complexity and "noise". By having great integration (CI, CD, tech practices, ...) helping with transparency is very valuable. So yes, if the ability to produce an increment is at stake, I'd sure go and make the changes necessary to have increments come out as often as needed. I'd also have the Nexus retrospect on this to see what we can do to move away from this.

Hope that's enough answer. :-)

I am about to take my Scaled Professional Scrum exam and i have found this article extremely helpful in answering some questions that i had. But i do have a few more questions:

1) The Guide says that in Nexus Sprint Planning, "All members of the scrum teams should participate to minimise communication issues". If you have multiple scrum teams, dozens of developers all in a room and dialling in via skype etc will be chaotic. I was thinking that since individual teams will still have their individual Sprint planning events, that representatives from each team that are part of the Nexus Integration team will be the ones to select PBI's that their teams will work on for that sprint. If on the other hand all team members need to be present , how should this be facilitated so that id does not become chaotic?

2) During backlog refinement is when the teams i work with size their stories. How are story estimates handled in Scaled Professional Scrum? How can we ensure that the one single prioritised product backlog is also sized?

Thanks

1) There's a number of things to go over here. :-)

1a) A team being represented in the NIT doesn't mean it has to be an individual from every team. If teams Blue and Green feel represented by a single individual from team Green, that's enough. So don't assume the NIT has individuals from all teams. They may, but that's up to your context and discovery of what's needed (empiricism, inspect and adapt!).
1b) What PBIs one team will work on may very well change during the Nexus Sprint Planning. It may be chaotic (I sure have had my fair share of those). In my experience, it's more dynamic than "step 1 [Nexus, teams picking PBIs] and then step 2 [teams work out their Sprint Backlog from selected PBIs]". Sprint Goal is typically not "discovered" during this event, but likely something that's been crafted during refinement.
1c) "participate" doesn't mean "shout out their thoughts to everybody in the room". You can send representatives to different teams you need to collaborate with, the NIT may need to assemble during this event (or not), the person updating the Nexus Sprint Backlog doesn't at all have to be the same person representing the team on the NIT. In my experience, if you quickly stand-up a Nexus with many teams, the first couple of Nexus Sprint Planning events are going to be more chaotic than later ones. There's not perfect recipe to apply to all organisations, setups, products, people, sucky internet connections, ... Inspect and adapt, always!
2) Neither Scrum nor Nexus requires a full product backlog to have all PBIs being sized. Why would you want this? (And "ensure" this?) What are you trying to achieve?

Thanks for your explanation. I read the Nexus Guide again and also read Simon Kneafsey's definitive guide on Scaled Professional Scrum and what you explained was the conclusion i gathered.

I wish there are more case studies like those on Less sites. It gives great overview of how Nexus or scaling can be implemented. The issues and how communications and dependencies are ironed out will be great.Even a solution that works on one organization may have to be tweaked or revised on another. By having cases, it allow discussions like to provide a more impactful understanding of the Scrum/ Nexus process even further. This definitely is a helpful article