I think scaling frameworks get a lot of bad press and there is a perception that they don’t work. Worse than not working, some say the concept of scaling is harmful and introduces a lot of bureaucracy and waste. My goal is to look at each of the most popular scaling frameworks, understand their core intentions, and examine why the foundation companies build on aren’t mature enough to support the scale. I believe scaling frameworks contain valuable tools and guidelines that can help organizations, especially large ones, coordinate and see benefits from Agile adoption. Ultimately, this isn’t about what framework you choose to scale, but whether your foundation is solid enough in Agile principles and practices to support successful implementation.

Buckle up, this isn’t a quick read, but it may be valuable in your Agile journey.

Full disclosure, I work as a Release Train Engineer within a SAFe® framework, but I want to approach this question with as little bias as possible.

For each of these scaling models, what foundation is required to implement their framework?

The more companies move through Agile “transformations”, the more I wonder if we’re focusing enough on the basics. Large companies want to transform quickly, to start seeing the results promised by many frameworks (I’m looking at you, “twice the work in half the time”). If you’re part of a large organization, you’ve probably also considered/heard consideration of “scaling” Agile methodology. Why would a company consider scaling its implementation, when the frameworks work perfectly well at the team level? In large organizations, scaling may help engage the entire organization in Agile processes and improve adoption and implementation. Sometimes products are very large, and more than a handful of teams are required to deliver it. Could the teams work independently and coordinate through traditional methods? Probably, but scaling frameworks are meant to improve the delivery of value to the customer and streamline these types of activities.

Which brings us to the four most popular scaling models: Scaled Agile Framework® (SAFe), Nexus™ (by Scrum.org), Large Scale Scrum (TM) (LeSS), and Scrum @ Scale (by Scrum Alliance/Scrum Inc.).

Let’s agree on something, dear reader; building skyscrapers on a wet foundation makes them collapse.

From the LeSS framework overview:

“Scaling Scrum starts with understanding standard one-team Scrum.”

I haven’t worked with LeSS, but I respect this stance. An organization needs to have a solid foundation in a basic methodology before trying to scale it (or even deciding if scaling is necessary). LeSS claims, much like Nexus and Scrum @ Scale, to be a simple scaling of the standard Scrum methodology.

SAFe isn’t prescriptive either, per se, but provides “proven patterns” to implement. The start of their “implementation roadmap” shows Waterfall/ad hoc Agile, so they expect any company would be able to “Go SAFe” from a starting point of zero. SAFe tries to account for any methodology within an implementation, allowing for Scrum, Kanban, or even Waterfall teams willing to commit to the process. I’ll diverge here to make an important point about the entry level SAFe training for “standard” Scrum roles. It does not teach you, in-depth, how to be a Scrum Master or Product Owner. It teaches you how to be one of those roles within a SAFe framework. Having attended multiple training sessions, I would say if you are approaching SAFe implementation without a solid foundation of Agile training from other sources, or additional advanced SAFe training, your Scrum Masters/Kanban Leaders/Project Managers will have a tough time.

Nexus™ is from Ken Schwaber, one of the co-creators of the Scrum Guide itself. Nexus touts itself as an extension of the Scrum Guide to scale “minimally”. The guide provides roles and events for Nexus, which scales directly from Scrum itself. The expectation is to have enough foundation in Scrum to introduce these, but the guide isn’t prescriptive to say any prior practice with Scrum is required before adopting Nexus as a whole. I would make a reasonable assumption Scrum.org expects a company to solidify its team-level practice before scaling the whole, but your mileage may vary.

Scrum @ Scale, by the other co-creator of the Scrum Guide Jeff Sutherland, describes itself as being a “scale-free” way of scaling linearly. I’m assuming this is to differentiate itself from complex models like SAFe, but Scrum Alliance has always included the linear/fractal scaling of Scrum as part of their certification training. This is a codification of part of their training, with some additional recommendations. Scrum @ Scale assumes the foundation of Scrum is used to scale the framework and states, rather simply,

“…the first challenge is to create a small set of teams that implements Scrum well.”

If the foundation is the problem, why does everyone blame the scaling framework? I think people like to attach blame to added complexity. SAFe is a consistent punching bag for this kind of criticism and has tried to go out of its way in recent iterations of the framework to simplify (compared to its prior versions). Many Agile practitioners are against any form of scaling. They assume you should be able to do the work as individual collaborative teams. 

Collaborative teams? Great! Let’s take a look. What do all these frameworks depend on? Teams of teams. SAFe has Agile Release Trains, consisting of multiple teams. LeSS has a team of teams, scaling to teams of teams with “LeSS Huge”. Scrum @ Scale and Nexus both scale linearly from standard Scrum teams into teams of teams.

What are the roles in each of these teams?

Scrum Master, Product Owner, Team Member (developer or otherwise).

Starting from the foundation, they are essentially identical. All scaling models discussed have the same roles.

Is something different about their values?

• SAFe: Teams are cross-functional, the latest version includes “business” teams with the same values. Teams are “self-organizing and self-managing, accountable to deliver results…” © Scaled Agile, Inc.
• LeSS/Huge: Teams are cross-functional and self-managing. 
• Nexus and Scrum @ Scale: No specifications, because both are built on standard Scrum framework. Cross-functional and self-organizing teams.

This is all extremely consistent with Scrum, and the foundation scaled teams are built on seem to have the same values regardless of the model. Teams share work, are responsible and accountable for the delivery of their product and follow Scrum principles.

Next level up

If values don’t change at the Team level, maybe the next level up makes this all fail/removes value/adds unnecessary complexity? There is a lot of information to digest, and I dove in where others have already gone, in a once-over of the first scaling levels of each of the models from the perspective of structure, roles, artifacts, and events. This is available in a separate article so we can focus on the discussion and you can read the comparisons at your leisure. 

What’s my summary of the scaling models? Do they all start to implement unnecessary complexity and cause failure the way so many Agilists complain? Probably not. 

Depending on who you received your certification from, Scrum may have always been meant to “scale”. I received my initial training from Jeff Sutherland, and we’re taught it’s fractal and self-replicates at scale. Once you have a big enough team, you split into two teams with the same operating guidelines. Once you split into enough teams, and you need to coordinate with each other, you start having some sort of scaled communication (Scrum of Scrums, per the Scrum Alliance training). Scrum @ Scale and Nexus were both taken directly from each corporation’s training on how you could scale your implementation. To be fair, we’re also taught scaling should be simple and other models do introduce a lot of complexity. SAFe is the biggest of them all, but I believe intentions were good. Many companies have significant entrenched organizational problems to overcome to achieve large implementations, which SAFe was intended to address and overcome.

The elephant (or HiPPO) in the room

I know, I know. I only scratch the surface, talking about “one level up” from team-based Scrum. “Leadership,” some will say, “is the root of the problem.” I’m taking the view from the bottom up, but let’s make another assumption before we continue. Lack of top-down leadership support will hamper, or even kill, the chances of real adoption of any Lean/Agile practice. Most of the frameworks account for this explicitly, which is one of the reasons I’m not talking about this here. I could, and probably should spend an entirely different article talking about the challenges of getting real top-down support for any of this.

From LeSS on adoption:

Top-down or bottom-up? That’s a false dichotomy. Either one or the other by itself is likely to fail. Do both.

SAFe has “Lean-Agile Leadership” as one of their core competencies:

Lean-Agile leaders must do more than simply support the transformation: they must actively lead the change, participating in and guiding the activities necessary to understand and continuously optimize the flow of value through the enterprise. © Scaled Agile, Inc.

Scrum@Scale and Nexus both form from the bottom up, but S@S stresses the importance of executive involvement in their “Executive Action Team”, with the ultimate responsibility being very similar to the Lean-Agile Leadership concept in SAFe.

The EAT is accountable for the quality of Scrum within the organization.

Nexus does not explicitly discuss top-down commitment, beyond the Nexus Integration Team.

Scrum generally believes teams can practice the framework without having wide organizational participation or commitment. Jeff Sutherland will often tout (evidence in his book) that Scrum was practiced on a small or departmental scale to out-perform the rest of the company and pave the way for adoption. There are some basics, like the SM being able to protect the team from outside influences, but if you can minimize the harm from existing organizational design and process you can practice the framework at a team level.

This is why my focus is on the bottom up. Yes, if you don’t have strong top-down support it is likely your scaled implementation, regardless of framework, will be challenged and fail. Additionally, this disregards the cultural baggage your organization may have piled up between departments, business units, or layers of leadership. If there are conflicts between the upper levels of leadership it poses even more potential problems with top-down support for Agile adoption.

Conversely, if you have strong top-down support it doesn’t mean your teams are operating effectively within the framework. You might have strong Agile leaders scratching their heads, asking “Why aren’t we accelerating? We’re doing the right things!” all the while the teams are faltering. So, let’s put top-down aside for the moment, and focus on what I believe the most common issues are in scaling Agile.

Haters gonna hate

Are any of the scaling models “destined to fail”? SAFe has a team of teams, with a servant leader (Release Train Engineer), and centralized Product ownership (Product Management). It encourages face to face planning, and team-level commitment/accountability to work. It involves stakeholders and a regular cadence of feedback and continuous improvement. LeSS is similar but approaches it differently. The Product Owner (PO) becomes central (until it balloons out again with Area POs) but does not scale the Scrum Master role. LeSS still encourages face to face planning, team-level commitment to work, and regular feedback cycles with stakeholders. Not to give short shrift to Nexus and Scrum @ Scale, but the story is the same. All of these scaling models, ultimately, try to embody and encourage Agile principles at the next scaled level.

What’s the problem here? Why are there so many people hating even the scent of a scaled Agile implementation? Maybe it’s just so situational there’s no valid frame of reference? Some Agilists have never worked with a company with more than 500 employees. For some, they may have only worked with Fortune 100+ companies with thousands of employees and an entrenched hierarchy. Some may focus on startups where there is little cultural inertia to overcome, while others may focus on starting “agile transformation” at large corporations. If there’s one thing I’ve learned there is no one-size-fits-all for thinking about scaling. Some companies never need to scale, but for Agilists at those companies to say “scaling is worthless” it’s a very short-sighted stance. There are also plenty of practitioners involved in Agile transformations at large companies who pan any scaled Agile. But why?

My theory is most scaled implementations fail because the teams’ Agile practices, forming the basis for scaling, were not ready for prime time. Just think about the last large Agile implementation you were coaching. The company was on board, senior leaders engaged, and you started strong. The teams were hitting your guidelines on implementing Scrum, and you were starting to see some results. Then the big day. The Agile Center of Excellence/PMO/whatever your company has decided the teams have hit a level of operation ready for scaling! 

But are they ready?

Time for a litmus test

Before considering a model for scaling, scratch the surface on your teams. You may find your solid gold standard is just gold foil wrapping on bronze.

Here is an example of how this conversation might go, and how you might make sure the teams are following the intent of an Agile framework. Let’s imagine you have an Agile Program Management Office (PMO) like many companies do.

<scene>

Teams: Ok! We have our roles filled, are doing two-week sprints, and have our backlogs in order! We’re even doing reviews and retrospectives!

PMO: Well great, Teams! We’re ready to scale! I think Teams A, B, and C should be our initial groups. 

Teams: Sounds like a plan, we’ll just go and…

PMO: Wait a minute… Team A, you said your roles are filled, didn’t you need a PO as of last week?

Team A: Sure, but we couldn’t find anyone. Our Scrum Master will fill the role for now.

PMO: That… doesn’t sound like a good idea.

Team A: But we have a prioritized Backlog! The SM/PO was able to get everything squared away and the team feels great about it. 

PMO: Did you get stakeholders involved since your PO doesn’t have the background to understand all the stories?

Team A: …

PMO: Ok maybe we should do some more work with you, Team A. Teams B and C, you’re good to go?

Teams B and C: Yes, we have individual people for the two roles!

PMO: Great, then maybe we should… hold on. Team B, just curious, how dedicated are your team members to the Scrum team?

Team B: Well, the PO is 20% they’re also a Business Operations Manager. The SM is 50%, they’re also Project Manager for a couple of different projects. Our tech lead is 20%, across five different teams. We do have a couple of junior developers that are 100% dedicated though.

PMO: Uh. That sounds problematic. 

Team B: Well, it does hurt our commitments. We had to push several stories from our last Sprint into the next one, and we’re only about 40% reliable on our commitments at this point. 

PMO: Let’s work on it, have you generated any improvement ideas in your retrospectives?

Team B: … We’ve been canceling those to catch up on work. And our Sprint Reviews.

PMO: There’s a lot to unpack here. 

Team C: But we’re ready!

PMO: *stares in Scrum Master*

Team C: Ok, maybe not.

</scene>

One of my favorite quick tools for assessing Scrum practice is Henrik Kniberg’s Scrum Checklist. Its an oldie, but a goodie. It talks about the “bottom line”:

1. Delivering working, tested software every 4 weeks or less
2. Delivering what the business needs most
3. Process is continuously improving. 

You can have all of the boxes checked on the rest of the checklist, but if you’re not doing those three things then you’re not practicing the intent of Scrum/Agile development. This gets to some of the Shuhari (Shu Ha Ri) model of mastery, are teams already bending or breaking the rules before they’re ready? The bottom line above is often achieved by following a framework and moving toward an understanding of how the framework helps to deliver. None of the teams in our imaginary scenario are doing any of these three “bottom line” activities.  

Let’s get back to basics.

I looked at each of the scaling models in terms of structure, roles, artifacts, and events. Let’s combine structure and events because, for the most part, the events are the structure of Scrum. I think we should look at these together, and I’ll add some commentary on my observations of teams that seem to be hitting a stage of maturity, and what lurks beneath the surface. I’m going to give some (non-exhaustive) examples for each.

Structure/Events: Standing up the structure of Scrum seems to be the focus of organizations, without looking at the “why” behind the “what”. Each of these events/cadences is meant to do something important for the team. I describe each, though any Scrum Master needs to know what they are, and just touch on questions to evoke the “why” that is often missed during transformation.

• Sprints – Scrum breaks work into Sprints, lasting 1-4 weeks, and structures an iterative cycle around that. The teams are Sprinting along, check the box, but are the Sprints starting/ending on cadence? Are Sprints being terminated early? Is work being completed within the Sprints or is it consistently carrying over into the next Sprint?
• Product Backlog Refinement (PBR) – Refining Epics and Stories leads to a groomed Product Backlog, which is prioritized by the Product Owner (PO). Is this activity being done by the whole team? Is the PO involved? Are all the stories expected for the next Sprint ready to work (team understands the acceptance criteria, has the infrastructure to complete the work, work is sized appropriately, meet’s team’s Definition of Ready [if they use this])?
• Sprint Planning – The team meets and plans their work for the Sprint based on the work the PO brings into the Sprint Backlog. Are the stories ready [see PBR]? Is the team committing to a reasonable amount of work, taking things like defect management or maintenance into account? 
• Daily Scrum/Stand up – The team meets for a max of 15 minutes/day to talk about the day’s work. Scrum does not mandate the “three questions” but it is a common model teams use especially when starting. Is the team focusing on the work or is it a status meeting? 
• Sprint Review – At the end of each Sprint the team meets with relevant stakeholders to review the Done work and get feedback. This is often done in a “demo” mode, and the stakeholders can touch/feel the product and give immediate feedback. Is the team doing this? Was all the “Done” work validated with the Product Owner before the Review? Is the team discussing the “not Done” work? Are these feedback items making it into the Backlog?
• Retrospective – The retrospective gives the team, and only the team, the opportunity to reflect on the Sprint and collaborate on changes to make a positive impact in their work. Team members need to be able to, and be encouraged, to speak openly and honestly about challenges and frustrations. This is the check and adjust portion of the program, and I often see this being pencil whipped. Is the team having a real retrospective? Whatever format you use, is the team identifying at least one continuous improvement item each Sprint to incorporate in the next Sprint? Is the team, and ONLY the team, invited to the retrospective? Are you adapting your format to elicit new responses? Sometimes focusing a retrospective on a recurring theme is more important than asking about “what went well”. Continuous Improvement (CI) is part of everyone’s role in Scrum/Agile, and the Retrospective is how the team can focus at their level on what they can control.

Roles: Scrum dictates three roles. Scrum Master, Product Owner, and Development Team. A functioning Scrum team has these roles filled, but let’s dig into possible modifications teams tend to make. When the answer to “do you have a <role>” is “Yes, but…” that’s a red flag. One other thing to consider is that Scrum has a simple clarity when it comes to understanding what your role is on the team. If the company’s Agile transformation isn’t standard Scrum and mixes some roles, it makes it much harder to have any consensus on who is supposed to be doing what.

Scrum Master (SM) – Yes, there is an SM. The SM needs to facilitate and coach the team on the execution of the Scrum framework, protect the team from outside influences, and help the team continuously improve. Many companies seem to check the box as soon as the role of SM is created, and this person facilitates and coaches, but protecting the team and CI are often sticking points. This role focuses on CI for the team, using Retrospectives as the tool for identifying and enacting improvement. CI takes time and effort, and not everyone feels like CI is a priority. Does the SM have time? Maybe, but maybe the Scrum master is also…

• Un(der)trained – Often the SM is the most likely to have received formal Scrum training/certification. When companies are focusing on the initial “roll-out” of Agile transformation everyone seems to receive the same level of training. Once you’re past the initial period, however, the scales may tip. Are your new Scrum masters trained? If they are, is the training consistent? Conversely, if the SM shares some of the PO role (read: project management) do the SMs have the training to succeed? Often, I see a good SM be a terrible PM, and vice versa.
• Developer – This situation can certainly work, but there needs to be enough time given to the SM to do more than rote facilitation of the events. Developers can have an intimate understanding of the work of the team, but sometimes the Developer has no passion for being an SM and the appointment is meant to check the box. If your SM isn’t full time, the question I have is what proportion of their time is spent on Scrum/Agile vs operations work?
• Project Manager – The dreaded slash (SM/Project Manager, or Agile Project Manager). Similar questions as the Developer situation. How much of their time is spent making sure the team understands how to use the framework, and CI, vs how much of their time is spent doing traditional project manager activities like status reporting, financial management, and flogging the team to hit artificial deadlines? It’s hard to protect the team when you are partially in a role that the SM is supposed to protect the team from!
• Operations Manager – Scrum is not meant to equal reporting structure, but it doesn’t mean some companies don’t have the teams report to the SM. Much of this person’s time will be spent on resource management, operations management, and reporting functions. CI may fall by the wayside, and even the standard facilitation of Scrum events may fall to the Team itself in the absence of the SM. 
• Product Owner – This is the biggest red flag. The Scrum Master is sometimes also assigned as the Product Owner or is acting as a surrogate PO. Not only does this occupy a lot of the time of the Scrum Master, but it also skews the relationship with the team as the SM/PO may default to driving the team rather than working with them to continuously improve.

Product Owner – Yes, there is a PO! The PO needs to own the product backlog, make sure there is enough work groomed for the team’s upcoming Sprints, clarify requirements, and work with stakeholders on things like scope, cost, and schedule. Many traditional project manager activities fall into the PO role in Scrum. Again, many companies are happy to assign a PO and check the box on “implemented”, yet this is another “Yes, but…” situation. Maybe the PO is also…

• Un(der)trained – Problem #1 I’ve seen during Scrum implementations is when a PO is assigned, but not given a real understanding of their assignment and the work! Maybe the untrained PO isn’t managing the backlog, maybe they aren’t working with the team on refinement or understanding requirements, and maybe they are leaning heavily on the SM because the SM knows what their role is meant to do!
• Uninterested – Not all POs are created equal and a disinterested PO means they may focus on the parts of the role they like and understand, such as stakeholder management and strategic vision, and ignore the hands-on part of the job like Product Backlog Refinement (PBR) and working directly with the team.
• A Ghost – Some POs just don’t show up. Don’t show up to events, aren’t available for questions, are too busy. Usually, this is because being a PO is 10% of their “real job” which takes priority. Organizations can’t ignore the serious responsibilities of the PO.

Development Team – Yes, there are team members! It’s hard (read: impossible) to have a Scrum Team without team members. But what if the team members…

• Aren’t dedicated to the team – Are they 100%? 75%? 50%? Context switching kills productivity and introduces waste. I constantly see people split across multiple Scrum Teams, and it always hurts/kills the productivity of the entire portfolio.
• Don’t have context – “Team member” is a named role in Scrum and deserves some level of training to give the team context for why the cadence, events, and artifacts are useful tools. Teams without context feel like they can ignore the framework, or practice “zombie scrum“.

Artifacts: Scrum doesn’t have a lot of artifacts, but what it does have is essential. Much of the criticism, regarding the utilization of these artifacts, was covered in talking about the Roles primarily responsible for maintaining them, so I will try not to repeat myself here. 

• Product Backlog – I covered a lot of the Backlog in the role but reiterating the red flags could be helpful. If your Backlog doesn’t have well-defined stories, including clear acceptance criteria, prioritized and ready for the next two Sprints you probably aren’t in a good place.
• Sprint Backlog – If your Product Backlog isn’t ready, then your Sprint Backlog will be problematic. If the team takes stories into the Sprint while muttering “I guess we can work on this” then you need to spend more time on refinement and getting to at least a notional ready-to-work state.
• Increment – In Scrum terms, the increment is the block of potentially shippable product. The biggest challenge here is when teams don’t focus on completing work end-to-end during the Sprint. Not completing “potentially releasable” work during the Increment is a sign that your process needs some attention. Are you working on a vertical slice of the product? Or are you practicing Scrummerfall (“iterative Waterfall”, which is just bad Scrum)?

The same type of analysis and questioning can happen with other frameworks! I bet you thought Kanban was getting a pass. What’s the most important part of Kanban? From my perspective, Work in Progress (WIP) limits. You see your bottlenecks clearly and can work toward one-piece-flow. Your metrics will be junk, and the team is probably overwhelmed. The biggest red flag for any team working Kanban is not having WIP limits and might be your first question for any Kanban team.

Whew! We’ve gone into some detail on all of the basics, and maybe you can see where a team might look “ready” for scaling on the outside but is still very immature in their practice. For the record, this is OK! All teams start from the beginning, and the only way to get to a level of maturity is to practice, practice, practice.

Let’s Wrap Up

I think scaled frameworks are a common punching bag representing displaced blame. Reviewing multiple frameworks, I don’t think there’s anything inherently wrong with the intent behind each of them. Some are more overwrought than others but if you have a strong Agile practice I could see any of them helping keep work visible, commitment strong, and communication high in a large organization that thinks they need it.

Maybe before blaming the framework, it’s better to find out whether the foundation it is being built on is strong enough to hold it. Companies are practicing all kinds of modifications to all of the Agile frameworks. I would hazard they haven’t been practicing the basics (Shu) for very long and many of them don’t have a good understanding of the intention of the frameworks to start making those changes (Ha).

Will having a great foundation of Scrum (or Kanban) make your scaled implementation succeed? Not necessarily, but it means you’re not cutting your legs out from under you as you go. I expect this will generate a lot of feelings on different sides of the argument, but I think my biggest takeaway is you might be arguing about the wrong things.