Scaling Agile is fascinating and not trivial, at all. Many framework exists, SAFe for example is a famous, organic and somehow quite structured one that allows to scale agile within the whole organization through its four layers: Team, Program, Value Stream, Portfolio.
That structure can be overwhelming when applied to small programs and when there’s no need to scale up to the strategic portfolio layer
In that case Nexus, more light-weight, can be used.
A Nexus, as a generic definition, can be seen as the means of connection between things/groups linked together, which represents a whole that delivers value.
That definition is very interesting, because it stresses the concept that value can be delivered only through the cooperation and synchronization of the different actors forming the Nexus.
Nexus is the name that Ken Schwaber (one of the founding fathers of Scrum) gave to a framework which actually “extends” Scrum for scaling purposes. It has been thought for programs which combine from three to nine scrum teams and is strongly geared on Scrum fundamentals. Essentially, Nexus wants to answer and hence solve problems which always pop up when scaling Scrum: dependencies and integration issues.
Dependencies Issues
When three or more teams are working “against” the same product, they will for sure struggle with dependencies about requirements, how they are decomposed, prioritized and hence sequencing and distributed between teams. Another interesting point about dependencies regards the knowledge of the team members. It happens frequently that, despite the willingness to have T-Shaped team members (generalizing specialist) – which are specialized in a specific domain (e.g. front-end developer) but also able to cover other roles (e.g. tester) – they, however, have siloed knowledge that often creates dependencies between teams.
Then we have technical dependencies more specific to source code and how it is managed through repositories, version controls and other artifacts more related to testing.
Integration Issues
According to the Agile Manifesto principles, we want to deliver working and valuable software every sprint. In a program with more teams we need to keep in mind that integration will happen putting together the different potentially shippable increments coming from the teams, into a single product increment.
This is hard work indeed and leaving it “just” to teams’ self-organization, could be a real challenge. Nexus wants to solve these problems, starting from “pure” Scrum and adding just the necessary additional roles, events, artifacts and rules to make this work.
This is the Nexus life-cycle.
Considering that Scrum is the corner stone, the foundation pillars, let’s see what is added or changed.
Nexus Integration Team Entity
An important entity is added, which is called the Nexus Integration team.
The team is formed by the Product Owner (look, we have just one Product Owner for the whole Nexus), the Scrum Master and one or more team members, eventually shared between scrum teams. The composition of this team could change, if necessary, according to the necessity of the product development.
The main responsibility of this team is to address any integration issue the program is facing; sometimes it could even work on P.B. items that are related to integration.
Artifacts
We obviously have one product backlog which is owned by the Product Owner. This product backlog is refined and stories pulled by teams.
A new artifact is the Nexus Sprint Backlog which is the formed by the Nexus Sprint Goal and the collection of the various team Sprint Backlogs and goals.
Lots of use of Visual Management is recommended in order to see the work to be done and every dependency of the program.
The Nexus sprint backlog hence should visualize all the items above described.
Product Backlog Refinement
I want to start with this activity because in, my opinion, is the most understated event in standard Scrum, thus leading to many and big problems.
In a program with more teams collaborating and insisting on the same product backlog, this is even more important. Nexus framework does not identify a specific event, as Scrum, but states that refinement should happen according to complexity and rhythm of the program.
The main objectives are:
- decompose coarse grained items in more fine ones ready to be developed in the upcoming sprints,
- think on what items of the product backlog will be pulled by what team,
- minimize dependencies.
A first part of the meeting should be dedicated to refinement and the second one to dependencies minimization.
Nexus Sprint Planning Event
Product Owner gives knowledge and contexts about stories that should be developed, according to the previous activity of backlog refinement.
Teams validate and prioritize the stories they pulled and after a discussion that aims to finally consolidate the high level vision of the sprint, each team execute its own sprint planning. It is highly recommended that the sprint planning for each team happens in the same spaces in order to immediately address and discuss any dependency.
The event concludes when every team finishes the forecast for the sprint and a big, overall (Nexus) visualization of sprint backlogs and dependencies is done.
The Nexus sprint goal must be confirmed by each team sprint goal.
Nexus Daily Scrum Event
This events happens just before the the team daily scrum. Nexus Sprint Backlog is used to guide the meeting. Status of integration is the main topic.
Representatives from the development team should participate with the Nexus Integration Team, to identify, discuss and address any integration or dependency issue. Decisions and work to be done to solve problems, must be reported in the daily scrum of each team by the respective representatives.
Nexus Sprint Review Event
This event replace the one from each team. The integrated product increment is showed to stakeholders to gather feedback.
Nexus Sprint Retrospective Event
The event is divided into three separate parts, but in general focus is on: Integration issues, Technical Debt, Work Undone.
During the first part teams (or representatives) meet to discuss main issues and problems which have impacted the program. Focus should be on impacts across two or more teams.
The second part is held by each team according to Scrum; input from previous part should be addressed accordingly.
In the final part the teams (or representatives) meet to share decisions or any new information. They also decide on how to visualize improvement actions.
