An-Isotropic Scaling
In the vernacular of my former career as a metallurgist, 'scaling' is defined as 'the accumulation of unwanted material on solid surfaces to the detriment of function'. Over the last year or two, I've been amused by the discussions around scaling in agile environments and the applicability of that definition. There are many, although not all, in the agile community who might define scaling as 'the accumulation of unwanted process and overhead on solid teams to the detriment of their function'.
In metallurgy, there is the notion of isotropic vs an-isotropic scaling. That is, the difference between uniform scaling and non-uniform scaling. It is natural to visualize scaling anything uniformly along all axes. When we look at a picture, we think in terms of increasing or decreasing it uniformly in all directions, resulting in a larger (or smaller) version of itself. Sometimes we use uniform scaling and fix the ratio of expansion or contraction along the axes to match the original and maintain a shape. However, there are situations where the reason for scaling actually dictate non-uniform scaling; the bigger picture isn't the goal, rather increased utility or performance at a different size is the goal. I believe that to be the case with scaling an agile organization.
Isotropic scaling of an existing system can very often lead to expansion (or contraction) in unnecessary areas and not enough expansion (or contraction) in others for the desired effect.
Very often, expansion within an organization requires growth at different rates-- and in different directions. This is precisely the definition of an-isotropic scaling. Further, it’s quite possible that the expansion in one area actually requires a contraction in others for the system to be effective. Rather than focusing on keeping the shape of the organization intact through uniform scaling, it might be helpful to recognize that non-uniform scaling, by definition, changes the shape of an organization.
Too often, expansion is seen as the solution to problems- problems that would actually benefit from contraction. A classic example is the notion that we need to increase the number of support teams to handle increasing numbers of customer support issues. Using a systems thinking approach, the real solution to this problem is to uncover the cause of growth in customer support issues and address that, rather than expanding to handle the symptoms.
When we are scaling an organization, we need to identify what problem we are trying to solve. Are we trying to coordinate existing and additional teams for some form of consistency (perhaps architectural or technological)? Are we trying to increase the throughput of the organization in terms of different products/services delivered? The specific solutions to those scaling issues may depend on the maturity of leadership, teams, products or portfolio management, and will likely require growth at different rates in each of those. With mature products and teams, perhaps it is simply the portfolio management system that needs to scale up. With mature leadership and products and services, perhaps it is only the teams that need to multiply. Without taking into consideration the people and their relationships, it is very possible that process and overhead will be added to the detriment of an already well functioning part of the whole. As many organizations consider people simply ‘human resources’ within a process, it is too easy for those organizations to ignore the human part of growth or contraction.
There are, of course, instances where isotopic growth is required. When we are considering the increase in capacity for software delivery, there is often a desire to ‘hire developers’ to accomplish this. In this case, the increase in capacity usually needs to be isotropic (perhaps with fixed axes); adding developers, testers, Scrum Master, Product Owner. Adding developers alone doesn’t increase capacity, adding multi-discipline teams increases capacity.
An agile mindset keeps us focused on inspecting and adapting based on a clear understanding of what problem we are trying to solve. Scaling an agile organization is no different; we need to keep focused on the problem we are trying to solve, rather than simply uniformly scaling a system that works in its current situation.
