Yesterday I made the case that agile software development cannot grow to large scales. But obviously we have many companies with multiple agile teams. What gives?

While it may not be possible to scale agile, it’s certainly possible to run multiple agile teams in parallel.

Each team must have its own autonomy (i.e. be self-organized). Each team should talk to customers, etc. Each team should reflect on how it can improve, etc. Everything that the agile manifesto talks about.

How is this different than scaling agile?

That’s a great question. And to some extent, it does boil down to semantics. But I think the semantics are important here, because they are so frequently (usually) lost entirely.

In my mind, “agility” boils down to two closely related things:

1. The ability to change quickly.
2. The ability to make decisions locally (which is really just the key enabler for #1).

Frameworks which seek to organize agile teams tend to (in my experience) inhibit both of these, and thus are failing to “scale” agile. That’s not to say all frameworks are bad, but by design, they seek to limit freedom (ideally, in a good way). The danger thus comes when a framework begins to limit, rather than enable, agility. It’s like the story of the Goose that Laid the Golden Eggs: the very attempt to replicate the object of desire destroys that which we desire.

Obviously, there are large companies that are successfully achieving agility on many teams (or at least they purport to do so). What makes these companies successful?

I believe it’s the fact that each team, individually, is being agile. It’s agile in parallel, not agile at scale.

The book Team of Teams: New Rules of Engagement for a Complex World is a good case study of this sort of “agile in parallel” concept in practice, in the context of a number of large organizations, from the US Military to NASA.