According to Craig Larman, a renowned consultant, reducing switching costs by learning is resisted most by any organization. Speed of delivery can be quickly "sold" to management. But speed is by far insufficient to be Agile at the organizational level. Instead, the biggest issue in becoming Adaptable is narrowly specialized teams that stem from the lack of team and management investment in team learning.
Below is an example of how narrow team specialization hinders adaptability as scale.
Once, we consulted a product company building a portal with an innovative fintech system that processed payments among hundreds of countries. The organizational design consisted of several feature teams that could deliver usable increments to the market every couple of weeks. Even though teams were feature teams, they specialized around tiny business domains to "maximize focus and thus speed of delivery". All teams could only pick up items corresponding to their business knowledge. Suddenly, when a crash happened in the market, one of the teams got overloaded with the number of changes they had to deal with.
Figure 1 below illustrates the trap that the organization got into. On the left of the figure, you can see that each team specializes in a narrow domain. ( e.g. Grey team can only work on Grey backlog items ) On the right side, you can see that the highest value work exceeds the capacity of the black team, and no other team can help.

The organization turned out to be fragile, unable to absorb significant change.

Imagine a product group with six cross-functional teams, see figure 2. Each team can pick up any feature that comes into the product group, which means that all teams in the product group can always work on the most critical work. Also, imagine that all teams optimize for delivering a feature in short cycles (e.g. two weeks) from an idea into the hands of the end-user. This means that they have fast feedback for learning. As a final step, imagine that the teams split large work items into small items, to work on each cycle.

Figure 2 Product group optimized for adaptability. (Figure copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Such a product group has the conditions to be maximum Agile. Why? Consider the following 3 reasons:

• All cross-functional teams can pick up the most important work, so the product group can react to the work that comes in with 100% of the teams. Contrast this with specialized teams in figure 1 that have a limited work scope comprising their area of expertise. When the most crucial work exceeds the capacity of the specialist teams, no other team can help, and therefore the product group can not adapt and focus on the highest value work.
• A big piece of work, for example, a project in a traditional project organization, is split into small items of end-user value. Now, instead of assuming that the whole big item is "required", the teams only deliver the high-value items in short iterations and ditch the low-value ones altogether. Large items convey lots of information, are made full of assumptions and therefore carry high risks. So, the product group does not focus on the question: "How can we deliver all the "requirements" in this big item?" but instead answers the question: "what is preventing us from achieving the intended outcome?". It avoids fixed work scope and re-plans for the highest value every cycle.
• The group learns from short feedback loops and puts that learning back into the plan on what to work on next. Hereby reacting to changing conditions as more is learned and discovered.

Creating such a product group requires certain capabilities to be in place. For example, the teams need to have the skills to work across all product domains, technical components, applications, and tools. This implies minimizing costs when switching between jobs and getting the work done as effective as required; how to do that? There are three main concerns to address:

1. Minimize switching costs from moving from one work item to another, because teams don’t have all the parts or information. These include learning costs, cognitive costs, and the cost of a team stopping existing work and starting new work.

2. Minimize transaction cost: the cost of overhead activities. In Lean, these are activities that are either necessary but non-value-adding waste (temporarily necessary waste) or unnecessary activities that could be eliminated (pure waste). In Agile software development, transaction costs are in activities other than software design, programming, and verification, including communication, coordination, and repeating manual activities like manual deployment or testing. The critical point is that your software must be soft enough to change it quickly, at a low cost, and validate if it delivers what is expected. The way to lower the transaction costs on software development is to use appropriate engineering practices, including effective automation of the build and test process and eventually automation of the delivery pipeline, and these are just a start.
3. Flow Efficiency over Resource Efficiency. The final concern is the learning speed of the product group: the ability of fast delivery to create short feedback combined with the quality of measuring to decide what is most important to work on next. In software development, for resource efficiency, it is more important to ensure each team always has a feature to work on. For flow efficiency, it is more important that a feature is always being worked on. So, in resource efficiency, the work is likely queued before each team to always keep them busy. Whereas, for flow efficiency, the goal is for teams to be ready to pick up the highest value work. This implies teams are expected to learn to understand to work effectively on multiple areas of the larger product.
So, for Adaptability at scale, an organization needs more than fast delivery. It also requires a design that promotes broad learning to change direction effectively; without it, you get local team improvement at best.