I have been involved in a series of experiments and most recently a large scale initiative with Nexus as the backbone. Nexus is a scaling framework for enabling multiple Scrum teams to work together. It aims to reduce the number of cross team dependency and integration issues. The core principles behind are:

• Making the right people interact at the right time
• Having a single shared entry point for work in the teams.

How does Nexus work?

Epics flow into the overall Nexus Product Backlog where they are refined in order to reduce the number of dependencies between each other. Periodically the Scrum teams pull the Epics from the Nexus Product Backlog into their own Team Product Backlogs. Scrum Teams work on their epics as autonomous as possible and integrate their work as often as possible. In order to make sure that the software produced can integrate, the appropriate competencies across the teams meet to discuss dependencies and solutions.

How to get started?

Taking an exoskeleton like Nexus and making it work in the real world requires som adapation. In our case, we have strived to be true to the framework and grow the model in places where our organisation has gaps. Our setup has one central Product Owner and several Product Owners who each has their own Development Team and Product Backlog.

Here is how we started the Nexus Product Backlog:

1. Early in our large scale initiative our Product Owners and customers gathered and gave their first shot on Epics for the Nexus Product Backlog
2. Product Owners and relevant teams and customers refined the Epics to a state where it was clear which teams would be able to pull the Epics
3. Teams pull Epics to their Product Backlog for further refinement and dependencies startet to unveal themselves
4. To get an overview of dependencies we gathered all teams for a big room planning session where face to face communication was a high priority
5. Output of the bigroom planning is a forecast and visualisation of identified dependencies that is placed centrally in the office space

Steps 2-5 are repeated continuously to ensure that scope of the initiative adheres to changes over time.

Keep it running

Nexus Integration Team (NIT) is a new team spawned in the Nexus theory. Its primary goal is to reduce dependencies and enhance interoperation between the involved Scrum Teams. NIT is not a management team and does not have any power over the Scrum Teams. In fact, NIT primarily has members from the Scrum Teams and only a handful of dedicated people. In the theory of Nexus the NIT has two static roles defined:

• Scrum Master
• Product Owner

In our scenario we have a dedicated Scrum Master, a dedicated Product Owner and three dedicated supporting roles – Business Architect, IT Architect and Agile Coach. The supporting roles are there to aid the Scrum Master and Product Owner in implementing the Epics on the Nexus Product Backlog. In addition team members from the involved Scrum Teams are integrated in the NIT when their competencies are needed to help reduce cross team dependencies and delivering integrated software.