I’m going to the Agile 2015 conference this year. It’ll be the first time I’ve been to that conference in half a decade. Agile has been around for over 15 years now and at a certain point you feel like you’ve seen the important developments. In truth, I felt that way years ago but I kept going to agile conferences primarily to catch up with friends and colleagues and offer advice to people new to agility.

If I have to put my finger on it, though, I think that the main reason that I stopped going to agile conferences was because of a blind spot I was noticing. Most of the discussion I was hearing at the conferences was about how to “scale Agile.” It felt like the last open problem, and it’s been that way for over ten years now. As a person who was involved in Agile before it had name, I found this puzzling. Extreme Programming (XP) and Scrum were developed as small team processes and they worked well in that domain. But, rather than being satisfied with that, the industry decided that Agile must scale. After all, we want it to. How could it not?

Architecture is another area where we are constantly faced with scaling challenges. Companies start with a simple website and/or mobile app, and it's easy to handle the first few hundred users but then something happens. We find that we need more computing power and different infrastructure. We do deep surgery and re-architect the core of our application to prime it for more customers, different features and a skyrocket ride into global market dominance.

Does the architecture of the application ever look the same as it did when we started? No. But that doesn’t stop us from hoping for architectural stability. Surely after we’ve scaled to thousands of concurrent users we’ll have the architecture we need for hundreds of thousands, or millions. The alternative is too depressing. It means that we won’t have a final architecture until we reach maximum scale. Maybe we should just architect for maximum scale from the beginning. After all, architectural change is chaotic. We’re engineers. We should be able to smooth that over.

Let’s go back to process for a second. Agile started in the small and people have been trying to scale it for over a decade. Today, you can choose from Scrum Of Scrums, Scaled Agile Framework, LeSS, Spotify’s Tribes, Squads, Chapters, and Guilds, and a number of other lesser known processes. There’s no clear winner, and when you look close they all seem to be variations on a theme. They attempt to take the core of Agile and scale it up with practice tweaks - keeping the principles and values intact.

Periodically, people ask whether Agile is a cargo-cult. The simple answer is - yes. Because everything is to some degree. People find something that works and they attempt to make it work for things that it was not designed for. It’s a natural strategy to try and sometimes it works. But we shouldn’t be surprised when it falls short. Sometimes different problems require completely different solutions. Scale may be one of those problems.

There’s a interesting book by physicist Robert Laughlin called A Different Universe: Reinventing Physics from the Bottom Down. In it, he makes the case that different physical laws operate at different scales in nature and that when, for instance, we try to reconcile quantum theory with relativity we’re trying to cross a boundary that is very much like a phase transition in matter. Systems work one way at a particular scale but as we scale up we approach a boundary where a different type of organization takes hold. Water turns to ice and it’s chaotic at the boundary but once we cross over we’re in a new state with different qualities. Nature isn’t a continuum.

If you've ever watched a B-grade adventure or fantasy movie from the 1950s and any part of it takes place on water, chances are, what you are really seeing is a water tank in a studio with miniature models of boats, sailing ships, or monsters. The terrible thing is that the ruse is obvious. Six inch water ripples do not look the same as six meter ripples. And, there’s also no way that you’ll ever see ten foot tall ants in this world, much to sci-fi screenwriters' chagrin. Some biological configurations work at one scale and not another.

Despite the fact that we are surrounded by examples of structures that "don't scale." We want to believe that we can keep fundamentally the same process or architecture in place "as we scale." I think that we need to get used to the idea that scaling is different than what we may think it is. We should expect something analogous to phase transitions.

It's funny. I can’t count the number of times I’ve seen organizations with large monolithic software applications move toward SOA. It’s easy to think that we’ve learned a lesson in the industry and that services are just the new “best practice.” Surely we would’ve started with them if we were just starting development now. Actually, I think the truth is a bit more jarring. Different architectures work at different scales. Maybe we need to recognize that and understand when to leap from one to another.

The process space has similar issues. If we cargo-cult anything from the small team space into the large organization space, we’re falling prey to a blind spot. We’re missing an opportunity to re-think things and figure out what works best for small teams, interacting teams, and large-scale development. They may be quite different things.

Here’s something to think about. When was the last time you saw someone advocate different organizational structures for different sized organizations? For counter-balance, look at the number of people advocating the one right way to structure an organization - even if it is something that is supposed to be inherently adaptive like the teal organization.

Can you sense the belief in this point of view? The hope that we can find the one right form that is going to work for us at all scales? We want to believe that desperately, don’t we? We want to believe it because we want to avoid disruptive change - it’s expensive. But believing that it’s unnatural may be worse.

With realistic expectations we can plan and choose a new ways of organizing our code and ourselves to fit the scales we encounter, and find ways of transitioning between them as we grow. There's a good chance that would be a better approach than trying to extend a structure or even a set of principles to fit all scales.