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.