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:

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