Skip to main content

9 keys to understand the Nexus Integration Team

January 25, 2016

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

 


What did you think about this post?