Agile Scaling Frameworks: When to Use Which

In this post, we’ll examine the evolution of Agile at scale and survey a few available large-scale Agile development models. Finally, we'll look at why one might favor a particular framework in their organization.

What Is Scaling Agile?

Agile at scale is a transformational business process that replaces a top-down project management with leaner, more collaborative, and more incremental development across an organization. Scaling Agile frameworks, such as SAFe, provide workflow and organizational guidance to organizations that want to expand lean and Agile development methodologies beyond the team or department level. The end goal is to streamline work processes in order to outperform competitors.

Why Agile at Scale?

With increased buy-in at the executive level, we’re seeing more full-blown change initiatives than the typical gradual transformations seen previously. Early Agile transitioning programs (if it is even right to refer to them as “organized programs”) were often small pilot projects. In which, individual development teams experimented with lean and Agile methods. When a team arrived upon a method or process that worked particularly well in their context (commonly an adapted version of scrum), the organization would then try to spread best practices internally while scaling the process to fit existing processes on the program/product level.

In comparison, today’s approach to transition looks very different. The scope of Agile transformation programs are expected to impact not only the development organization but the company as a whole and its customer interface. The mandate of change agents have grown. They’ve moved beyond changing the way we think and work in the development organization and transformed into the redesigning of major parts of the company. This translates to changing reporting lines, relocating people, rebuilding the office space, and doing whatever it takes to get the company to a more Agile state.

Needless, managers in these ambitious organizations often feel challenged to come up with (let alone implement) a smart model for scaling Agile that aligns with their company’s products and contexts.

Watch the webinar >> The New Fundamentals of Agile at Scale

What Agile Scaling Frameworks Exist?

So, what frameworks for Agile at scale are out there? What types of product development and environment do they address most successfully?

It can be difficult to find an answer to these questions. There are few forums presenting and exploring the pros and cons of different frameworks. As a result, many Agile coaches and process consultants tend to specialize in one model and promote it as a one-size-fits-all solution.

Below is not a comprehensive and detailed list of all existing models. Instead, it is a range of options available to implement Agile at scale. It is intended to be a starting point, a source of inspiration.
 

Scaled Agile Framework (SAFe)

Let’s begin with the most obvious Agile at scale option, familiar to many large software developing/engineering company: Dean Leffingwell’s scaled-Agile framework.

There are four levels of the scaled Agile framework — Team, Program, Large Solution, and Portfolio — and it is constantly being improved.  
 

Key Features

• The framework is open source and constantly evolving.
• Describes roles and practices across team, program and portfolio level.
• Optimizes for program, not team level.
• Emphasizes close collaboration and alignment between top-level management and development organization.
• Solves core challenges of large-scale Agile — dependencies between work packages conducted by different teams —through up-front release (PSI) planning.
   

The Spotify Model

Spotify provides a digital music service with access to millions of songs. Their development organization consists of 30 teams that are spread out in three different locations. In 2012, Henrik Kniberg and Anders Ivarsson published a paper of the large-scale Agile at Spotify — an Agile at scale model that has received much attention, and been an inspiration for many.
 

Key Features

• Approach is team-centered (or “squad” as Spotify calls them). 
• Squads are cross-functional and autonomous (capable handling everything from design, development and testing to release and production on their own). 
• Squads are empowered to organize their own work and ways of working (Scrum, Kanban, and hybrid are used).
•  Dependencies between squads are few and handled through Scrum of Scrums when they occur.
• Continuous learning and innovation is handled in the format of “hack days” and group belongings (chapters and guilds) based on skillsets and interests.
   

Enterprise Agile-Waterfall

Another approach to Agile at scale is to create an Agile-Waterfall hybrid, as companies such as Schneider Electric have done. It’s particularly appropriate for enterprises creating a product with a combination of hardware and software components.
 

Key Features

• Their model allows software teams to adapt Agile practices, while hardware development (and overall product management) use a traditional Waterfall approach.
• The resulting (and very challenging) product backlog management situation is well-addressed by the model. It accommodates swift product releases by attending to feature releases planning on the software side.
• Compromise is critical. Like any other hybrid model, this Agile-Waterfall hybrid compromises some of the principles of non-hybrid methods. The Waterfall side of development lives with flexibility regarding software requirements. Likewise, Agile teams must commit to time-fixed delivery dates, cost forecasts and risk assessment.

One could argue that these models are incomparable. Not only because they represent widely different answers to the large-scale Agile challenge, but also because the challenges they address are not entirely the same.

Clearly, each was developed to solve different core problems. In the case of SAFe, this would be ensuring coordination and alignment of effort across the team, program, and portfolio level in the development organization. In Spotify’s case, the core challenge we need to address is to accelerate release cycles and boost team creativity. In the enterprise Agile-Waterfall hybrid, we need to find some compromise between the requirements for creating hardware and those for developing software. 

Read the case study >> How One Company Scaled Agile (SAFe + LeSS) With Helix Plan (formerly Hansoft)

What Are The Scaling Agile Frameworks — How Are They Different?

Remember, there is not a one-size-fits-all solution when it comes to large-scale Agile models. When deciding what large-scale Agile development model works best in a particular setting, analyze the needs and constraints of your specific case, then pick inspiration from the models developed for similar circumstances. What model works best for you will depend on many different variables, but there are some key questions you can ask yourself.

To choose the right model, consider these three important questions.

Does development have many intradependencies? 

No matter how you organize there will always be many dependencies among teams? Are your teams working towards a joint release (as opposed to being able to release independently)?

Does development have a lot of interdependencies? 

Are the conditions surrounding your development too rigid or inflexible to allow for non-time fixed releases? For embedded software and products containing both HW and SW, SW development tends to have lots of interdependencies. The same is true for distributed development and rigid contract development.

Is there a high need for creativity and innovation in development? 

Game development and other entertainment consumer products tend to have a high need for creativity and innovation. How they scale Agile must account for that. 

Based on these criteria, we can roughly place these three frameworks into their most appropriate conditions.

The axes in the figure above describe the development environment: Many vs. few intradependencies, many vs. few interdependencies, and high vs. low need for creativity and innovation.
 

SAFe — Scaled Agile Framework

High Dependencies, Low Need for Innovation

SAFe is well-suited for environments with many dependencies among teams. Practicing SAFe means spending considerable time and resources to plan and coordinate work in release/PSI meetings. This is a costly way of handling dependencies and alignment between teams. Yet, it really works.

SAFe is most suitable when the need for creativity and innovation among the developers is not top priority. If you believe that creativity and innovation spurs out of team empowerment (for example, the ability for team members to influence the content of their work and decide how they get the work done). SAFe should probably not be your choice as it prioritizes high-level team coordination and alignment over giving teams freedom to decide for themselves. 

SAFe works reasonably well for environments with high levels of interdependencies, but has not been designed seeing this as the core challenge to solve.
 

Spotify Model 

High Need for Innovation, Low Dependencies

Spotify has not prioritized dependency resolution as a core challenge. Their teams (or “squads” as they call them) are autonomous and capable of handling everything from design, development, and testing to release and production independently. Dependencies between squads are relatively few and, should they occur, handled through scrum of scrums.

Spotify’s model empowers teams that favor creativity and innovation among developers. The teams organize their own work and ways of working (eg. Scrum, Kanban, and mixed methods are used). Spotify’s model also encourages the developer to spend 10 percent of their time on “hack days” (which surely spurs creativity).

Spotify’s model is not design to primarily answer specific demands from the surrounding environment such as time fixed releases. Their light weight model is certainly one that allows for rapid release of customer value but what the release contains and when it happens is dictated by themselves and not set-in stone through contracts with someone else.
 

Enterprise Agile-Waterfall 

High Interdependencies, High Need for Innovation

This model does not invent new ways for handling dependencies across software development teams, but refers to the practices and roles of SAFe.

The Enterprise Agile-Waterfall model has been developed to address challenges from many unit interdependencies. It can handle several time-fixed milestones (that sometimes even originate from different sources).

Just like SAFe, this model doesn’t score high on the creativity/innovation parameter. The need for teams to commit to numerous fixed milestone dates is hardly something that boosts creativity among the team members.

Bringing It All Together

In the framework above, we used three key parameters: intradependencies, interdependencies, and need for creativity and innovation. These parameters are certainly not the only ones to consider when designing a large-scale Agile model for a particular context. The most important thing, however, is that those charged with selecting and creating a successful large-scale Agile approach be aware that there ARE several questions to consider. 

Learn more about Helix Plan, a proven Agile tool for large-scale frameworks.

Scale Agile for free