How can you use Scrum to manage multiple teams and complex projects?

There is no more challenge in scaling Scrum than in scaling any other complex system development. The challenge is in balancing groups' autonomy with the tight interworking that defines agility. Much of the complexity of scaling is accidental complexity that results from creating organizational entities and the communication paths necessary for them to synchronize. Organizing around technology stovepipes or system components forces coordination around the primary concern, which is the product. Scrum out-of-the-box helps scaling by organizing around deliverables instead of components, so the primary value focus (the end user) is local instead of being distributed. The final coordination on value requires little cross-team coordination.

Original Scrum provides a template for advancing work in a consistent and predictable manner. It was designed with a Team in mind and continues to be very effective for many situations that require maturity to achieve constant flow. Scaling Scrum by itself gets into uncharted territories since there is no template for scaling. However, Scrum is very effective in the context of many Scaling frameworks that deal with the complexities of large efforts. Scrum should be though of as a Team Practice that can be combined with many other Scale Practices to achieve a large goal, rather than thinking of "Scaling Scrum"

Problems of scaling from one team to several in software development is often caused by poor architecture. When being just one team, it is of little consequence for the organisation if the architecture makes it hard to divide the code base up in distinct components with clearly define responsibilities. However, this becomes a problem when having multiple teams. If you can’t adequately define the responsibilities of one team or create a (mostly) unidirectional chain of dependencies then scaling is likely going to slow you down. That however has nothing to do with scrum

The most effective way to scale Scrum is to build a scale-free organizational structure that maintains efficient communication across the development population. Hierarchies destroy such efficiency by adding links to the communication paths between individuals, that necessarily pass through higher levels that feel left out if excluded from exchanges across teams. One achieves scale-freeness by directly connecting teams with shared concerns or synergies through facilitating hubs. Communication reach comes from a large fan-out, as in an obeya, community of practice manager, or Scrum of Scrums, rather than through hierarchy. Hub structures create an organization that is a directed graph with redundancy and robustness, rather than a hierarchy.

Scrum focuses on creating value for the organisation not the customer. It so happens that in many cases they overlap but the objective is value creation for the organisation/company now as well as in the future

Most frameworks are devoid of mature organizational principles other than hierarchy, and hierarchy is antithetical to dialogue. Agile is based on individuals and interactions. Hubs greatly reduce the distance between individuals and teams to sustain this agile objective. Rather than being a framework that one fills in, hubs are a principle of largely autonomous organization with a light touch of organization design that provides a custom, but ever-changing, fit to the organizations need. Organizational frameworks like LeSS can help identify waste to guide the organization's coordination processes with its insight into eliminating unecessary organizational elements.

The first question to answer should be, have we done everything we can to avoid scaling? I’ve seen organisations go from 50 people to less than 10 while increasing both quality and speed of delivery. And seen a project being far more productive with only 10 people than the same project with 110. There’s waste in any system and unless you have clearly identified the waste and likely seen an increase in value generation of more than 200% odds are that instead of scaling you are better off identifying the waste. Which might very well be producing stuff that doesn’t add to the value generation.

There is little literature justifying scaling. Scaling often feeds an itch to increase productivity; in software, where 65% of code is never or rarely used, scaling just becomes a way of generating waste faster. Scaling can optimize productivity; ōno-san, the creator of TPS, admonishes us that overproduction is the number 1 cause of waste. Scaling can help a product create a presence in several multinational markets. Scaling a Danish product development to add a team in China allows the enterprise to scale the product into the Chinese market, attentive to local mores, language and regulation. This is more of an increase in scope and product scale than it is scaling the organization, though the latter follows from the former.

You go fast by reducing waste. Simplifying. Reducing scope. Building quality in. Removing inter-team dependencies. Staffing our teams with the correct skills.

Before scaling to get more output, instead consider whether an increase in efficiency can better achieve the same goal. Scrum teams have achieve monumental improvements in throughput through discipline application of Scrum principles of collocation, one-by-one construction (swarming), enabling specifications, striving to eliminate inventory, and tight market feedback loops. While these kaizens typically can double delivered value again and again at low cost, scaling tends to be heavyweight, adds coordination overhead and high fixed cost, while yielding improvements of only tens of percent.