Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

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

DZone's Guide to

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

Scrum Masters and Agile Coaches often have to tell POs their process is inefficient. One Scrum Master shares his 3 favorite frameworks for improving efficiency.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

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 their pre-existing opinions are correct.

However, sometimes, things don’t go the way they want. I tell them what I sincerely believe 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 scaling frameworks?

To avoid biases and get the big picture, make sure you get a 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 the delivery of valuable features and solutions that customers use.
  2. Quality‒Scale the quality of integrated features and solutions.
  3. Time to Market‒Deliver valuable features and solutions frequently and regularly.
  4. Waste‒De-scale the waste of time, effort, and money.
  5. Risk‒De-scale the exposure to uncertain, undesirable outcomes.

Top 10 Scaling Barriers

Based on my experience, these are the top 10 impediments to Scaling Business Agility that most companies face:

  1. Activity Based Scaling- Focus on scaling a number of people, teams, and rituals, and not on scaling business value.
  2. Project Thinking‒Wasting company time and money on project accounting and context switching.
  3. Siloed Teams‒Teams based on components, functional areas increasing hand-offs, and dependencies.
  4. Team Persistence‒Team composition is frequently changing, thus impeding self-organization and learning.
  5. Reactive Interactions‒Reactive, crisis-driven interactions between interdependent teams.
  6. Local Optimization‒Valuing the good of the silo over the good of the organization.
  7. Environments‒Lack of shared prod-like environments and data impedes frequent integration.
  8. Tools‒Ineffective use of tools inhibits interactions, self-organization, and learning.
  9. Policies‒Org Structure, Hiring, Performance management, Office space, and 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 and Clarity‒A 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 additions of new roles and up-front org changes ease 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 and 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, we 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 and Adoption

Here is my comparison of the 3 Scaling Frameworks on the 10 point comparison criteria based on outcomes and ease of adoption. 

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-Minimizes the need for teams to un-learn/re-learn.

3.Minimal addition of new roles-Minimizes the complexity of explaining new roles and new training, thus reducing confusion.

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

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

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

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

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

9.Shared Sprint Planning-Identifies dependencies, and creates an alignment and a plan.

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

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

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

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

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

15.Certification detached from training-Enables validation of learning and a 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 chart.

Final Assessment Scores and 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, and 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 and 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 With: Essential SAFe and 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, and ART Retro with team reps. Manage misalignment between Product Manager and Team level Product Owners. Manage misuse 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, and 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 a shared understanding of the 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!

Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

Topics:
agile ,scrum ,frameworks

Published at DZone with permission of Ravi Verma, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}