MAIN SITE ABOUT US SUBSCRIBE

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 9 keys to understand the Nexus Integration Team
 January 25, 2016  Jerónimo Palacios  Nexus, Organizational Agility , Scaling Scrum

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.
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 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
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 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

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Share this article:

Email Facebook Twitter LinkedIn 203 Google Reddit Pocket

Jerónimo Palacios

Jerónimo is a Scrum.org'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.

nexus nexus integration team

6 Comments Scrum.org Blog

 Recommend 1 ⤤ Share

Join the discussion…

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Ian Mitchell • 8 months ago
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 tha
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 wa
implementing one, but it is not a condition of its operation. In other words, a Nexus Integration Team can pull
from the Product Backlog if doing so would facilitate the integration of work across multiple teams. That wor
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 separat
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
necessary. If this is the case, priority must be given to the work for the Nexus Integration Team.”

also:
see more

△ ▽ • Reply • Share ›

Fredrik Wendt > Ian Mitchell • 5 months ago

Ian: I see your point, but what do you propose that work drawn from the Product Backlog (not the Nex

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Sprint Backlog) is? What kind of "work"?
One practice we discuss in Scaled Professional Scrum is that of putting infrastructure, operational a
architectural work, affecting multiple teams, in the product backlog. This practice, which is nothing bu
practice (so you need to think about how this applies to/in your context, if at all), could perhaps hint to
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
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 Ma
see applies to the Nexus Integration Team.
△ ▽ • Reply • Share ›

Ian Mitchell > Fredrik Wendt • 5 months ago

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

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

Fredrik Wendt > Ian Mitchell • 5 months ago

Agree, I'm sure we're on the same page as to how we would prefer the NIT to operate

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Except perhaps one thing: if the NIT actually pulls work from the PBL, I would expect t
have their own Sprint Backlog, as any of the other Scrum Teams in the Nexus. The pu
the Nexus Sprint Backlog is not for the NIT to manage _their_ work, but for the Nexus
manage/bring transparency on its work, progress and dependencies.
△ ▽ • Reply • Share ›

Ian Mitchell > Fredrik Wendt • 5 months ago

I also would agree with this. The way I coach the matter is to say that if a NIT finds itse
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.
△ ▽ • Reply • Share ›

Fredrik Wendt > Ian Mitchell • 5 months ago

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

△ ▽ • Reply • Share ›

✉ Subscribe d Add Disqus to your site Privacy

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
  The 18 Characteristics of a Great Product Owner How to start a Nexus in practice? 

Search… 

RECENT POSTS

The 8 Stances of a Scrum Master

What DevOps Taught Me About Agile

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 Consider this before hiring an Agile Coach

5 Beliefs That Predict Enterprise Agile Success

Why isn’t the Definition of Ready described in the Scrum Guide?

SUBSCRIBE TO OUR BLOG

Email Address

First Name

Last Name

City

Country

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
 SUBSCRIBE

ARCHIVES

 September 2016

 August 2016

 July 2016

 June 2016

 May 2016

 April 2016

 March 2016

 February 2016

 January 2016

 December 2015

 November 2015

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
  October 2015

 September 2015

 August 2015

 July 2015

 June 2015

 May 2015

 April 2015

 March 2015

 February 2015

 January 2015

 December 2014

 November 2014

 October 2014

 September 2014

 August 2014
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
  May 2014

 April 2014

 March 2014

 January 2014

 December 2013

Log in

sparkling Theme by Colorlib Powered by WordPress

open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com