Skip to main content

I'm Not Calling Your Baby Ugly - Two Ways and 25 Dimensions to Compare Agile Scaling Frameworks

April 20, 2017

True Story...

Many times, clients ask Agile Coaches like me to come in and share our "expertise" with them. But sometimes they really don't want our "Expertise". What they really want is someone with lots of TLA's to come and tell them that there pre-existing opinions are correct.

However, sometimes, things don't go the way they want. I tell them what I sincerely believe in and not what they want to hear. At this point, things get messy. Feelings are hurt, engagements are ended and there is heartache all around. It's like I called their baby ugly.

Actually I didn't. I was trying to tell them what car-seat is the best fit for the long term well-being of their baby. So I may have called their car-seat unsafe and recommended a different one, but I didn't call their baby ugly.

Before the analogies start getting too confusing, let me explain...

The "baby" in the analogy is the end-goal - the long-term well-being and Sustainable Competitive Advantage of your Business. The "car-seat" is a means to the end, kind-of like Agile Frameworks, Practices and Tools.

Of late, these interactions often seem to revolve around Agile Scaling Frameworks. So I thought I could save us all a lot of grief and save you a lot of time and money by proposing a way to compare scaling frameworks.


To avoid a situation where you think I am calling your Baby ugly, please read this blog only if you see yourself in one of these categories...

  1. You want to come up with your own approach to compare Agile Scaling Frameworks and want to see another approach to get some ideas for your own.
  2. You want to use a pre-existing approach to compare Agile Scaling Frameworks with your teams
  3. You are interested in my expert opinion on applying this approach to compare and recommend an Agile Scaling Framework.

If you already have a favorite Agile Scaling Framework and get emotional if anyone recommends another framework, please save us all a lot of trouble and stop reading now.


I chose three candidate scaling frameworks as I was coming up with this approach...


LeSS is Scrum applied to many teams working together on one product. The LeSS Rules are the definition of the LeSS Framework. They are considered a must.

Essential SAFe

Essential SAFe is a subset that describes the minimal elements necessary to be successful. If you incorporate these ten essential elements for each release train in your portfolio, you’re well on your way to realizing the full benefits of SAFe.


Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.


Start by asking the teams four important questions...

  1. What Business Outcomes do you want from scaling?
  2. What are the biggest barriers to achieving these outcomes?
  3. What constraints impact scaling adoption? What characteristics of a scaling framework will enable easy adoption?
  4. What are your fundamental beliefs about a scaling frameworks?

To avoid biases and get the big picture, make sure you get diversity of input from...

  1. Different levels in the org chart
  2. Different functional groups
  3. Different lines of business

Once you have the views of the teams, try to synthesize them and look out for patterns and differences.

Now, let me share some of my perspectives on these topics...


I believe there should be 5 key desired outcomes for Agile Scaling...

  1. VALUE‒Scale delivery of valuable features and solutions that customers use
  2. QUALITY‒Scale quality of integrated features and solutions
  3. TIME TO MARKET‒Deliver valuable features and solutions frequently & regularly
  4. WASTE‒De-scale the waste of time, effort, money
  5. RISK‒De-scale the exposure to uncertain, undesirable outcomes


Based on my experience, most companies face these top 10 impediments to  Scaling Business Agility...

  1. ACTIVITY BASED SCALING- Focus on scaling # of people, teams, rituals & not on scaling business value
  2. PROJECT THINKING‒Wasting company time and money on project accounting, context switching
  3. SILO'D TEAMS‒Teams based on components, functional areas increasing hand-offs, dependencies
  4. TEAM PERSISTENCE‒Team composition changing frequently, impeding self-organization and learning
  5. REACTIVE INTERACTIONS‒Reactive, crisis driven interactions between inter-dependent teams
  6. LOCAL OPTIMIZATION‒Valuing good of the silo over good of the organization
  7. ENVIRONMENTS‒Lack of shared prod-like environments & data impede frequent integration
  8. TOOLS‒Ineffective use of tools inhibits interactions, self-organization and learning
  9. POLICIES‒Org Structure, Hiring, Performance management, Office space, Outsourcing
  10. CULTURE‒Command and control, waterfall culture inhibits empirical management of value


Remember that merely choosing an Agile Scaling framework will not magically remove all these impediments. In fact, most frameworks may not even prescribe how to address some of these impediments. They may only provide guiding principles, values and some descriptive suggestions that may help you figure out how to make changes to the surrounding eco-system in a way that enables the scaling framework to be effective.


I believe that five key elements of Scaling Frameworks influence the ease of adoption...

  1. SIMPLICITY & CLARITY‒Simple, clearly expressed framework enables shared understanding
  2. BUILDING BLOCKS‒Using Scrum as a building block enables Scaled Scrum
  3. NEED FOR ORG CHANGES‒Minimal addition of new roles, up-front org changes eases adoption
  4. EASE OF LEARNING‒Free, online resources enable scaled, self-paced learning
  5. CERTIFICATION‒Certification helps team members validate their understanding


If we combine the 5 desired outcomes of Scaling with the 5 enablers of adoption, we can create a weighted 10 point comparison matrix. I chose to distribute 100 points across these 10 criteria - 60 points for scaling outcomes and 40 points for scaling adoption enablers...


Now that we have 10 distinct criteria, you can rate each framework on a 7 point scale: starting from -3 to indicate that the framework will impede most teams, to +3 indicating that the framework will enable most teams, with 0 indicating that the framework will have no impact on the status quo of scaling...


Here is my comparison of the 3 Scaling Frameworks on the 10 point comparison criteria based on outcomes and ease of adoption. If your eyes are as bad as mine, you will likely need to zoom in so you can see this eye-chart...


Now this may come as a surprise to you, but I happen to have some very strong beliefs about what is needed for effective scaling. There are only 15 of them ;), so let me share them with you...

1.A simple, clear framework- Enables shared understanding across teams.

2.Builds on Scrum-Minimize need for teams to un-learn / re-learn.

3.Minimal addition of new roles-Minimizes complexity of explaining new roles, new training, confusion.

4.Customer-Centric, Product Teams-Aligns teams to a shared, elevating true north.

5.Single Product Owner-Avoids disconnects between PO-teams & PO -proxies.

6.Single shared Backlog for all Teams-Creates a single, unifying source of shared work.

7.Shared Definition of Done-Creates single, shared, transparent standard of quality.

8.Shared Backlog Refinement with Team Reps-Identifies dependencies, aligns teams, reduces risk.

9.Shared Sprint Planning-Identifies dependencies, creates alignment & plan.

10.Shared Daily Scrum-Enables daily course corrections, daily integration.

11.Single PSI each Sprint-Minimizes risk, reduces cycle time, increases value.

12.Shared Sprint Review-Enables stakeholder feedback & course correction.

13.Shared Retrospective-Enables shared learning, course correction, reduces risk.

14.Ease of learning via free online resources-Enables self-paced learning, shared understanding.

15.Certification detached from training-Enables validation of learning, shared understanding.


Here is another way to compare the three scaling frameworks based on my 15 fundamental beliefs about scaling. Once again you would probably need to zoom in if your eyes are as bad as mine, to make sense of this eye-chart...


Based on my highly subjective assessment, here are the scores for the 3 frameworks...

  1. LeSS - 258 points
  2. SAFe - 130 points
  3. Nexus - 260 points

My recommendation is Nexus, but there may not be a one size fits all framework for everyone.


Some advice on when it may be appropriate to use each framework...


USE WHEN: There is strong C-level support, you can change org structure, people hate prescription, there is high Agile Maturity in Management and teams

START WITH: LeSS Rules, pull in practices from the LeSS Works Framework

AND: Provide job safety to Project / Program Managers & consider Daily Scrum for ‘shu’ teams struggling to self-organize to resolve integration issues.

Essential SAFe

USE WHEN: People hate ambiguity and want maximum detail up-front.

START WITHEssential SAFe pull in practices from SAFe Big Picture gradually.

AND: Consider adding ART DOD, ART Sprint Planning with team reps, ART Daily Scrum with team reps, ART Backlog Refinement with Team Reps, ART Retro with team reps. Manage mis-alignment between Product Manager & Team level Product Owners. Manage mis-use of I/P Iteration as an enabler for big-bang hardening / stabilization phase.


USE WHEN: Teams have varying levels of Agile Maturity and are OK with some prescription.

START WITH: Nexus Guide, pull in practices from case studies and resources

AND: Complement the intentional minimal guidance with practices for your context. Encourage self-study, free practice assessments and online certification to validate shared understanding of framework.


If you would like to see my slides, you can review them on Slides on SlideShare.

Hope this helps provide a structured approach towards comparing scaling frameworks. Just don't confuse the baby (organizational value) with the car-seat (scaling framework).

Scrum On!

What did you think about this post?