Agile scaling frameworks – why do they exist and which ones are there?

Bashing agile scaling frameworks like SAFe, LeSS, or NEXUS seems to be all the rage right now. It’s easy to do so. They often seem convoluted and opposed to the original agile spirit. I am also not their biggest fan. But I can acknowledge that there are reasons why they exist. In my mind the discussions around agile scaling frameworks are not nuanced enough and ignore the realities often present in companies applying them.

In the next few articles I want to introduce those agile scaling frameworks I have experienced first hand (SAFe and LeSS) and learn about the others that are out there. Today, I want to first give an overview of the most popular ones. To start, I want to explore why they exist.

The reasons agile scaling frameworks exist

In a nutshell, I believe agile scaling frameworks satisfy the needs of a particular type of company while offering a first step along a path towards more modern product development. They are easier to implement than overhauling the company culture or the product architecture.

To illustrate, let’s look at how product development could be and compare it to how it often is. 

Product development in an ideal world

In an ideal world, each product team within an organization is completely independent from others and has a clear outcome it is trying to achieve. Minimizing dependencies means the team can move fast. Providing clear outcomes means the team is empowered to define its own solutions. Leadership’s role is to provide enough strategic context (without resorting to micromanagement) so that the independent teams’ work supports the overall company goals.

The teams’ work is reflected in various leading and lagging indicators and shows up in high level KPIs. Monitoring those and reacting to changes or problems is in theory then all that needs to be done.  

In this world there is no need for agile scaling frameworks. The system regulates itself. Unfortunately, this world is not the reality for most companies.      

Product development in the real world

My guess is that the typical companies that apply agile scaling frameworks are big corporations that have been around for decades. Software is likely not at the center of their business  – or it wasn’t in the past. Product development in those companies can be very different than described above. 

Companies with 10.000 or 100.000 people distributed across the globe are challenging to align. Excellent leaders and managers are necessary to do so and good ones are hard to find! Structured approaches and rigid processes are the way they still manage to coordinate all the efforts (most of the time). This means bureaucracy that may also be increased by regulatory requirements.

These corporations often have little software expertise and/or use software that grew over decades. The architecture has become so complex that eliminating dependencies between teams is almost impossible and release cycles are long. 

Speaking of release cycles, their main business may not be digital products but selling physical goods. Those often have significantly longer development cycles. For example, creating the tooling for die casting can easily take half a year. Iterating with rapid feedback loops is challenging in this context.

Changing culture or architecture are harder than implementing an agile scaling framework

Furthermore, corporations of this size are resistant to change. Human nature, political dynamics, and the incentive structure are the causes of this. Changing the leadership culture from old-school command and control to an approach centered around coaching and empowerment is an arduous undertaking. 

Anybody that works in a big corporation has stories to tell about culture change initiatives that they had to endure. Every few years it seems like the next big wave rolls around. Some people truly believe that it is necessary and push for change. Many oppose it, some go along. Some don’t truly believe but jump on the bandwagon as a means to forward their career. Regardless, many change initiatives fail. 

Rewriting old business software that sometimes grew over decades is also no small task, as anyone that has worked on projects to redevelop a big monolith can attest (🙋‍♂️). While there are smart ways to do so, the projects often take years and there is no guarantee that the results will lead to better outcomes.

Considering that changing culture and removing dependencies between teams caused by underlying software architecture is incredibly difficult, one can see the allure of LeSS, SAFe, NEXUS, and the other agile scaling framework. They offer a structured approach to addressing complexity and serve the needs of the typical company applying one of the agile scaling frameworks.  

I am not trying to advocate for companies to apply agile scaling frameworks. Empowering teams through mindset and culture change and the accompanying product architecture is the better approach in the long run. But this is hard. I do want to create an understanding for companies that apply agile scaling frameworks. They represent a step in the right direction towards more effective and efficient – agile – product development but still satisfy the needs of the old organization. 

The most common agile scaling frameworks

I want to now give a high level overview of the most frequently used frameworks (according to my anecdata). I will cover these five. They don’t differ that much from one another.

• Scrum of Scrums
• SAFe
• LeSS
• NEXUS
• Shape up

Scrum of Scrums

It seems to me most of the agile scaling frameworks are a version of the Scrum of Scrums idea. So I want to start by introducing this idea of having “meta Scrum teams”.

The basic idea is that the individual Scrum teams work as they always would. Individual team members, often the POs or Scrum Masters of each team, take part in an additional Scrum team. This meta Scrum team ensures that the teams’ activities are aligned, resolves dependencies, and removes impediments.

At minimum, the team members take part in a separate round of daily Scrums (that in my experience don’t have to be daily). And the meta Scrum process may also include the other Scrum meetings, depending on the circumstances. So you may end up with a planning session one level higher in abstraction where the participants ensure that teams are not blocking each other in the upcoming sprint. The larger the organization the more layers of Scrum teams it will have.

SAFe

SAFe which stands for Scaled Agile Framework seems to be the most popular of the frameworks. It is based on 10 Lean-Agile principles and introduces various roles and new elements.

Scrum teams are at the center of this framework. Eight to twelve of them are part of an Agile Release Train (ART). Although the teams still have their bi-weekly Scrum cycles. The ART delivers Program Increments (PI) every 8-12 weeks. That is also when the teams come together for several days of PI Planning. 

Depending on the size of the organization, several ARTs may be present and SAFe offers the option to coordinate them on a portfolio level. 

LeSS

Large-Scale Scrum or LeSS is not as structured as SAFe but the underlying principles are very similar. 

The basic version of LeSS is intended for up to eight teams. Those eight teams work on one product backlog and there is only one product owner that has more or less the same responsibilities as in regular Scrum. The teams themselves work as they would in regular Scrum.

The difference lies in some additional meetings at the beginning and end of the sprint. First, there are two planning meetings. An initial sprint planning where representatives of all teams participate to determine on a high level the sprint backlogs for each team. Then, there is a second planning for the individual teams where each team plans its own sprint. 

At the end of the sprint there is a joint review with all teams, followed by retrospectives for each team individually. Finally, there is an overall retro where representatives of each team take part. If necessary, there may also be product backlog refinements where multiple teams take part. 

LeSS Huge exists to align more than eight teams. It stacks multiple LeSS frameworks on top of each other. There is still only one overall PO and one overall product backlog but Area Product Owners are responsible for subsets of it called Area Product Backlogs, one for each LeSS framework.  

Nexus

One of the creators of Scrum, Ken Schwaber, created the Nexus Guide. (The other, Jeff Sutherland, created Scrum@Scale, which is very similar to Nexus but doesn’t seem as popular). A Nexus is a group of three to nine Scrum teams that work on a single product backlog with a single product owner.

Again, it builds on the regular Scrum framework and adds some elements. First, there is a cross-team refinement for dealing with dependencies if necessary. Then, the sprint starts with a Nexus sprint planning where team representatives and the PO participate to produce an overall Nexus sprint backlog and individual sprint backlogs for each team, along with the corresponding overall and individual sprint goals.  

Nexus also adds the so-called Nexus daily Scrum that is nothing more than a Scrum of Scrums to deal with cross team issues. Finally, there is a Nexus integration team consisting of the Product Owner, Scrum Master, and team representatives. This integration team is there to support and coach where necessary, so that the teams are able to produce valuable, useful Increments at least once per sprint. 

There is only one overall Nexus sprint review and retro for all teams. 

Shape Up 

Shape Up from Basecamp is different from the other frameworks covered so far. Scrum is not part of it – although I imagine individual teams might still use Scrum if they want to – and it doesn’t mention agile. But I do think it carries the agile spirit. 

Shape up consists of the three phases shaping, betting and building. It runs on six week cycles with two week cool-off periods between the cycles. 

Shaping and building happen during the six week cycle in parallel. While the product teams build, a small senior group “shapes” projects that will be assigned to teams for building in the next cycle. Shaping needs to be in such a way that these projects have the right level of abstraction. Sufficiently concrete for teams to know what to do but abstract enough so that the teams have enough freedom to work out the details. 

During the building periods, the team has full responsibility to define their own tasks, make adjustments to the scope and build vertical slices of the product. They iteratively work their way towards a solution and should deliver a first version as soon as possible.  

During cool-down teams are free to work on what they want and the betting table takes place. This betting table is where proposals for what to build (that have been shaped in the previous cycle) are pitched and decisions are made on what to build next. 

Every project that is included needs to be done in six weeks. There is no extension of this deadline. There is also no interruption of the building teams during the six week cycle unless it is truly a crisis. 

Do whatever works for your circumstances

I had never thought I would write an article making the case for agile scaling frameworks. I genuinely try to avoid them in my daily work. Nevertheless, I think bashing these frameworks is so easy that it has gotten out of hand. There is a reason for their existence. And it’s important to acknowledge that implementing one is likely a step in the right direction. 

As always though, we tend to focus too much on specific practices, methods, tools, and frameworks. The underlying principles are what is important. So whatever makes your teams move closer to your users is good. Whatever makes your teams deliver in smaller increments is good. Whatever makes your teams less frustrated is good. You can achieve all of this with or without an agile scaling framework. Try something, see what works in your circumstances and adapt. That’s the key.