Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Comparing Nexus and SAFe – Similarities, Differences, Ideas

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

I’ve been asked several times now about Nexus and SAFe – what are the similarities, and differences? etc. If you’re not familiar with either Nexus or SAFe I recommend taking a look at the Nexus Guide and the SAFe whitepaper first. 

Nexus and SAFe – Similar Concepts

Let’s start with similarities – There are quite a few of them as you can see: 

Nexus – ART

The Nexus group of teams is very similar to the Agile Release Train (ART) construct. In both SAFe/Scrum it is a self-managing team of self-managed teams with a couple of key roles at the team of teams level. 

Following the principles of Empiricism, Self-management within constraints, organization around value, and flow. 

Scrum theory emphasizes Empiricism and Self-management, coupled with Flow in recent years. SAFe’s theoretical base is more verbose but essentially similar. 

Lean/Agile Leadership

Both SAFe and Scrum/Nexus emphasize the need for a different style of leadership – leaders who serve, have a growth mindset, lead by example, live and breath Lean/Agile principles and practices, and strive for relentless improvement. 

Sprint – Iteration

SAFe chooses the term Iteration which is more reminiscent of Extreme Programming (XP) but looking at the details Sprints and Iterations are quite interchangeable. PS Some people feel the term Sprint isn’t the best choice if we want to emphasize “sustainable pace”. 

One Product Backlog – Program Backlog

Nexus emphasizes that for one Product there should be one single backlog – the Product Backlog. While SAFe has multiple Team Backlogs for teams working together on a product, it does have the concept of the Program Backlog which serves a similar purpose to the Product Backlog. 

Nexus Integration Team (NIT) – System Team

Both of these have a similar goal – enabling an Integrated Increment at the end of each Iteration/Sprint across the teams. When it comes to how these teams operate Nexus emphasizes the coaching/enablement role while SAFe has a bit more of an emphasis on the actual Integration work. The NIT approach should be a very interesting practice to consider on a SAFe ART / System Team. 

Scrum Master in the NIT – RTE

The Scrum Master in the NIT has a role similar to the Release Train Engineer – orchestrating and facilitating the effective use of Scrum/SAFe across the Nexus/ART with the purpose of enabling a tight Inspection and Adaptation cycle leveraging working product increments. 

Empiricism via working integrated increments every Sprint – System Demo & Nexus Sprint Review meeting a common Definition of “Done”

Both SAFe and Scrum make it very clear that frequent inspection and adaptation of working integrated increments are key to managing the uncertainty/variability inherent to product development in the complex space. The Nexus Sprint Review and the System Demo are similar events happening on a similar cadence – every several weeks (Sprint/Iteration)

Nexus Sprint Goal – Program PI Objectives – just at different cadence/frequency

Program PI Objectives serve a similar purpose to the Nexus Sprint Goal – a steady North Star goal for the Sprint or set of Iterations to focus on while the details might shift around. 

You cannot scale crap – Scaling requires technical excellence

Both Nexus and SAFe emphasize building quality in and the importance of XP-inspired technical practices in order to effectively scale. Without the technical excellence, both SAFe and Nexus would drown in technical debt. 

Important Differences

Nexus – ART

Didn’t I just say The Nexus is similar to the ART? Well, God is in the details…

A Nexus is approximately 3-9 Scrum Teams working together. An ART is approximately 5-12 teams working together. This seemingly minor change provides some insight into some of the design choices of the two frameworks. A smaller Nexus can be easier to provide Product Ownership for, making the “Single Product Owner” a more viable choice. Nexus-level events are easier to facilitate/orchestrate than whole-ART events, provide some insight into why SAFe only brings the whole ART together every PI, not every Sprint.

For larger teams of teams working on a single product, there’s Nexus+. Nexus+ is comprised of several Nexus. The “Organize around Value” challenge both for Nexus+ as well as the SAFe ART is to figure out what set of teams need to closely coordinate and collaborate. 

One Product Owner vs Product Ownership/Management Team – PM/POs

SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities.

Nexus has  Product Owner for the entire product. In real life, these Product Owners are typically accountable for the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale.

As we emphasize in Scrum.org Product Ownership training, Benefits from Scrum are quite limited if your Product Owners are Scribes or Proxies. It might be easier to coordinate meetings and get time with the Product Owner but its harder to maximize value. Benefits grow when the Product Owners are real business representatives, sponsors, or ideally entrepreneurs for their Product. 

What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. Striving towards real product ownership and what it looks like within a SAFe ART is a key topic when I’m helping an ART “Organize around Value”. Similarly to the Feature/Component team discussion, there isn’t a single best-practice here. You need to apply Systems Thinking and look at the different options, and relentlessly improve. 

Cadence/Frequency of bringing the whole Nexus/ART together for Planning and Retrospection

The Nexus reviews, retrospects, plans, and refines together every Sprint. That doesn’t mean the WHOLE Nexus gets together every Sprint though. Typically, Sprint Review has quite a wide attendance including Nexus stakeholders. Refinement, Planning and Retrospective is attended by the appropriate representatives of the Scrum Teams. What’s appropriate is a matter of context of course. 

In SAFe, the only ART-level Iteration event is System Demo (which as we discussed is very similar to the Sprint Review). There’s no formal place for the ART to Plan/Refine/Retrospect across teams on a Sprint by Sprint basis. Having said that, The ART Sync provides an opportunity to inspect and adapt throughout the ART that many organizations use to Plan/Refine/Retrospect. 

The formal cross-team Retrospection/Planning cadence in SAFe is the Program Increment which is explicitly a whole-ART event. 

No team-level Sprint Review

Nexus only has one cross-team Sprint Review. On paper, SAFe has both the Iteration Reviews at the team level as well as the System Demo at the ART level. In reality, many ARTs skip the Iteration Reviews and get enough inspection and adaptation from the System Demo. 

Scope – Team of Teams vs organizational-level 

Nexus focuses on just the team of teams – what is considered the “Essential” configuration in SAFe. SAFe also covers other competencies needed for Business Agility – Lean Portfolio Management, Large Solutions. Some organizations using Nexus end up looking at SAFe’s Portfolio-level competencies or Portfolio Kanbans to complement Nexus. 

Integrated Nexus Sprint Backlog vs various team iteration backlogs

A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. This doesn’t explicitly exist in SAFe and should be considered by ARTs that want to highlight dependencies and the flow of work during the Sprint across the ART. It can be seen as a Sprint-level version of the “Program Board”

Program Kanban

SAFe includes one of the most powerful techniques to help improve flow and collaboration across a team of teams – a Kanban Board that takes a cross-team perspective. I started using this technique back in 2009 and it’s one I “don’t leave home without”. Nexus doesn’t include a Nexus-level Kanban board but it’s a very nice complementary practice to consider. Read more here

Other potentially useful elements of SAFe that aren’t covered in Nexus

As Nexus is designed to be a lightweight framework, with a more limited scope than SAFe, its not surprising that there are a lot more elements in SAFe that Nexus doesn’t say anything about. Some of these can be useful in your context, some not necessarily. Think Architectural Runway, Innovation and Planning iteration, Team-level Kanbans, DevOps, Continuous Delivery pipeline, System Architect, Business Owner, Features/Enablers, Epics. 

Some ideas for Improving SAFe inspired by Nexus

I hinted at some of these above:

Retrospect and Plan together across the ART every Sprint/Iteration

Don’t just review together every Sprint. Also retrospect and plan together. It doesn’t mean bringing the whole ART together necessarily. It just means creating some alignment across the ART before splitting off and doing Iteration Planning at each team and then coming back together. Sort of like the pattern Solution Trains use when they do PI Planning. 

Use an ART-level Sprint Backlog

Similar to a Program Board for the PI, use an Integrated Nexus Sprint Backlog to look at dependencies at a more granular Sprint/Iteration level. This is an artifact that can support ART-level Iteration Planning 

Some ideas for adding to Nexus inspired by SAFe

Use “Big Room Planning” every 8-12 weeks

Follow the SAFe PI Planning format for higher-level alignment/refinement once in a while across the Nexus. 

Adjust Cadences and level of participation

Figure out what level of “big room” whole Nexus together makes sense every Sprint and what can fit a less frequent cadence (e.g. a PI) – Look at how you run the Nexus Sprint Planning, Retrospective specifically. 

Get inspiration from the SAFe Lean/Agile Principles and Competencies

Looking at the SAFe Principles and complementary Lean/Agile competencies like Lean Portfolio as a way to support the Nexus within the traditional ecosystem in the organization. One specific technique you can use is to look at the “Measure & Grow” Business Agility assessments that are included in SAFe. Each category or item could be something you’re already doing (great!), something that you aren’t doing yet but makes sense to consider (also great!), something that doesn’t make sense in your context (fair enough), or something that you disagree with vehemently (totally acceptable as long as you’re looking at each principle/technique at its merits…). This exercise could create an improvement backlog/roadmap. 

 

Conclusion – Options are good, Tunnel vision is bad

As professional agile practitioners we should be curious and open to new ideas. It helps to get exposed to different scaling frameworks – it gives us a better understanding of the one we’re proficient in and using, as well as provides some more ideas we can consider experimenting with. In our work with clients we try to steer them away from dogma and tunnel vision. Yes, learning multiple scaling “languages” can be confusing. (You know what I mean if you have a toddler in the house learning to speak when there are multiple languages spoken around them…) but I think it’s totally worth it. As SAFe principle #3 says “Assume Variability, Preserve Options”.

Get in touch with me if you’re interested in figuring out how Nexus can complement your SAFe implementation or vice versa.

Subscribe for Email Updates:

Categories:

Tags:

Agile for Embedded Systems
Kanban 101
Systems Thinking
Scrum With Kanban
Agile Project
Legacy Code
Lean Agile Leadership
GanttBan
Kanban Basics
PI Objectives
LPM
Agile Development
SAFe Release Planning
Implementation of Lean and Agile
BDD
Release Train Engineer
Lean-Agile Software Development
Artificial Intelligence
System Archetypes
DevOps
Sprint Planning
Agile Delivery
RSA
System Team
Enterprise DevOps
Program Increment
Daily Scrum
Scrum
Scrum and XP
Continuous Integration
Agile Release Planning
Agile Mindset
RTE
Risk Management on Agile Projects
Story Slicing
Lean Startup
Video
Legacy Enterprise
Agile Community
Agile Risk Management
Kaizen Workshop
Nexus vs SAFe
Professional Scrum with Kanban
Lean Agile Basics
Continuous Planning
Agile
Certification
Portfolio for Jira
speed at scale
AgileSparks
ART Success
AI Artificial Intelligence
A Kanban System for Software Engineering
LAB
Business Agility
Managing Risk on Agile Projects
POPM
Acceptance Test-Driven Development
AI
Agile Techniques
Kanban Game
SAFe DevOps
Agile India
Webinar
Scrum Master
Professional Scrum Product Owner
Test Driven Development
Agile in the Enterprise
Achieve Business Agility
speed @ scale
Jira admin
Agile and DevOps Journey
Atlassian
Releases Using Lean
Value Streams
Rapid RTC
Process Improvement
Agile Testing Practices
predictability
Nexus and SAFe
Accelerate Value Delivery At Scale
Scrum.org
Limiting Work in Progress
Kanban Kickstart Example
Lean Budgeting
Large Scale Scrum
Software Development
agileisrael
Continuous Deployment
Nexus and Kanban
ATDD vs. BDD
Agile Program
IT Operations
Lean-Agile Budgeting
Product Ownership
Lean Agile Management
Scrum Master Role
ROI
Sprint Retrospectives
chatgpt
Hybrid Work
Games and Exercises
Covid19
Presentation
Change Management
Effective Agile Retrospectives
Kanban
The Agile Coach
Reading List
Software Development Estimation
Sprint Iteration
The Kanban Method
Perfection Game
Scrum Values
Slides
ATDD
ALM Tools
ScrumMaster Tales
QA
Jira Cloud
What Is Kanban
Agile Games and Exercises
ARTs
Development Value Streams
Agile Assembly Architecture
Product Management
Jira
Lean Agile Organization
Engineering Practices
Agile Israel
Scaled Agile Framework
Advanced Roadmaps
Entrepreneurial Operating System®
Principles of Lean-Agile Leadership
Kaizen
RTE Role
lean agile change management
Operational Value Stream
Tips
TDD
Agile Exercises
Agile Basics
Spotify
Nexus Integration Team
Agile Product Development
Applying Agile Methodology
Lean Agile
Agile Israel Events
Quality Assurance
Agile Product Ownership
User stories
An Appreciative Retrospective
Agile Marketing
Risk-aware Product Development
Frameworks
SPC
System Integration Environments
Certified SAFe
LeSS
Amdocs
Manage Budget Creation
NIT
SA
Agility
Lean Risk Management
Risk Management in Kanban
SAFe
Planning
Agile Release Management
Jira Plans
Introduction to ATDD
Lean Software Development
EOS®
Scrum Primer
Code
Pomodoro Technique
Atlaassian
Built-In Quality
Introduction to Test Driven Development
Agile Games
Continuous Delivery
Lean and Agile Principles and Practices
Coaching Agile Teams
WIP
PI Planning
Professional Scrum Master
Lean and Agile Techniques
Agile Outsourcing
Iterative Incremental Development
Tools
Scrum Guide
Continuous Improvement
Nexus
Agile Contracts Best Practices
Self-organization
Elastic Leadership
Implementing SAFe
Managing Projects
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart