There is a lot of fuzz currently going on the Agile communities around the topic of “scaling”. Why does scaling matter? Let me try to express my view on the matter.

The ongoing increasing complexity

Our whole work runs on software. Software exists in our cars, our telephones, our traffic systems, and our voting systems during elections. Nowadays our whole society is built upon software. I remember about ten years back when I raised the point of the Y10k problem that humanity will hit in eight-thousand years. At that point no one will any longer understand how the underlying date system works anymore, and there will be probably just 5 people in humanity that can change anything about the lower-level programming going on. Software will be so complicated, if we continue to apply the same mode of thinking that brought us into today’s problems with slow delivery rates in our enterprises.

If we can’t think of ways to simplify our current thinking, how are future generations going to deal with the complexity that we create today? 50 years from today, programmers were working with zeroes and ones to program. Forty years from today programmers were working in assembly language. Thirty years from now, programmers discovered structured programming. Twenty years from now, object-oriented software was a hype. Ten years from now, agile software development started. Ten years in the future, we will realize that Lean and Craft were the hypes of today. Twenty years from now, the post-Craftsmanship movement that overcame the year 2036 bug will be hyped. Two hundred years from now, Back to the Future programming will be popular.

Do you know how to program in assembly language? Do you know which bugs are more likely to be created using assembly language? Do you know how to best test a program written in assembly language? All of the existing levels of generalization exist because there was a demand to handle the existing complexity. A hundred lines of code method in C is more usual than a hundred lines of code function in – say – Ruby nowadays. But do you really understand the side-effects of today’s compilers when it comes back to bytecode? How many times have you been surprised by the simplifications that a good compiler could make out of your crappy code to tune the performance? Did you notice any bugs that your coding introduced because you didn’t understand the compiler well enough?

The same holds for the systems that we work in. Once we stop to understand the underlying complexity of the organizations that we work in, we are very likely to misunderstand the communication paths in our organizations, and program something out of value for our customers. We probably create more code that is not earning us any money, but slowing us down because we can’t never understood the other programmer downstream of our activity that has to live with our short-comings and lack of knowledge about his role and problems that he faces.

So, when we think about agile software development, should we think about how to handle the complexity in today’s society? Or should we rather think about how to challenge and reduce the existing complexity in our organizations, and therefore our thinking in order to reduce the amount of unnecessary waste that slows us down?

As Einstein famously said once, we can’t solve our problems by the same thinking that created them. So, is the question around scaling agile really the right question to ask? Maybe it should be something different. Maybe it should be along the line of “how can we enable a team of five persons to deliver something valuable in four weeks of time?”; “how can we get rid of the things that slow us down?”; “how can we reduce the amount of people we need to create something we can earn money from?”; “how can we deliver software faster with fewer people, and thereby serve more client requests in parallel?” We achieve this not b< re-thinking our practices, but by re-thinking our underlying assumptions about the principles that guide our practices.

There is always “hope”
There is one thing that every company has in common with all the other companies around: it’s unique. There is no other company that consists of the same people, the same attitudes, the same types, the same hierarchies – formal and informal – and the same routines – formal and informal. What does make us believe that the same solutions that fit somewhere else will work for us? The short answer – like it or not: hope.

There is always hope that some things will be similar in our workplace, and the same methods can be applied to our situation. There is always hope that we can transfer the wisdom behind that other experience into our situation. There is always hope that this methodology will be different, and will work for others as well as for us.

So, our minds play an awful trick on us. Rather than asking why did it work elsewhere, we put the hope into the question that takes less effort to answer: which of the practices can we easily start using (and hope to receive the same benefits as the others claim to have)? There are two terrible problems with that level of thinking.

First, the stories of other companies are polished to protect the guilty. When it comes to conference talks, articles, and marketing material, almost no company would tell the blunt truth. There are almost always polished stories out there. Some people polish their stories on purpose, others on not knowing (or not seeing) better. Since there is always hope that this time will be better, there is always some filter applied – like a splinter in your mind – that this time it really works. Until we realize there has been something hidden from us. That foreign element can, and will drive us down. That’s when we start to notice a crisis – that really is just the end of some illusion.

Second, since our company, our system is totally different from any other company, from any other system, why do we think we will receive the same benefits by applying the same practices? Companies, especially large ones, are complex enough for us not to understand side-effects, and root-cause relationships. So, when we change one thing, how do we know that the changed behavior we observe really is an outcome of our change? How do we know that the changed behavior is the one desired? How do we know there is no cost attached to the benefit we hope to see?

Hope can blind us from the truth. Hope can turn on all of our filters. Hope can make us unaware of the grizzly that is waiting for us in the tar pit that we are heading to. Hope can make us unaware about the fact that we are heading for that tar pit. Hope can influence the metrics that we measure to justify our decisions.

What does “scaling” mean?

I think we have to re-think what “scaling” means in the context of agility. Traditionally scaling meant that we put 5000 people instead of 50 on a problem that is 100 times larger than the 50 people problem, and have it solved. Unfortunately this is a trap. The trap lies in thinking that scaling simply means any ratio of “problem size” to “body count”. Most of the times I have seen a linear fallacy attached to that: thinking that there is a 1:1 ratio involved.

So, when it comes to agility, how should we define “scaling”? Agility is meant from the viewpoint of business value, from the customer point of view. For a customer, what counts is “how fast can you ship this thing to me so that I will have less problems sooner for less money?” From a company’s perspective – in the traditional sense – “scaling” means something else: “how can we solve this more complex problem with the more complex hierarchy that we have in place?”; “we estimated this problem in the range of 50 times that problem. How can we solve this problem with 50 times the people cost in there?”

And I think there lies the real underlying problem, the problem with yesterday’s thinking. We try to scale agile by “scaling” by the amount of estimation that we made, and assume we need similarly scaled people to do the job. From the customer perspective we should ask how to change our organization so that we can deliver the solution to the customer problem sooner by spending less money? When it comes to scaling agile in the enterprise, unfortunately, I don’t see many answers to these kind of questions.

Scaling the majority

What does that mean for scaling agile in the enterprise? I think we have reached a point where more and more “enterprises” became attracted to the successes of agile software development form smaller companies. They now realize they need to change something.

But keep in mind that this is most likely the conservative early or even late majority that adopts agile right now. That means that there are less conservative moves that company is taking. That means that the enterprise is more likely stuck with their thinking, and the underlying culture in the enterprises that adopt agile need a more dramatic shift towards leaner, more agiler methodologies – not more blown answers to problems they thing they have. And this is the real drag of current large-scale agile introductions.

There are more rules, because more people need to be governed without questioning the motivation behind governance to start with. There is more structure, and more hierarchy introduced together with the agile frameworks than should be necessary. Unfortunately the short-term changes introduced now will only reveal their outcomes in years to come in such enterprises. So it will take years before the last enterprise starts to stop cursing their agile adoption a failure. Unfortunately that warning will come as late as the next wave of new methodologies starts to raise.

I think we should not bother with “scaling agile” or large scale enterprise agility which should be disciplined because all that we lack surely is discipline. Instead we should wonder why we think we need such large enterprises to start with. Only then might we be able as a craft, as an engineering culture, as artists, and scientists to see behind the curtain that has been pulled over our eyes with terms like “scaling”, “enterprise”, and “agility”, and start to wonder how deep the rabbit hole really goes.