The simple answer is ‘yes… but’. The Agile methodology does work at scale and I would argue that it is the best way to keep organizational complexity from crippling throughput, BUT the framework you use to implement Agile principles is slightly different. For an explanation of the difference between a methodology and a framework see my post on Agile. Here is why and how it must change:

Why 

First let’s understand why the framework must change as we look at implementing Agile in a large organization. One of the core tenants of Agile is “Individuals and interactions over processes and tools”. In a small team of two people, this works perfectly. Each person is managing 1 relationship. As a team grows the number of relationships each person must maintain grows exponentially rather than logarithmically. At 5 people, each member of the team must maintain 10 relationships, at 10 people each member must maintain 45 relationships, and at 50 people the number is 1,225. This is the fundamental reason organizations build processes and bureaucracy in the first place, because having thousands of relationships to manage is unrealistic.

This is where Agile comes in. By creating a small team you limit the number of critical relationships anyone needs to maintain inorder to get work done. In the team based concept that Agile encourages, we can look at a team as needing a single relationship to another team rather than a personal relationship between each person on both teams. For example Let’s take three teams, each with 10 people. The team approach reduces 435 relationships down to 138 relationships.

The same exponential math however still comes into play as you scale the number of teams you have, and at some point these two become cumbersome and slow down work. This is where scaling Agile comes in. In its most basic form, doing Agile at scale in a large organization is about creating a team-of-teams to once again limit the relationships a team must manage when getting work done. 

How big should a team be?

The general rule in Agile is that a team should be made up of 7 individuals, plus or minus two. Some people stretch the upper bound and say that a team can be as large at 12 and still be effective. 

How big should a team-of-teams be?

For this we turn to Dunbar’s number. Proposed by Robin Dunbar as the limit to the number of relationships a person can cognitively manage. He postulates that a human is able to effectively manage between 50 and 150 relationships. Based on this research, most experts suggest that a team-of-teams should be formed when closely linked teams constitute more than 50 individuals. This team-of-teams should never exceed 150 people, though most would encourage an upper limit of 125 so that everyone’s cognitive capabilities can remain focused on work rather than being spent on maintaining relationships. This means a team-of-teams should be comprised of between 5 and 25 teams depending on the size of each team.

How

Now that we understand the science and math behind why teams are important and how we can leverage similar efficiency gains as we grow beyond a few teams by creating teams-of-teams. Next, Let’s look at how to accomplish this. 

As Agile has been adopted across industries and organizations it has become evident that the light weight frameworks like Scrum and Kanban fall significantly short of managing the exponential complexities of larger organizations. These frameworks are powerful though and should always be used as the foundation for larger organizational agility. Additional constructs however need to be put in place to help move work through the organization in a way that creates a consistent stream of value to the customer as quickly as possible. 

As of this writing there are six frameworks at various stages of evolution that can be adopted out of the box to lead a large organization into a successful Agile state. Some of these are highly prescriptive and others are designed to be light weight in an effort to leverage the benefits of flexibility that Agile was commissioned to embody. These frameworks are:

There is one consistent theme across all of these frameworks that’s worth pointing out. They all encourage organizational agility, not just departmental agility. The power of Agile is in cross functional teams which bring together an array of perspectives to help get work done. As you scale an organization this becomes even more critical. Teams need input from sales, marketing, customer service, IT, accounting, and even HR to gain perspective so that their work achieves the larger goal of the organization. It generally does not make sense to include these resources in a team of 7 people, but when you scale to a team-of-teams, it is paramount that all business units can speak into the direction this larger team is heading. This interaction between the business and the individual teams, creates the unifying voice needed to empower individuals to make decentralized decisions that compound to bring the organizational vision to life.

How is this practically done? 

Generally speaking, Agile at scale is achieved by solidifying teams and organizing them into teams-of-teams. Then establishing ceremonies and rolls to govern the larger team-of-teams and keep all teams in sync. This allows the team-of-teams to align around a singular vision and leverage economy of scale without handcuffing it with organizational complexity and bureaucratic processes. 

Shout out to starline for the awesome header vector art!