This is the first of six articles on approaches that try to help to scale Agile. One of the most popular Agile methods is Scrum. Scrum is a very simple framework that describes an one iteration, one increment, one team product development effort. The framework leaves the more complex application of Scrum to the user. Many, many organizations have devised their own processes, standards, frameworks, etc. with which they apply Scrum to a wide-range of large development challenges.
But lately these scaling challenges and frameworks have become a hot topic in the agile community and multiple approaches have been created to address scaling Scrum and scaling Agile. Currently there are 5 well-known approaches that try to address these challenges each in their own way. In no particular order:
1) Nexus, by Ken Schwaber, www.scrum.org
2) DAD (Disciplined Agile Delivery), by Scott Ambler and Mark Lines, www.disciplinedagiledelivery.com
3) LeSS (Large Scale Scrum), by Craig Larman and Bas Vodde, www.less.works
4) SAFe (Scaled Agile Framework), by Dean Leffingwell, www.scaledagileframework.com
5) Scrum at Scale, by Jeff Sutherland, www.scruminc.com
Each one of them has their own focus and ideas. This series of articles will present and discuss each one of them. The final article will try to make a comparison between them and present weak/strong points, limitations etc.
The Nexus Framework
This first article will present the Nexus framework. Nexus is created by Ken Schaber and his team from Scrum.org. Nexus is a framework that is intended for developing and sustaining large software development projects.
Ken states on his blog that he has been working with people who have actually made Scrum scale for large projects and product initiatives over the last twenty years. Their smallest project experience was 3 teams, average 25 teams, and largest was 80 teams. In an answer to one of his blogposts Ken states that experiences were made at Microsoft, Intuit, Keybank, Adobe, and other organizations that do not want to be named.
Ken and his team abstracted a framework for this scaling which they named Nexus, defined as a causal link between things, such as biological nervous systems. In this case, a Nexus is 3-9 Scrum Teams that are working on a single Product Backlog to build an integrated increment that meets a goal. A Nexus+ is more than one Nexus inter-operating to build a large product, usually integrated through a product family framework, API, or such.
The core of the Nexus Framework is the development and reformulation of 40+ practices which cause the Nexus to operate predictably. They call this Scaling Professional Scrum, because they agreed that you cannot Scale amateur Scrum, represented by such bad practices as lack of integration and excessive dependencies.
The Nexus Guide that is describing those practices can be downloaded here www.scrum.org/Resources/The-Nexus-Guide. The Nexus Guide can be used next to the Scrum Guide (www.scrumguides.org) to scale Scrum and support the integrated effort of multiple software development teams.
What’s so special about Nexus?
Nexus is defined as an extension of Scrum, an exoskeleton. Single team Scrum artifacts are integrated in Nexus artifacts (Nexus Sprint Backlog, Integrated Increment). Events for managing the integration through identifying and resolving dependencies drive existing Scrum events, such as the Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Retrospective and where appropriate replace them (Nexus Sprint Review). Rather than relying on serendipity, integration responsibility is formally embedded in a new role, the Nexus Integration Team.
Roles, Artifacts and Events
As displayed in the following graphic, Nexus consists of:
Roles: A new role, the Nexus Integration Team, exists to coordinate, coach, and supervise the application of Nexus and the operation of Scrum so the best outcomes are derived. The Nexus Integration Team consists of a Product Owner, a Scrum Master, and Nexus Integration Team Members.
Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will do the work inside a Sprint are made visual. A new artifact, the Nexus Sprint Backlog, exists to assist with transparency during the Sprint. All Scrum Teams maintain their individual Sprint Backlogs.
Events: Events are appended to, placed around, or replace (in the case of the Sprint Review) regular Scrum events to augment them. As modified, they serve both the overall effort of all Scrum Teams in the Nexus, and each individual team.
Nexus+ provides an architectural platform for consistently integrating the work of multiple Scrum teams into a consistent, quality whole.
How does Nexus relates to the other scaling approaches like SAFe, DAD, LeSS?
This question will be part of every article but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion.
Ken Schwaber in an InfoQ Interview:
Nexus is different both in scope, approach, and cost. Nexus only addresses scaling software development, starting with a Product Backlog, budget, goal, and scope. Nexus also is only a framework within which an organizations unique approach to software development operates. Nexus does not guarantee success and is not formulaic. The people doing the software development do so to be successful in the most appropriate manner available. Individuals and interactions over processes and tools.
Are there well-documented use cases of companies using Nexus?
According to Ken in an interview on InfoQ it is being used worldwide. They are gathering, editing, and will publish examples and case studies on their website, www.scrum.org, as soon as they are ready. At the moment of writing no such use case has been published.
