5 Misconceptions About Scaling Agile

When you hear the term "scaling Agile," what comes to mind? For many people, the first thing that comes to mind is doing everything bigger and faster—throwing more people onto a team of agile teams in order to speed things up. However, this is just one of the many misconceptions about scaling Agile.

In reality, scaling Agile is not a one-size-fits-all solution. Every organization is different, and therefore each organization will need to adapt Agile to their own unique needs. It’s also important to have a clear scaling strategy before starting to scale Agile; trying to wing it can lead to disaster.

And finally, experimentation is key when it comes to scaling Agile. There is no one right way to do it, so you’ll need to try a variety of different approaches until you find what works best for your organization. So don’t be afraid to experiment – it’s the only way to find out what works for you.

Here are five of the most common misconceptions about scaling Agile:

1. Scaling Agile means doing everything bigger and faster
2. You can’t just add more people to an agile team and expect it to work
3. Scaling Agile is a one-size-fits-all solution
4. It’s important to have a clear scaling strategy before starting to scale Agile
5. There’s no “right” way to scale Agile—experimentation is key

Photo by Hanna Morris on Unsplash

Scaling Agile means doing everything bigger and faster

Refining big things into smaller things, then working on the most valuable smaller things with focus, is what Agile is all about. That does not change when you use Agile at scale. If anything, it becomes even more important. So, scaling Agile means doing everything smaller and faster. As one of the Agile principles clearly states, "Simplicity—the art of maximizing the amount of work not done—is essential." Even as we are creating big things, we keep looking for options to "trim the tail." By refining big things into an ordered list of smaller things, we create the option to do just that, to "trim the tail" of remaining options after we have delivered the most valuable ones.

You can’t just add more people to an agile team and expect it to work

As Frederick P. Brooks mentioned in his 1975 book The Mythical Man-Month, "Adding manpower to a late software project, makes it later." Sadly, doing so before the project is late, runs the same risk. Always start small, with one to three teams. Then scale up as data analytics dictate. Be realistic. Keep looking at the data. When you see the numbers go down again after adding yet another team, you have hit your scaling limit. So, scale back down again. If that means you can’t make the deadline, good. You should probably tell someone. And figure out what to do next. Maybe "trim the tail" a little.

Scaling Agile is a one-size-fits-all solution

Every organization is different. Every situation is different. As much as we would like to find a standard solution, a best practice, for the complex problems we are facing, to quote Chris Williams from the Badass Agile podcast: "If there was a formula, we’d all be using it." Agile scaling frameworks can be tremendously helpful, but only as sources of inspiration for experiments, not as a one-size-fits-all boilerplate solution. Here too, the trick is to make things smaller. Identify the problem to solve, think of one to three experiments that might help you solve it, then work the problem with short feedback loops.

It’s important to have a clear scaling strategy before starting to scale Agile

Trying to wing it can lead to disaster when you are scaling Agile. After all, if you scale small problems, they become big ones. To scale effectively, you need a strategy, that is, a bounded environment for action and a set of habits that will afford the maximum support to the adopted scaling policy. Many organizations opt for a scaling framework such as SAFe, LeSS, Nexus, Scrum@Scale, or Spotify to help them create scaled Scrum and Kanban teams. If you do that, be sure to hold yourself accountable to make it a habit to invite and experiment, rather than to force and implement. That will prevent you from accidentally disengaging your people and from using your scaling framework as a golden hammer.

There’s no “right” way to scale Agile—experimentation is key

As much as you need to have a clear strategy before you start to scale Agile, don’t be afraid to experiment—it’s the only way to find out what works for you. To avoid painting yourself into a corner, and to ensure the people get a say in how they are going to work, organizations would do well to use OpenSpace Agility as an implementation framework and to leverage unFIX to sharpen their thinking on a supportive organizational structure.