Scaling is easy if you just let go!
Scaling is about alignment, focus on that! Autonomy and scaling will evolve organically, suiting itself to the particulars of your organisation.
Scaling is a big thing in Agile. Scaling frameworks are big businesses and organisations specialising in scaling are enjoying golden times. Allied Market Research, quoted among others by Bloomberg, predicts almost 20% growth per year globally for the Agile industry, with both the Scrum Master and Agile Coach positions growing significantly across the board.
But why do organisations actually scale? The usual narrative is that scaling is necessary for growth. As an organisation grows, the number of Scrum Teams also grows. Because Scrum focuses on the team it is deemed insufficient to address problems that arise from the increased number of Scrum Teams, such as coordination. Therefore, it needs to be scaled up.
However, the reality seems to be quite different with large organisations. What usually seems to happen there is that an organisation decides to go Agile, for a variety of reasons. A scaling framework is seen as an integral part of the package to achieve this, a necessary part of becoming Agile. A scaling framework is implemented, not to solve the problems of scaling, but to jump-start Agile in the organisation.
SAFe is quite clear about this:
SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.
I have misgivings about this approach. Let me explain.
Do you need to scale?
First of all, this approach completely hides the fact that there is a very important question we should ask before we decide to scale our organisation:
Do we really need to scale?
Yes, it is possible to avoid scaling. And no, you do not need to have a scaling framework in place to be Agile. In fact, avoiding scaling can be a very good strategy for any organisation because scaling in any form brings costs with it, not least amongst them being a serious increase in complexity.
Let me illustrate this with an example. I worked at a company delivering custom software to a variety of customers. Every customer was partnered exclusively with a single Scrum Team. As we got more customers, we gradually increased the number of Scrum Teams: a very simple way to avoid scaling. And it worked. The Scrum Teams built up relationships with their clients and developed their own particular way of working together.
As the company grew, at a certain point we thought it would be good to increase our flexibility by making customers and projects interchangeable. For example, to be able to add extra Scrum Teams to a project running into problems with a deadline. To achieve this, we explored various aspects of scaling and did quite a few experiments. Time and time again these experiments failed. For us the coordination between Scrum Teams and the necessary standardisation of the codebase was challenging and very time-consuming. What we learned was that the necessary overhead to achieve scaling was such a pain in the ass that it was more efficient to simply accept a certain level of inflexibility regarding deadlines. We stuck to our proven approach.
Scaling is just really hard. Avoiding it is a sensible approach. Christiaan Verwijs wrote a cool article about this: Don’t Scale Up. Scale Your Product Down.
Higher level of Agile complexity
The whole point of a scaling framework is to make scaling easier, much as the Scrum framework helps making Agile easier at the team level. However, I don’t think the two are comparable, simply because the amount of complexity is much, much higher.
How does this complexity affect us? Looking at my own experience as a Scrum Master, it took me about 8 years working with various teams in different companies to reach the point where I felt confident about my understanding of the Scrum framework. That is not to say implementing Scrum with a team has stopped being a puzzle, not at all! It is just that the number of major surprises has become manageable and the number of personal crises has gone down a lot.
Scrum is hard, really hard. The rules may seem simple, but it will always be a journey of discovery you set out on with your team and in which there is simply no chance, no chance at all that you can plan for everything that you will encounter.
It is the reason Scrum is a framework: it serves to guide us and must be modified to work for the specific situation of each and every Scrum Team.
It is why we have a Scrum Master, to guide that evolution.
The point is that, if a simple framework like Scrum, which focuses on small teams, is already such a challenge, how realistic is it to expect applying a complete scaling framework to a whole organisation to be a simple exercise in plug & play?
To get an idea, let's use Metcalf’s Law. As you can see in the diagram below, as you increase the number of people working together, the increase in the number of lines of communication is quadratic:
Let us solve for the lines of communication using an organisation with say 500 people. We get 124,750 lines of communication!
y = ½x² – ½x
where y is the number of lines of communication,
and x is the number of people.
Sure, this is an approximation. For example, not everyone needs to talk to everyone else. But still, the increase is huge. To me, trying to predict or control this amount of complexity is absolute lunacy, an obstinate symptom of times gone by, echoes of Taylor and steampunk attitudes from a time when organisations were viewed as no more than complicated machines, static and reliable, a time when life seemed simple enough that you could hope to control much of it.
The Challenge of removing stuff
Perhaps I hear you say that a scaling framework is just as much a set of guidelines as the Scrum framework itself and that as the organisation gets to know the framework, they will adapt it to their needs?
This is not easy. I see 3 factors at play that make this really difficult.
First of all, psychologists agree that we humans are terrible at removing stuff. Faced with a problem, we will reliably add something to fix it, but we will rarely stop to think that maybe removing something might work better. Leidy Klots wrote an interesting book about this. The subject has even made the cover of Nature.
Incidentally, this is one of the things we try to learn with Agile. Quoting Sjoerd Nijland:
Solving complexity by introducing complicated workflows and protocols is the road to rigidity. Solving complexity through simplicity, is the way to agility.
To make matters even harder, organisations starting with Agile lack the understanding to tweak an Agile framework. To tweak a framework effectively you need to be seriously versed in Agile. This is not the kind of understanding you get overnight. For me, this is illustrated by the giant learning curved I described above, the one faced by Scrum Masters in developing their understanding of the Scrum framework.
Finally, scaling frameworks can easily be mistaken for the old fashioned bureaucratic command processes which organisations moving towards Agile are actually trying to move away from. In our old fashioned way of thinking, tweaking a process is already a kind of out-of-the-box thinking which is rare, so imagine how more challenging it would be to think of removing stuff from an unfamiliar process put in place by experts?
I feel that by having a scaling framework in place we are creating a huge problem for ourselves. We might tell ourselves that the scaling framework forms a stepping-stone towards Agility. But I am afraid what we often end up doing is replacing our original processes with a new one that we don’t understand and which will actually make it that much harder for us to attain the kind of understanding of our processes that is essential for an Agile approach.
Big design upfront
If there is one thing Agile tells us is that trying to plan a complex system upfront is not going to work. The whole idea of an iterative approach is to deal with this complexity. The whole point is that you find your way as you go, as you gradually learn and discover new parts of the puzzle.
This is someth]ing that does not apply only to the projects your teams work on, but to any kind of project. In fact, moving a large organisation towards Agile is a textbook example of a complex endeavour.
So why do we keep insisting that scaling with a meticulously designed scaling framework is going to work? To me, this is about as absurd as, say, deciding to learn French by reading French books translated to your own language.
If you want to embrace an Agile approach you have to do it across the line, with no exceptions!There are no shortcuts. Agile is not about the final solution, Agile is about how you get there yourself, how you learn to build the solution - the scaling framework in this case - yourself. And this incidentally is another serious problem with the big design up front approach, that it is usually external specialists who make the design, not the people who will end up working with it. This brings me to my last point.
Culture change
To me, Agile is primarily about empowering those responsible for creating value, cultivating a growth mindset in them so that they can manage their work as effectively as possible. That is why the first value of the Agile Manifesto is Individuals & Interactions over Processes & Tools. Take care of the people first, and they will figure out the processes and tools.
For me, the fact that the focus is usually on the processes is one of the most frustrating parts of any Agile transition. Too often I see organisations plastering their own interpretation of the Scrum framework on their Scrum Teams, and announcing that they are Agile!
A meticulously designed Agile framework risks having a similar effect. It creates the illusion that you really have thought about everything. The scaling framework more often than not will become the purpose, a seemingly reliable representation of ‘the solution’. It will end up hiding the problems you encounter in a shroud of complexity. And it will stop you from learning the things you really do have to learn to be able to scale.
Put simply, a scaling framework is just a shortcut for the journey you must take with your organisation. A journey that is necessary for you to learn to understand what it is you are getting yourself into. The key to becoming Agile is taking ownership of your processes. Dealing with scaling is just one aspect of your Agile journey, and it is something you can only deal with by developing the expertise and know-how yourself. Focus on the individuals and interactions in your organisation and help them grow so that they can deal with the scaling processes and tools themselves.
Conclusion
Based on these thoughts, my recommendation is twofold.
First, do anything you can to avoid scaling. Minimise it, even if it costs you. Like for example accepting reduced productivity to minimise the number of teams working on a product. With a bit of perseverance, you may be able to reduce the scaling needed to something manageable without a full-blown scaling framework.
Second, invest all the resources you have for scaling in the Scrum Teams. Give them the mandate to organise their cooperation (alignment) and give them the room to figure it out themselves (autonomy).
By all means, study the various scaling frameworks looking for possible solutions to problems you run into! But be critical and adapt them to your situation. And keep experimenting.
If you feel tempted to hire an expert to speed things up, remember this is not about achieving scaling, but about learning to deal with scaling as an organisation. An expert will only help if he can speed up the learning. Everything else is just another shortcut which you will have to pay for eventually.
As soon as your first Scrum Teams start figuring out how to scale, start looking at ways to do something about the costs you incurred during the first scaling-avoidance phase. With the experience developed by the first few Scrum Teams, you can expand the scaling where it balances against the costs. By this time you will probably have developed the necessary expertise to measure this.
The road to Agility is a long and bumpy process of evolution. Scaling frameworks can be a useful tool to point the way. They are also a source of solutions and best practices for problems as they arise. The key here is “as they arise”. Scaling is just part of your Agile journey.
In that sense, a specific scaling framework is just one example of what you could arrive at after having made the scaling journey yourself. It is one single possible destination, put there to offer you a coherent and understandable collection of best practices.
One thing I guarantee is that when you finally get there, proud and happy after having completed your journey, your scaling solution will be something else, something unique and fantastic, a new example to inspire others. That’s what happened with Spotify.