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.

SO PLEASE READ THIS BLOG ONLY IF...

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.

THREE CANDIDATE SCALING FRAMEWORKS

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

LeSS 

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

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.

ALWAYS ASK THE TEAMS

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

TOP 5 SCALING OUTCOMES

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

TOP 10 SCALING BARRIERS

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

TOP SCALING CAVEATS

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.

FACTORS THAT ENABLE ADOPTION

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

CRITERIA BASED ON SCALING OUTCOMES & EASE OF ADOPTION

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

RATING SCALE

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

COMPARISON BASED ON SCALING OUTCOMES & ADOPTION

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

CRITERIA BASED ON MY SCALING BELIEFS

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.

COMPARISON BASED ON MY SCALING BELIEFS

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

FINAL ASSESSMENT SCORES & MY RECOMMENDATION

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.

WHEN TO USE EACH FRAMEWORK

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

LeSS 

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.

Nexus

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.

WHAT NEXT

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?

Comments (14)


Darren Terrell
03:04 am April 21, 2017

Overall, I think you did a good job with this article. I would recommend removing "Certification detached from training" as a criterion due to the fact that it has nothing to do with implementing a scaling framework in an organization. Having been through LeSS (CLP) and SAFe (SPC4) training (along with having my SPS certification), I think the training is requisite to understand the nuanced portions of those frameworks.

Your point against LeSS is about the Shared Daily Scrum is not recommended. However, the concepts of Scouts, Travelers, and Component Mentors, which greatly mitigate this need, are not mentioned. LeSS also uses an advanced communication technique known as "Just Talk" that allows people/teams to communicate as needed.

For Scaling, I do not see organizational alignment as a criterion. Why did you decide against this in your assessment? I think it would be a significant factor when looking at Agile at scale.

I wish you would have left the scoring off as it tends to lead to discussions of my framework is better than yours. I believe all three are valid frameworks depending on the fluency needed within the organization doing the scaling.

Again, overall, I liked the article. Thank you for putting it together and sharing Ravi.


Naveen Kumar Singh
03:05 am April 21, 2017

I liked way you have compared these scaling frameworks. I do hear a lot about Spotify model nowadays especially in Europe. Do you consider Spotify model is a scaling framework?


Sabina Renshof
09:07 am April 21, 2017

dear all, i had to compare the scaling frameworks for a customer of mine and i used some other perspectives and variables. Then the outcome is very different. Its just the way you look at it, not an objective comparison :-). By the way: i am an PSMExpert and PSM II and SAFE SPC. I was actually hoping for a more objective comparison, which helps our customers to make a right choice, whether its scrum nexus or not? Maybe we should do this???


Sabina Renshof
09:11 am April 21, 2017

Good question!


Mark Chapman
02:04 pm April 21, 2017

The Spotify model, whilst not the same, is similar to both LeSS and Nexus in that they build on top of something like Scrum. So the idea is you start with Scrum (or whatever, Spotify allows individual teams to decide) and add the scaling parts as the teams get bigger and need them. The idea of SAFe is a prescriptive process from day one that you must follow, and this violates value one of the Agile Manifesto - "Individuals and Interactions over Processes and Tools"


Ravi Verma
03:29 pm April 21, 2017

Thanks Naveen. I know just a little bit about the Spotify model, but not enough to comment.


Ravi Verma
03:36 pm April 21, 2017

Thanks Darren for sharing your perspective.

Your points are valid. I think reasonable people can have differences of opinion - a lot of this is subjective, based on our beliefs and experiences. I respect your perspective, it's just that I have a different perspective. Both are valid.

Regarding my rationale for certification detached from training...
I believe that in many large organizations, there may not be enough time and money to send people to training. I believe that we should empirically validate the assumption that they have a strong grasp of the theoretical fundamentals of the framework. This does not eliminate the risk of varying interpretations of the framework, but may help us manage the risk.

Regarding Shared Daily Scrum:
I think mature Agile Teams will apply those practices and figure out how / when to just talk and manage integration issues. My concern was with beginner / "shu" level teams. Based on my experience, "shu" level teams may need more prescription.

Regarding organizational alignment:
You are right it is important. I provided some suggestions towards the end of the blog on characteristics of organizations which may lend themselves to one framework over another.

Regarding why I put the scoring in...
There may be a miniscule minority out there that is curious to see some #'s that may reflect my perspective. Please ignore my scores.

In general, leave anything that is not useful. I hope there are some ideas that are valuable.

Scrum On!

Ravi.


Ravi Verma
03:37 pm April 21, 2017

Absolutely! We should do it!

Thanks,
Ravi.


Bhuvan Misra
04:15 pm April 21, 2017

Have you seen the ASK Matrix? Search for "Agile Scaling Knowledge" on the web. They have compared quiet a few.


Venkatesh Rajamani
02:31 am April 22, 2017

Good insights, But DAD has come up with Scaling thoughts as well. So are we considering that in comparison.


Ravi Verma
02:44 pm April 22, 2017

Thanks Venk At. Maybe I will write a sequel using this approach to contrast DaD. Would love to see your perspective if you get a chance to write it before I do.


Ravi Verma
02:45 pm April 22, 2017

Mark,

I like what they have done with essential SAFe - reduces SAFe to only 10 prescribed elements.

What do you think about Essential SAFe compared to Big Picture SAFe?

Thanks.


Ravi Verma
02:47 pm April 22, 2017

Thanks bhuvan


Mark Chapman
05:25 pm April 22, 2017

I saw a quote from someone at a SAFe session where they discribed it as PRINCE 2 with Agile terminology. I also read a tweet from Martin Fowler where a colleague said every time he expected a feedback loop in SAFe there was someone to tell you what to do, and that pretty much sums up my feelings on it, it's "agile" for people who'd really just like good old fashioned PMO.