Agile development is a software development methodology that has been embraced as a highly effective antidote to the workflow bottlenecks that can result from the traditional Waterfall alternative and once cost organisations huge amounts of time and money. Most modern software development projects of any scale take some kind of Agile approach.

However, standard Agile frameworks also have scalability issues because they are designed for teams of up to a maximum of 9 members. In response, a number of scaled Agile frameworks were designed to allow for the coordination of multiple Agile teams working on different parts of one larger software system. All the advantages of Agile but while addressing the scalability issue.

In this blog, we’ll delve into the details of the most popular scaled agile frameworks used to coordinate multiple teams, which is best suited to which conditions, and a practical guide to effective implementation.

The scalability problem of standard Agile frameworks

The problem with standard Agile frameworks such as Scrum, Lean and the Kanban method, is that they only allow for teams consisting of 5-9 individuals. While that upper limit can of course be ignored, doing so would largely defeat the purpose of adopting an Agile framework designed for it. And inevitably impact the efficiency and quality of work.

But a team of 5-9 software developers may be much too small to handle the amount of work represented by a large, complex development project intended for release in the foreseeable future. As a result, many organisations have more, sometimes many more, than just one Agile software development team working on different parts of large projects.

However, failure to effectively synchronise the workflows of multiple teams leads responsible for different parts of one software system leads to exactly the same kind of expensive bottlenecks all too frequently encountered in the pre-Agile era. A new kind of approach to Agile was needed to effectively scale the methodology – scaled Agile frameworks.

The most established and popular scaled Agile frameworks are:

• SAFe (Scaled Agile Framework)
• DAD (Disciplined Agile Delivery)
• SoS (Scrum-of-Scrums)
• LeSS (Large-Scale Scrum)

Each of these approaches has been designed to facilitate the increase in the speed and quality of software development associated with Agile in the context of more than one Agile team working on the same project. But the conditions under which each will be the most effective methodology vary as well as there being an element of personal preference.

We’ll explore each of these distinct scaled Agile frameworks, setting out their strengths and weaknesses and the kind of agile software development project they are best suited to in greater detail. But first, let’s take a quick look at how they evolved.

Innovation, development and evolution have been demonstrated to show notable acceleration in the context of a stressful and pressurised ‘needs must’ environment. War has brought untold misery to humanity. However, it is also no coincidence that it, and just the threat of war, has also been the catalysts for a huge percentage of the most significant technological innovations in the history of human civilisation.

While Agile software development teams and their management are fortunately rarely forced to work within a military context, they do often work under significant pressure. And pressure situations that have thrown up the need to find the most effective solution to avoiding productivity bottlenecks have historically led to the evolution of new scaled Agile frameworks that deal better with the particular context.

Since the publication of the Agile Manifesto in 2001, countless software development teams have been trained on, and work to an Agile approach. But Agile frameworks focused on smallish software development projects involving a single team.

The 2007 publication of “The Enterprise and Scrum” by Ken Schwaber was a response to the growing adoption of Agile by larger companies and the application of the methodology within the context of bigger, more complex software development projects. More specific scaled Agile frameworks that addressed the particular needs of different multi-team development scenarios followed with 2008 publication of the LeSS (Large-Scale Scrum) methodology by Larman and Bodde, followed in 2011 by Dean Leffingwell’s SAFe (Scaled Agile Framework).

These scaled agile frameworks focus on synchronising multiple teams working on the same project as well as the integration of support teams using the Kanban methodology.

*Kanban is a visual workflow management methodology pioneered by Toyota in the 1940s. The highly visual qualities of a Kanban approach facilitates better communicate on what work must be done and when. It also standardises cues and refines processes, reducing waste and maximising value.

Scrum frameworks are typically used in complex environments where cause and effect are not always immediately obvious and outcomes unpredictable. The Kanban approach is used for complicated systems based on rules and deterministic processes. Both can be used, or combined, as a scaled Agile framework. 

Each of the popular scaled Agile frameworks we’ll look at here has its particular strengths and inevitable weaknesses. But which best suits the different kinds of projects that your development teams might work on? Let’s profile the 4 the four core scaled Agile frameworks, breaking down their key qualities, strengths and weaknesses. Specific development project circumstances might also mean the best methodology can be a blend of the approaches and techniques typical of one or the other of these frameworks, so don’t be afraid to work to a hybrid model where appropriate.

• An integrated set of engineering practices
• Standardisation of planning and execution process synchronisation between a large number of agile development teams
• Definition and standardisation of roles in large scale enterprises with multiple levels of hierarchy
• Quick launch without changing company’s structure
• Possibility to choose Agile framework (Scrum, Kanban, XP, etc) on the agile development team level

SAFe risks and weaknesses

• Multiple hierarchy levels
• Accused of not being “Agile enough”
• Rigid

SAFe use cases

Intel implemented SAFe into its software development processes between 2012-14 in order to scale five Scrum teams working on a single project to 33 between 2012 and 2013. And then to 170 Scrum teams by 2014. Development was completed over 2-week sprints and 8 Release Trains (ART) were deployed within only 2 months.

Hewlett Packard, Swisscom, Cisco, Tomtom, Sony, Fitbit, KLM, Philips are just some of the other big names to have adopted the SAFe.

When & where to apply SAFe

SAFe is recommended for big companies with multiple large development projects running concurrently. 

True LeSS adoption can, however, be a challenge and usually requires investment in organisational change and the education of individuals as well as an Agile mindset shift on a personal level.

LeSS Advantages

• Minimal set of rules
• Strong Product Ownership scaling potential
• Facilitates an innovative, open-minded and motivated environment
• Promotes strong principle alignment
• Provides distinct models for medium and large organizations: LeSS and LeSS Huge

LeSS risks and weaknesses

• “Radically agile” approach
• Opposition often encountered from middle-management jostling for influence
• Difficult to integrate into big traditional organisations with multiple layers of hierarchy

LeSS use cases

Interestingly, one of the biggest and best examples of LeSS adoption is that of Nokia Networks. It was initiated in 2005 by Craig Larman and Bas Vodde, who originally developed the LeSS framework, via a Scrum pilot. Nokia subsequently adopted LeSS at an organizational level in 2007, incorporating tens of Agile software development teams totalling circa. 500 people across two R&D sites. Nokia’s was a LeSS Huge scaled Agile framework deployed “by the book” with Requirement Areas, Area Product Owners, Feature Teams, etc.

Other notable companies that have adopted LeSS and LeSS huge scaled agile frameworks include Huawei, Ericsson, JP Morgan Chase, Bank of America, UBS and Telecom Australia.

When & where to apply LeSS

LeSS is recommended for medium-sized companies working on their own product or start-up, or the R&D departments of larger enterprises. As it focuses on feature teams instead of functional teams, the LeSS approach means agile software development teams are able to work faster.

SoS focuses on cross-team dependencies for established Scrum teams. The methodology is not considered a scaled Agile framework approach in the true sense by some but it is successfully used by a huge number of major organisations to scale Agile teams. So…

SoS Advantages

• Simplicity
• Does not require additional roles
• Low cost of implementation

SoS Risks/Concerns

• Limitations in scaling and documentation
• Imperfect solution to inter-team dependencies on a larger scale
• Possibility of roll-back towards status meetings

Scrum of Scrums (SoS) use cases

The first fully documented example of the Scrum approach to Agile being scaled was at IDX Systems in 1996, 5 years before the Agile Manifesto was even published. IDX’s approach was to turn the entire organization into the kind of interlocking set of Scrums in a way that was pretty similar to what became known as the Scrum-of-Scrums framework. Every part of the organization was team-based, including the management team, which included VPs, directors and architects.

When & where to apply SoS

SoS is only recommended for projects involving a limited number Agile development teams, usually up to 3 or 4.

Currently, the SAFe Scaled Agile Framework is the most used of the four most popular methodologies. Data presented by the 15th State of Agile annual report indicates that the framework accounted for 37% of all scaled Agile methodologies adopted by organisations in 2020, followed by SoS on 9%, Enterprise Scrum on 6% and the Spotify Model on 5%.

As Agile development is iterative & incremental, it is strictly context-based and the most effective framework to adopt will be different depending upon the particular situation. When choosing a framework to scale multiple Agile teams, it is often advisable to take a flexible approach, choosing a skeleton of basics and principles that can then be adapted to the particularities of the case inhand.

One of the best examples of how a company tailored a scaled Agile methodology to their specific needs is that of Spotify, the Stockholm-based music streaming start-up that ‘disrupted’ the legacy music industry and is, as of mid-December 2021, now worth $44 billion.

Customising your own scaled Agile Framework – the Spotify Model case study

Spotify identified a number of elements of the Scrum framework that weren’t working well for them. So they decided to break away from some Scrum roles, artifacts and events. That resulted in their own tailored scaled Agile framework now referred to as the ‘Spotify Model’. And, says the 15th State of Agile report, Spotify’s redesign of scaled Scrum is now the 3rd most used scaled Agile framework internationally.

However, while the Spotify Model is definitely a great example of how to tailor a scaled Agile framework to the needs of a specific context, copy and pasting it might well be a mistake for many other organisations. Why? There are several complications that make it a difficult methodology to integrate without wholesale organisational reform. One challenge is the need to set up a ‘squad’ – an independent group of people, self-empowered but working together in the same location.

The Spotify Model could also be the perfect fit for your organisation. There’s no one-size-fits-all right answer. Whether you choose to adopt an “off-the-shelf” scaled Agile methodology or tailor your own as a pick-and-mix from several or even with your own new twists, the important thing is to first consider carefully why it’s the right approach for your organisation as a whole or a particular project. And then monitor and adapt it as experience teaches you what is working well and what isn’t. It is, after all, an Agile framework and adaptability should be built into the mindset of its adoption.

In summary, as vanilla “Agile” development doesn’t naturally scale well, large organisations tend to scale Scrum to an Enterprise Level. And that’s the basis for all scaled Agile frameworks. Scaling Agile can bring numerous benefits to large corporations and other organisations that need to coordinate multiple development teams. However, as with most organisational and project management or facilitation frameworks, scaled Agile isn’t necessarily always, or even often, implemented and executed especially well.

But done well, placing the emphasis on collaboration, transparency and trust among Agile development teams and management, through your scaled Agile framework of choice can significantly boost employee engagement, improve productivity, speed up time to market and generally lead to better quality software products.

However, to achieve maximum benefit, ensure you’ve chosen the most appropriate scaled Agile framework for your unique context:

• SAFe is holistic, but it comes with multiple levels of hierarchy, and as a result, can be rigid;
• LeSS embodies a minimalistic set of rules and lets you create an innovative, open-minded and motivating environment but big organisations with several layers of hierarchy will find fully adopting it difficult.
• SoS is simple and cheap to implement but is limited when it comes to scalability and documentation.
• Look into the Spotify Model and Enterprise Scrum adaptations too.

All thing considered, which of these scaled Agile frameworks would you choose? Or which mix of components from more than one? Not sure? K&C has a wealth of experience across the hundreds of Agile development projects we’ve worked on, covering the full spectrum of scale and complexity. If you think you might be able to leverage that experience, please do get in touch. We’d love to hear details of your upcoming projects or more general organisational Agile challenges. We might even be able to help!