SAFe vs LeSS vs Nexus Vs Spotify method, etc


I could see team doing scrum and kanban in the art if you move to through put instead of a normalized story points. We have teams with disfuctional story point estimation at the current org. So their velocities are all over the place but if you look at the throughput they constantly do 15 to 20 stories. actual count vs mystical number
Throughout for the win in my book.


To be fair, it isn’t always a vs. model. Nexus for example is just Scrum at scale. It does a lot of the things we all do today when taking Scrum from one team to many and puts a framework around that. As many would say, it is just common sense. That said, why not a vs. model? You can use Nexus in a SAFe environment for example and many people are. At the base of SAFe is Scrum and how do you scale from a single Scrum team to many working on the same product, Nexus. I spent time with Dean at Agile 2016 talking about this exact model and he totally agreed as well, Nexus can be used within SAFe as the way you scale your product teams from 1 Scrum Team to many. Same within DAD and the conversations I have had with Scott. DAD is not prescriptive to the point of saying what you use and encompasses many frameworks to deliver software and Nexus can be and is used within DAD environments.


What I’m really interested in is the paths orgs need to take to get to some form of agility at scale. The models are just that: Models. In that they are always wrong, but might be useful in helping plot a path from “Giant org that can’t get anything done” to “Giant org made up of a bunch of smaller orgs who get things done, with some way of keeping things more or less aligned”.

Of course, something like SAFe (or any of the others) isn’t something you can just drop on top of an org. Especially one that hasn’t even got the basics mastered, or who might be missing the technical plumbing around CI/CD.

I would venture to say that the Spotify model, insofar as it is a model, is probably the one of the 4 mentioned that is the least likely to inflict harm on the org, as long as it is used as a model of a what an early success milestone might look like as part of an ongoing transformation. None of the models should be viewed as a successful ‘conclusion’ to a transformation.


@enaiburg Eric would you be interested in doing a podcast around this topic. I know I would be very interested in hearing more. this topic is at the for front of almost every client I walk into. Let me know if that is something of interest and we can start to put an agenda together and throw some dates out there. Great discussion so far.


@Leanleff I would love to do a podcast and maybe get some others to join from as well.


@enaiburg and @Leanleff a podcast on this topic would be really awesome. Combining elements of different scaling frameworks is an awesome topic.


We should ask @Todd for a contact at .org that can talk about Nexus. Maybe Patricia Kong?


@enaiburg awesome I will start putting some dates and will message you with some outline of topics we can tweak it from there. Keeping this topic to a timebox should be interesting. We might need to do this as a series. :slight_smile:


Just wanted to let everyone know of the availability of Enterprise Scrum. Enterprise Scrum currently has about ~10% of the market. It is the oldest scaling method – started in 2003, and it is both a scaling and genericity framework. So you can do scaled-up software development, or Scrum for: company management, marketing, compliance, HR, finance, etc.

There is a book on Enterprise Scrum coming out early next year, and classes and certifications starting in January of 2017.

Here is an introduction to Enterprise Scrum:


In my experience, scaling frameworks tend to be popular because they appear to provide an answer to the “What-do-I-do-in-this-complex-mess-I-am-in?” question. The more rigid the framework (i.e. the more clear cut / “Do this and only this”) the more appealing it sounds as it feels comfortable to follow a recipe as opposed to have to come up with everything yourself. However, once an organisation gets over certain size, it invariably grows in complexity (often exponentially) and that complexity makes it inherently unsuitable to any rigid framework.

Local context is everything and while “Do this and you will be fine” sounds tempting (because it means people need to think a less), it usually leads to a many undesirable consequences at a local and org level. It often results in a superficial adoption of the “recipe” and its practices without any deeper understanding of the “Why” and without actually delivering the desired org/business outcomes and benefits that prompted the adoption of a given scaling in the first place.

Scaling framework are useful and provide a range of approaches for organisations and teams to consider when scaling their agile delivery. However, the best way to scale is to start with a deep understanding of how the org works today, be selective about which practices from which frameworks to adopt (and for what reason), be sensitive to specific contexts and business needs (of which there are many in a large org) and to always remain focused on the “Why are we doing this” question.



Just attended a presentation by Craig Larman, LeSS founder. Of course he is a purist and I’m less than a newbie. Wondering how many companies are inclined to completely change their structure and maintain it as executives come and go.


I consider all scaling frameworks as a useful set of patterns and only apply what makes sense for my current environment.

First rule of scaling is don’t scale bad agile. Most companies appear to get this wrong.

9 times out of 10 I suggest basic Scrum and XP practices at the team level and try to protect the teams from as much BS as possible.

Only take the patterns that from the scaling frameworks that will help your teams deliver value.

BTW, just like many ‘scrum’ teams don’t do scrum. Many “SAFe” orgs don’t do SAFe.

Our job is to help them all be as agile as possible, not to be as ‘SAFe’ as possible.



Please take a look at my blog which proposes an approach to compare these 3 and recommends contexts in which each might be appropriate…



Great response - it resonates properly with what I’m going through:

I’m in a giant legacy organisation that is throwing itself into Agile, with seemingly little knowledge of the landscape of Agile frameworks. The top management layers have stipulated that SAFe training is mandatory and that job safety depends on your 2 day training success.

Then, they superimpose SAfe on top of SCRUM teams to ‘plan and maintain focus’. This translates into a 3 month (6 two week sprints) window where no new requirements are considered. Teams must then iterate - in an agile fashion - to deliver pre-defined outcomes. Product discovery is taken care of by teams totally focused on discovery and passed to development teams who will then build the product in an agile fashion.

This is an example to me of where a lack of knowledge can stifle not only the development practices progress, but also the culture. Experimentation has gone out the window in favour of ‘lock step’ and various other mandated processes. And it seems very anti-agile to me at least.