9 keys to understand the Nexus Integration Team

After downloading and studying the Nexus guide, you have questions about how the Nexus Integration Team actually works, so here are some keys to understand the role and its fit within the Nexus.

It’s all about solving dependencies

Nexus is focused is solving the primary source of issues and problems when scaling beyond two Scrum Teams: dependencies. No matter how nvolved your corporate culture is or how well your retrospectives are facilitated, if you join more and more teams working in the same product, you’ll face integration issues. Remember that the goal is deliver a Done Increment, integrated, at the end of the sprint. Thus, is important that someone remains accountable and responsible to deal with integration issues.

The Nexus Integration Team is a role, performed by several people

The Nexus Integration Team is compound by the Scrum Master, the Product Owner and whomever needs to be there to make sure that Integration actually happens to deliver a Done Increment at the end of every Nexus Sprint. That may be proper representatives from the team, a DevOps guy or one member from each Scrum Team.

And still, is a Scrum Team

The Nexus Integration Team behaves as another Scrum Team within the Nexus. While its main focus is Integration that facilitates a Done Increment that may be inspected during the Sprint Review, it may pull and work other Product Backlog Items that are relevant for producing the Increment.

And yet, its composition may change

Dependencies and integration may vary from Sprint to Sprint. While Scrum Teams are relatively stable, the NIT will change to reflect challenges. Because at the beginning of a Scrum project the focus will be on a DevOps tooling infrastructure and later may be on End-to-end testing, the NIT will inspect and adapt its membership to show those challenges. What will remain stable is the Product Owner and Scrum Master membership.

While being responsible for Integration does not mean that it has to perform integration itself

Imagine having to integrate the work from seven Scrum Teams every sprint. Crazy, huh? 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.

Tooling, tooling, tooling

And the best way to achieve Integration resulting on a Done Increment is tooling. Rather than spending infinite hours figuring out where a problem resides, a smart Nexus Integration Team works on setting up a tooling infrastructure that supports Continuous Integration, Deployment and Delivery, ensure the cohesion of tools across teams the closer the end of the pipeline is.

And Teaching. And Coaching. And Patience

The job of the Nexus Integration Team may be exhausting. Because achieving a Done Increment by doing integration itself is out of the question, the work of the NIT requires prodigious amounts of teaching, coaching and patience, using those core practices already present in Scrum to facilitate Scrum Team’s proper delivery.

This sounds a lot like the Scrum of Scrums

Well, no. There is a lot of common sense on the Scrum of Scrums. It is just a meeting. The Nexus Integration Team addresses the flaws of the Scrum of Scrums creating a role that remains accountable for integration. Have you ever heard that complain: “We don’t have time for DevOps infrastructure”. Well, your NIT does.

And if you think you still haven’t got it

Remember the first time you heard of the Scrum Master? It took a long time until people started to understand what a Scrum Master is. Nowadays, nobody argues the existence and benefit of having a Scrum Master managing the Scrum process within the Scrum Teams. Yet it is difficult to explain. Well, in a few years no-one will question the existence of the NIT.

Happy Nexus.

You can read more about how to start with Scrum in Spanish in my personal blog

Jerónimo is a's Professional Scrum Trainer (PST) and an Agile Coach. He supports small & large organisations transition from process-centric to value-centric systems, working at strategic level with top management and C-execs as well as functional teams to make transformations happen using frameworks like Nexus and Scrum.

  • Pingback: Issue 46 - Agilean Weekly()

  • Ian Mitchell

    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.”


    “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.

    • Fredrik Wendt

      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.

      • Ian Mitchell

        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.

        • Fredrik Wendt

          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.

          • Ian Mitchell

            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.

          • Fredrik Wendt

            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. :-)