Scaling Agile Frameworks: Creating Solutions or Scaling Problems?

When the Agile Manifesto was published in 2001, it brought together several lightweight methods under one umbrella term. Agile methodologies have since been widely adopted across technology companies, as they bring effective benefits in guiding the development and delivery of high-quality, working software.

However, Agile methodologies were designed for small teams, often between five and nine members. So what happens when companies take over massive projects that require dozens or even hundreds of people working towards one common goal? How can you apply Agile methodologies to such an environment? And how do you do it while maintaining both the quality of your output and the best practices within your team?

To answer these questions, we need to take a look at scaling Agile frameworks.

While teams execute one project at a time, organizations execute combinations of several projects that may overlap. Therefore, a scaling framework doesn’t mean replicating one Agile team’s way of working by however many teams a company has. Scaling brings its own set of challenges that need to be thoroughly analyzed by organizations, before deciding on which framework to use.

To take your organization through its first steps in scaling frameworks, consider following these guidelines:

Start with an MVP

A Minimum Viable Product (MVP) allows you to test the waters before diving deep. It gives you the chance to analyze, inspect and adjust, preventing further wasting of engineering time when things are not going in the right direction.

Create One Single Product Backlog

Having a single source of tasks for all your teams allows you to focus on the high-priority global items first.

Build a Collaborative Culture

To instigate collaboration and teamwork, consider hosting meetings that include the product owner, a developer, and a tester to review requirements and feature requests on the backlog. This encourages sharing different viewpoints while providing group consensus.

An effective way to put this into practice is by using Radical Candor, a management philosophy focused on “caring personally while challenging directly,” which contributes to the psychological safety of everyone involved and the empowerment of team members.

After these first initial steps, then it’s time to consider adopting a scaling framework.

Scrum and other Agile methodologies don’t address the challenge of scaling. To do it successfully, organizations need to look at scaling frameworks created with this goal in mind.

There are several frameworks, with inherent differences, but all with the common objective of facilitating the application of Agile methodologies to large-scale projects and organizations. Here, we will analyze some of the most common ones.

The distinctions between them are a result of different approaches to the challenges of scaling Agile. SAFe aims for minimum disruption, adapting itself to the existing organization. LeSS sees the existing organizational design as a barrier to scaling, so it’s built to address that issue. And Nexus puts its focus on developing large products with multiple teams working together.

SAFe

Scaled Agile Framework (SAFe) is one of the most popular scaling frameworks. Created by Dean Leffinwell, it is a prescriptive framework that tells organizations exactly what to do — unlike other non-prescriptive frameworks. It describes itself as a “knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.”

SAFe introduced the idea of the Agile Release Train (ART) as a way of managing work across teams of 50–125 people, led by a Release Train Engineer (RTE). This methodology consists of two and ten-week iterations that tend to be successful in organizations with a more established Agile practice.

LeSS

Large Scale Scrum (LeSS) shows “how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible.” Basically, it takes the approach of scaling up the activities in Scrum and applying them at the team-of-teams level. It uses teams as its base, reducing the role of management and favoring simplicity over strictly defined processes.

Therefore, it is more flexible than SAFe, mostly because it is non-prescriptive. It tends to be more effective in smaller projects.

Nexus

Nexus is “a framework that drives to the heart of scaling by minimizing cross-team dependencies and integration issues.” It builds upon the Scrum foundations, extending the Scrum framework in only the strictly necessary ways to enable multiple teams to work from one single Product Backlog and build one Integrated Increment.

It brings together a group of three to nine Scrum Teams that work towards the common goal of delivering a single product.

These three scaling frameworks are some of the most common, but there are other options, such as Scrum@Scale (SaS), Kanban Enterprise, or Disciplined Agile Delivery (DAD).

When done right, scaling Agile can bring a set of benefits to an organization. Mostly, it helps companies to reach the ultimate goal of delivering high-quality software. 

Benefits of Implementing a Scaling Framework

Aligning Strategy and Work
These frameworks connect the business objectives and the people implementing them, creating a cascade of effects that bring about transparency, agility, and speed, making everyone in the organization focus on producing value for customers.

Improving Capacity Management
Capacity management is about balancing availability and workload. When you use a scaling framework, you align ARTs regularly, allowing teams to focus on creating value in a flexible, agile way. 

Facilitating Planning
Scaling Agile requires coordinating people from several departments and making them work together towards a common goal. Scaling frameworks help with this by setting up teams of teams meetings, that allow to highlight potential dependencies, identify risks and create visibility to everyone involved.

Enabling Visibility Across the Company
By connecting and allowing visualization of the work from every team, scaling frameworks enable a bird’s eye view over potential issues allowing them to be tackled in time.

Engaging Employees
Scaling frameworks, as Agile methodologies do, empower employees to be responsible for their own work and make decisions. This has a direct impact on employee satisfaction which, in turn, benefits the company.

Common Issues when Scaling Agile

While there are clear benefits in companies adopting scaling frameworks, the transition is not always done the right way. Therefore, some companies end up struggling with newly generated problems, without having been able to solve the previously existing ones. Here are a few common issues when scaling Agile.

Copying Another Organization’s Model Fails to Meet the Goal
Adopting a scaling framework is not about copying a successful model and applying it to existing infrastructure without changing anything about it. This would be the route to failure. To truly implement it and reap the benefits, adopting a scaling framework requires extensive changes in the organization.

Copying What Works for One Team Fails to Work for all Teams
In the same way that a company can’t copy another organization’s model, it also cannot take what works for a team and apply it to another. While there should be common ground in the way teams work, it’s important to remember that Agile is about constant inspection and adaptation. Therefore, teams should self-organize in ways that fit them best, which might not coincide with another team’s way of working.

The Organization’s Design is Incompatible with Agility
The goal of adopting Agile is to increase adaptability to market conditions quickly, therefore delivering better results to customers. But some organizations adopt Agile without being fully aware of the impact it will have — or should have — at the enterprise level. What’s the point of having Agile teams that adapt easily if the whole internal structure of the company is not optimized for change?

Different Parts of the Organization are Independently Optimized
When scaling Agile, some companies focus on making all the existing structures work in an Agile way without connecting the different teams. They end up with multiple Agile teams that fail to work as one big team, which undermines the whole purpose. Having an Agile business analysis team, an Agile development team, and an Agile DevOps team on their own doesn’t lead to the desired outcome because none of these teams can deliver value on its own. They need to be coordinated as one big Agile team.

The Organization Doesn’t Invest in Agile Engineering Practices
While many organizations understand the importance of hiring for Agile roles, such as Scrum Master and Product Owner, they fail to invest in trainings to achieve technical agility.

Technical agility requires practices such as automation of the delivery pipeline and a decoupled architecture that allows parts of the product to be easily changed or replaced. Otherwise, technical debt will become just too big to manage, hindering agility.

 

In order to scale Agile, we cannot ignore the importance of the team. And team efficiency means more than simply adapting to Agile methodologies. To do so, let’s take a closer look at designing systems that last. 

Conway’s Law 

In 1968, mathematician and programmer Dr. Melvin Conway stated in a paper submitted to the Harvard Business Review something that would become known as “Conway’s Law”:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

This means that more than adapting their existing teams to any Agile methodology, organizations should analyze and define what kind of software architecture they need before organizing said teams. Failing to do so will lead to the realization of Conway’s Law or, as Ruth Malan puts it:

“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”

An organization that is structured on independent teams that specialize in particular tasks, such as QA or security, is unlikely to create software products with an end-to-end flow in mind, compromising the quality of the delivered product.

If an organization wants to avoid such designs, it needs to shape itself to the image of the software it wants to create. In brief, organization design and software design are more interconnected than one would think and highly impact one another.

Considering the extensive impact of Conway’s Law, how could an organization go about solving it? Enter Team Topologies.

How to Create a Team Topology

Team Topologies is a concept introduced by Manuel Pais and Matthew Skelton that describes a way of changing organizations taking into consideration Conway’s Law.

It describes ways of reducing the cognitive load from teams and directing more energy toward streams of value that flow through the company. These top-level streams are extremely important because they help teams build a shared understanding of their purpose, organizing themselves in a way that goes hand-in-hand with the software architecture design they intend to create.

A practical way to implement Team Topologies into your organization can be by following these 8 steps:

1. Identify the type of teams your organization has at the moment
2. Fit technology teams to the fundamental team types
3. Limit the cognitive load for each team
4. Use the reverse Conway maneuver
5. Identify “as-is” and “to-be” team interaction modes
6. Explicitly guide inter-team collaboration
7. Evolve team structures overtime
8. Use team interactions for organizational senses

Embracing agility is more of a process than a decision. When a company decides to adopt an Agile framework, whether a scaling one or not, this decision should be followed by change.

Agile methodologies are not quick fixes for problems. Instead, they are glasses with which to look at the way organizations structure themselves and their teams. They are also a brave step: fully implementing an Agile framework implies letting go of anything that is not working in a team and in an organization at large, and not all companies are ready to take this step — even if they all like to think so.

Regardless, when Agile is implemented correctly and regularly inspected, it can generate effective benefits that include company success, team empowerment, and quality of the delivered product.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach