Ever since their inception some 20 years ago, agile methods have been associated with the delivery practices of small teams. Leveraging these techniques across organizations has proven to be quite a challenge, and a number of agile scaling frameworks have emerged which try to tackle this problem. These frameworks attempt to "cross the chasm" to scale, and thus enable the agile enterprise.
The "Scaled Agile Framework" (SAFe) is a popular option and perhaps the best known, although it has received significant criticism*. Its origins lie not in agile practice but in the Unified Process, a methodology which gained industry traction in the 1990's and which became something of a standard. Although iterative and broadly incremental, agile mechanisms of delivery and empirical validation were largely absent. SAFe can be seen as an industry successor to the Unified Process, and one which attempts to secure more frequent deliveries. However, it brings with it the baggage of a heavy process framework, which although extensively revised still lacks agile underpinnings at a philosophical level.
SAFe is anchored and framed by a so-called "big picture" of what a compliant implementation will look like. This generates two problems. Firstly, it encourages the perception that agile change can be templated and overlaid onto existing practices without deep and pervasive change...in other words, the foundations may be weak. Secondly, and ironically, organizations with no Unified Process legacy will find the prescriptions of the template hard to approximate...too much change in other words. Nevertheless SAFe can be an appealing option for organizations which are already vested in the Unified Process or similar methods.
Disciplined Agile Delivery (DaD) is another established option of many years standing, although it also receives criticism**. Like SAFe, its origins lie in the Unified Process rather than in agile practice. Again we see a framework that is iterative and broadly incremental but which lacks a clear philosophical foundation of agile delivery. The legacy of the Unified Process is even more apparent, and it represents a clear (though arguably logical) evolution of those same ideas.
Two more thoroughly agile scaling frameworks have also gained industry exposure. These are Large Scale Scrum (LeSS) and Nexus. Both use Scrum as their underpinnings and carry the same Scrum philosophy through to enterprise scale. The emphasis is squarely on the agile delivery of fully integrated and tested increments of release quality, at least once a month. These frameworks are highly product focused and are, in effect, designed to solve the problem of coordinating the dependencies of multiple teams which draw work from the same Product Backlog. The LeSS framework comes in two variants. Up to 8 teams are supported in the standard version. The second LeSS variant (LeSS "Huge") is intended for scaling agile practice across dozens of teams and is somewhat more complex to apply. The Nexus framework supports scaling up to nine teams but is otherwise comparable to LeSS in standard form. Both LeSS and Nexus are well suited for organizations with prior investment in Scrum and which intend to scale these practices using the same philosophy.
Another approach, which has some of the characteristics of a scaling framework, is the "Spotify" model. This also has its origins in agile methods at small-scale, and it has taken the much misunderstood "Scrum of Scrums" technique to a more rigorous level of application. There are many ideas and practices within this model which can be harvested even when other frameworks are sponsored.
Which framework to choose will, therefore, depend upon a number of factors, including legacy methods and practices and organizational aspirations for the future. Above all, however, it depends upon the depth, breadth, and quality of sponsorship which can be secured. Not all agile scaling frameworks are equal and some are indeed "more agile" than others...but if the need and urgency for change is left unclear, a transformation can be expected to fail regardless of the framework or target operating model chosen.