Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Observations on Scaled Professional Scrum and possible constraints represented by the Nexus

Last post 09:48 am April 13, 2015 by David Dame
3 replies
05:58 pm April 3, 2015

I've been going through the site looking at the Scaled Professional Scrum resources, and comparing this framework as sensibly as I can with's Evidence Based Management.

Although EBMgt is applicable to a wide range of scaling conditions, I wonder if SPS is more restricted in its potential. The key constraint is perhaps the "Nexus" which provides its underpinning. The assumption seems to be that multiple teams can draw work from a shared Product Backlog, and SPS appears to imply that enterprise scaling matters can be framed in these terms.

In other words a Nexus seems to assume the existence of a product or value proposition that has achieved scale, or is rapidly achieving it. The Scrum Teams that form an incipient Nexus respond to that condition. Since product scalability is never really in any doubt, teams arguably play in a field of clover that is tilted towards success.

However, most organizations at scale do not actually build software at scale, and the playing field for their developers is irregular and boggy. Software supports what these enterprises do, but it isn't what they do, so there is little pressure to scale these products. They may have scores of internal applications and obscure bits of middleware, each discrete element of which rarely involves more than one development team in its creation and maintenance. The numbers on these teams are at the low end, three developers or so being the norm. To enterprises like this, a Nexus is as irrelevant as a shared Product Backlog.

The difficulty these organizations face isn't one of scaling teams to support scaled products. They aren't mature enough in terms of agile development to enjoy that class of problem, and they may be in lines of business that don't place value on such artifacts anyway. Their challenge is one of understanding the most basic of agile practices, while applying them at the scale they have achieved in the business they happen to be in. These include the financial, retail, and transport sectors, a whole raft of public bodies, and many SME's.

The concerns they harbor might be elementary, but they are still "enterprise scale". They include:

- "How do we staff one team without robbing another?"
- "How do we support BAU as well as development work?"
- "Why is predictability so poor?"
- "How can we get rid of this technical debt?"
- "Why don't our projects deliver the value we hoped for?"
- "How can we get the I.T. Department to be more efficient?"
- "How can we get Business off our backs?"
- "How can we get other people to change?"
- "Where does product ownership reside, and how far can we compromise it?"
- "How can we change agile practices to fit the reality and greater pragmatism our organization is built on?"

Some of these concerns are reasonable and obviously some aren't. The point is that these organizations are on an agile journey, each one is larger than just one team, and none are remotely interested in having a scalable product that would justify a Nexus, and which would give them a shared, product-focused scaling narrative. For them, perhaps Evidence Based Management offers more than Scaled Professional Scrum does.

02:17 pm April 6, 2015

I just wanted to say "Thank You" for all your help during my PSM I preparation. I passed it from the first try. :)

Thanks Ian!


02:41 pm April 6, 2015


> multiple teams can draw work from a shared Product Backlog,

I think you hit it on the head here. The scope/context for Nexus is for 3-9 Scrum Teams working to deliver the same product or same application/system. If you have more than 9 teams, then you'd have multiple Nexuses.

EBM's scope is essentially any org that has one or more products that wants to get better at how they implement and reap the benefits of Agility.

09:48 am April 13, 2015

Hi Ian,

Great post. In your post I interpret what you say as the reason why were scaling via Scaled Professional Scrum, particularly the nexus, is to support a product that is scaling in size. Although, this is a specific use case or reason why we would scale, but it's not the only one.

A large organization can grow one of two ways: organically or through acquisition.

Organically, we can continue to add teams as we see fit depending on the architecture/technology of our product. If you are going to grow beyond one product, by might be a logical way to align teams and nexus's.

Growth through acquisition, requires a strategy of how to align the new organizations products/functions/workforce into an agile model. In addition to product line, there might be more other matrices to consider when building/organizing nexus's (or nexus +).

They are also aspects in regarding timing of the agile adoption.

If the organization started (or started early) using scrum, they have been able to scale their professional scrum teams in a steady momentum of inspecting and adapting.

If the organization adopted using scrum after they've grown in size, they may have to start out forming their nexus under one context, but continually realign them as the become more transparent in finding best ways to organize.

In comparing Scaled Professional Scrum with Evidence-Based Management, I believe it's not one or the other. I believe there is great synergy in utilizing both. Especially, when you're talking about extremely large organizations that are Nexus + in scale. The SPS can give you a framework that you use to continually improve practices from closer to the nexus (the doing level) , with Evidence-Based Management system allows you to continually improve at the leadership/executive level for the whole organization (extending beyond software development or IT)

You brought up a lot of points that are challenges no matter what methodology you use. We have to remember that agile adoption (Scaled Professional Scrum,, Evidence-Based Management, Proven Practices, Product Health) is a long game, not a sprint. We know that scrum is a journey… Agile adoption at scale is a commitment to continually pursue that journey under a variety of influences that epic size and scale brings. SPS won't be your silver bullet, rather tool or guiding light, and faith to be resilient as you pursue the challenge of adopting scrum across large enterprises.

I apologize for any voice recognition errors that might be in this post :-)

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.