Comparing Nexus and SAFe for Scaling Agile

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

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.

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

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 breathe Lean/Agile principles and practices, and strive for relentless improvement.

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”.

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.

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 places a bit more emphasis on the actual Integration work. The NIT approach should be a fascinating practice to consider on a SAFe ART / System Team.

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 to enable a tight Inspection and Adaptation cycle leveraging working product increments.

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)

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.

Both Nexus and SAFe emphasize building quality in and the importance of XP-inspired technical practices for effective scaling. Without the technical excellence, both SAFe and Nexus would drown in technical debt.

Important Differences

Didn’t I 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” option more viable. Nexus-level events are easier to facilitate/orchestrate than whole-ART events, and give 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, for both Nexus+ and the SAFe ART, is to determine which set of teams needs to coordinate and collaborate closely.

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 a single Product Owner to manage too many teams while balancing both outbound and inbound activities.

Nexus has a 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 heavily on assistance from the Development Teams to address the challenge of scale.

As we emphasize in Scrum.org Product Ownership training, Benefits from Scrum are pretty limited if your Product Owners are Scribes or Proxies. It might be easier to coordinate meetings and get time with the Product Owner, but it’s 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.

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.

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.

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.

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”

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

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

A Couple Quick Wins

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.

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

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

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.

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.

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 exploring how Nexus can complement your SAFe implementation, or vice versa.