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.
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.
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 incrementscoming 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.
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.
My experience taught me these lessons.
Not always is feasible to have the whole team involved in Nexus events (see also LeSS Huge). In those cases representatives should be sent. Well, these guys are so important and you need to think and select them according to their skills, knowledge, communication and negotiation abilities.
Nexus asks for one PO, just one. Every team shall find the best solution to leverage that role and adjust, not having her always in its room. Once more, you need to think how the team could ease and facilitate this discussion and relationship (see representatives above).
This team is in charge to mainly face and lead the resolution of integration issues. That’s its primary objective. You need to spend some time to think who should be part of it, about the roles of the Scrum Master and understand how the PO should behave within this team and with other Scrum teams.
One DoD (Definition of Done)
In Scrum definition of Done is an agreement the team makes to decide when the work can be definitely defined as done. This has activity that must be finished and has to do with coding, testing, acceptance, user documentation and the like, anything necessary to ship a working feature.
Well, in Nexus teams should agree to have one DoD in order to facilitate (again) integration and minimize dependencies.
This is so important, moreover when you are working with several teams on the same program. Time taught me that events like planning, refinement, review and retrospective at Nexus level, MUST be done together in shared spaces or, at least, leveraging the best technology to keep team in touch via IM, Webcams, VDC, etc.
Another error teams do frequently is to underestimate the power of visualization.
I teach my teams to have a Nexus program board on which report the sprint backlog(s), any dependency showed via red stripes (SAFe here is master) and visualizing every impediments via post-its and a dedicated board.
Finally if you have:
- teams that are already good with Scrum,
- not many teams working together to build one product
- not too many external dependencies
- not too much complexity on how to sync and map the program to Enterprise structure and processes (or the Enterprise is guan Agile one)
well, in that case, Nexus could be the right choice….otherwise, SAFe comes to play.
See you guys!