Frameworks for scaling agile methods

Scaling as a necessity in agile working

The current trend towards agilization is an immense challenge, especially for larger companies. Since the classic approaches Scrum and Kanban can often only be applied to a few players, scaling makes sense.

In recent years, various frameworks for scaling agile working methods have been developed and published as a solution for this. Since each model is based on its own approach and interaction between team members, not every framework is suitable for every company. In this article, you will find a presentation of each approach, including the respective advantages and disadvantages in application.

The five most important frameworks for scaling at a glance

SAFe®

Developed by Dean Leffingwell, the Scaled Agile Framework (SAFe®) is available in several configurations. It operates on three levels: Team, Portfolio, Program. The full version, Full SAFe®, is also designed for use throughout the entire company.

SAFe® combines interdisciplinary teams working with Scrum or Kanban into so-called Agile Release Trains (ART), which deliver the product incrementally. At the program level, the patterns familiar from Scrum are scaled. Again, three roles are provided: Program Manager, Release Train Engineer, System Architect. The functional package developed by the ART over several sprints is called a program increment. It is planned with all team members. In the process, the teams also clarify their dependencies on each other and record them on the program board. Among the scaling frameworks presented here, only SAFe® provides for an iteration run, which is not used for product development, but primarily as a think tank and for bug fixing. It concludes the work on a program increment. After each sprint, all participants discuss its progress and result. At the portfolio level, among other things, a chart, called a canvas here, helps prioritize the requirements (epics) that an ART has to fulfill in each case.

The strength of SAFe® lies in the multitude of lean and agile methods that support companies from strategy formation to tactical sprint planning. Compared to LeSS and Nexus, whose methodological minimalism must be supplemented by the user’s own efforts, the SAFe® offering is overabundant. Here, one should sort out before the implementation. Otherwise, you risk a methodological overkill that loses sight of the actual goal: the benefit for the customer.

LeSS

Large-Scale Scrum, curiously abbreviated as LeSS (less), was developed by Craig Larman and Bas Vodde. It scales the Scrum approach to up to eight teams working on the same product. Each team is responsible for a portion of the product features, and the skills of its members should complement each other. What makes LeSS (and Nexus, see below) special is that a single product owner provides technical guidance to all teams. There is also only one common product backlog, common sprint planning, common reviews and retrospectives. Instead of isolating themselves in their own department, teams should feel responsible for the entire product. Projects that require more than eight development teams can be managed with the extended variant LeSS Huge. Here, the product owner is assisted by several area product owners, who in turn supervise several teams.

Thanks to a flat hierarchy, decision-making paths are short at LeSS. However, the model already presupposes a high level of agility among management and technical staff. The strength of LeSS lies primarily in its ability to grow organically by forming additional teams. The repertoire of methods for keeping interdependence under control is meager. One looks in vain for help with portfolio management or strategy development. Some companies may welcome this as freedom to adapt to their own structures and processes. But it also demands a willingness to experiment on the part of the user.

Nexus

Nexus is the name of the framework developed by Ken Schwaber (scrum.org) for the development of individual products. As with LeSS, the product owner leads three to nine Scrum teams and manages a common backlog. Characteristic of Nexus is the focus on continuous integration. To this end, the classic Scrum arsenal is expanded to include roles, events and artifacts. For example, the framework provides for an integration team (Nexus integration team, NIT) consisting of the product owner, a Scrum master and representatives of the teams. The NIT analyzes integration hurdles and advises the developers on the choice and use of integration techniques. Unlike Scrum@Scale, the membership of the NIT adapts to the integration problem to be solved. In addition, Nexus introduces coordination meetings in which team representatives clarify dependencies and remove integration obstacles. A retrospective approach is used to resolve other issues that affect multiple teams.

Although Nexus extends Scrum, the framework remains a lightweight. Among other things, methods for portfolio management and strategic planning are missing.

Scrum@Scale

Unlike the frameworks mentioned above, Jeff Sutherland’s Scrum@Scale scales agile working not through fixed levels or structures, but through loose networking of teams as well as separation of responsibility for product features from responsibility for the method. Projects start with a single team of product owner, scrum master and developers. Once this team has settled in, others are formed and coordinated by a higher-level entity, the Scrum of Scrums (SoS). Product owners and scrum masters later form their own teams. The SoS of the product owners prioritizes and coordinates the work of the Scrum teams via a common backlog. A chief product owner assumes overall responsibility and coordinates with the other product owners. The SoS of Scrum Masters, on the other hand, monitors progress, is responsible for steady delivery, and takes measures to increase efficiency. At management level, two teams are also formed to pay attention to the strategic direction of agile working and promote it throughout the company.

The strengths of Scrum@Scale include organic, unlimited scalability. In addition, the user finds references to suitable metrics. The downside of arbitrary scalability is the lack of incentive to create flatter hierarchies in which the Scrum teams decide more themselves.

Spotify-Engineering-Culture

In 2012, Henrik Kniberg and Anders Ivarsson described how the streaming service Spotify keeps pace organizationally with its rapid growth and how a specific working style, the Spotify engineering culture, contributes to the company’s agility. This approach is often reduced to the organizational structure and dubbed the “Spotify model.” Yet it is only one aspect among many that are relevant when scaling. At the core are two dimensions of the organization, autonomy and alignment, and interdisciplinary teams called squads. As internal “startups,” they operate autonomously and deliver incrementally. Technically, this way of working is supported by a service-oriented architecture and automated test runs. This gives each team member the ability to roll out code. In addition, the teams are free to coordinate via an external framework.

To prevent autonomy from ending in chaos, a common direction is needed. For this purpose, squads with similar tasks are grouped into so-called tribes. The “chief” of such a tribe swears the squads in on the priority topics. Management systems such as OKR (Objectives & Key Results) are also used for this purpose. In some tribes, similarly specialized experts, such as business analysts, from the squads come together to form departments (chapters). The respective department head (chapter lead) also handles professional development for members. For initiatives above the tribal level, employees can form a “guild.”

More important than the project methods here are the company culture and its technical underpinnings. This is what distinguishes Spotify from the other frameworks. The uniform technology, which is accessible to all, minimizes the coordination effort. This requires a lot of trust in the employees. That is why cultural factors are also in the foreground: Intrinsic motivation and a sense of security promote the joy of experimentation, which in turn enables a steep learning curve and rapid adaptation.

Too many choices

So which framework should you use? The smart answer is: It depends. No framework suits all companies equally. The choice must be based on specific market conditions and problems in incrementally realizing customer value. Taiichi Ōno, inventor of the production system at Toyota, saw it this way: “Don’t look at others – think for yourself! Keep doing it until you solve the problem.” Applied to the choice of a scaling framework, this means that companies should not misunderstand a framework as a blueprint. Rather, the model requires constant reflection and adaptation. Its true value is revealed as a source of inspiration that reveals patterns by which product development or the entire company can be scaled. For all the differences we have highlighted in this article, potential users should keep one overarching aspect in mind: Ultimately, it’s about a culture where teamwork matters more than heroism. A culture in which everyone feels responsible for the product. In which continuous learning is more important than the illusion of being error-free, and management encourages employees to experiment in the interest of customer benefit. Every company has to find its own way into this culture. Consileon supports them holistically and systematically – also in choosing the appropriate patterns and frameworks.

Under the following link you will find another table as an overview of the advantages and limitations of the individual models. It also contains information on how to proceed with the implementation.

Download chart here

Our expert for scaling agile methods

Miljenko Jazvac is one of our experts when it comes to agile working. As a certified Scrum Master, he drives agile projects both internally at Consileon and for our customers.

Miljenko Jazvac

Principal at Consileon
+49 5361 3865-110
miljenko.jazvac@consileon.de