Many people are talking about Scaling Agile, but what does that actually mean?
There are at least these different interpretations:

• • We’re doing Agile at a few teams and want to ‘scale it to the organization.’
  • We’re doing Agile for some projects and want to ‘scale the size of the projects.’
  • We’re doing Agile for a part of our value stream and want to ‘scale it to the entire value stream.’

These are quite different meanings and one is usually not a good idea, another is sometimes a good idea and one is almost always a good idea. Let’s look at each of these.

Scaling Agile Across the Organization By Spreading Team-Agile

Many companies start with Agile at the team (most often with Scrum).  Then they want to ‘scale Agile’ by spreading Scrum across the organization.  This is fine if the teams are independent.  But if the teams need to work together they are trying to scale a method that was designed for a team where a method that works across teams is needed.
Scrum of Scrums was introduced to solve this challenge, but it has proven to be insufficient. The reasons for this are:

• • • Cross-team challenges present when multiple teams work together are different from the intra-team challenges that Scrum alleviates.
    • Scrum’s method of gating work for a team (only allowing a sprint’s worth of work into the sprint) does not work as well for a group of teams with several stakeholders as it does when only one stakeholder is involved.
    • When teams learned Agile they focused on themselves and optimized for themselves.  Team-optimization was somewhat global optimization in a sense.  But now, the optimization must be for the group of teams and this means some teams will need to slow down.  They most likely won’t want to do that after learning how to go faster.

We are not suggesting that Scrum-of-Scrums can’t be useful.  But it requires two behaviors which are often not present:

• • 1. There must be a driving from business value for all work hitting the group
    2. There must be a spirit of collaboration between teams

We’re doing Agile for some projects and want to ‘scale the size of the projects.’

Making projects bigger is more scaling the project than scaling Agile.  If the project can accommodate more people in an effective way this may work.  But very often the need is for a few specialized people that are difficult, if not impossible, to find.  These include as SMEs (subject matter experts) or whoever was present when the code was written.   This type of scaling is typically ineffective.

We’re doing Agile for a part of our value stream and want to ‘scale it to the entire value stream’.

The value stream is the sequence of work from beginning to end that it takes to bring a concept into fruition. Attending to the entire value stream is important because delays in any part of it will delay the realization of business value.  Expanding Agile across the value stream is almost always a good idea.  This is a counterpoint to the first definition which is taking a team approach and scaling where one is staying at the team level, just working with more teams.

Our intention is to maximize the realization of business value, not development cycles.  Having more value steams partially in play is not as effective as making each value stream completely Agile.    Business value includes customer value, compliance issues, operations cost, risk and more.  A good first step is to get alignment across the organization as to what truly constitutes business value for the organization.

You want to have Agile at scale but not to scale Agile

It is important that we understand the difference between Agile at scale and scaling Agile. Agile at scale means the organization is Agile. It can develop, deliver and pivot quickly. But it doesn’t mean that the projects are scaled. Large projects are an anathema to Agile as are large teams and trains. Scaled Agile should help us break workflows down into small and separate value streams so as to create efficiencies and quick feedback.

Just because you can hold planning events to coordinate hundreds of people doesn’t mean you should. In fact, large projects are usually a symptom of not being able to decouple functionality or not being able to create properly organized teams.

Sometimes getting started with big planning events is all you can do. But whatever method you are using needs to help take you further. A good coach can bring a tool box of many different ways to do this so you don’t have to re-invent the wheel. No one-size fits all approach will work because organizations and their teams are different. With a good understanding of the science of Flow and a set of practices to create small, (semi-)independent teams it is possible to create a custom-fit approach that you can be confident will work for you.

In Summary

On analysis we’ve seen that there are three types of ‘scaling Agile’:

• • • Scaling team Agility across the organization – not a good idea if the problem is not with the teams but at the program level
    • Scaling the size of the projects – almost never a good idea
    • Scale Agile to the Entire Value stream – the right thing to do