The main purpose of an Agile at scale organization is to scale while keeping the agility and flexibility of a startup. Scaling is important for a startup that may be on track to becoming a unicorn as well as for an established enterprise competing in the digital world.
Agility at scale can be achieved when the enterprise is driven by autonomous, stream-aligned, and cross-functional teams:
An autonomous team is empowered to make decisions and manages a minimum set of dependencies with other teams
A stream-aligned team is aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, or a single user journey [Skelton 2019]
A cross-functional team is composed of people from different areas of the enterprise, which together cover the range of competencies and skills required to deliver a product, feature, or journey
The ideas that drive the design of Agile at scale organizations are not new. They date back to the birth of socio-technical systems thinking.
Eric Trist and Ken Bamforth studied the consequences of introducing new technology, coal-cutters, and mechanical conveyors in English coal mines [Trist 1951].
Before the introduction of new technology, work organization was based upon pair-based units, which contained the full range of coal-face skills; each collier was an all-round workman. He was usually able to substitute for his workmate. The choice of workmates was made by the men themselves.
Leadership and supervision was internal to the group, which enjoyed a responsible autonomy. This organization had the advantage of placing responsibility for the complete coal-getting task onto the shoulders of a single small group. Work was meaningful and colliers could relate it to clearly identified outcomes.
When pair-based teams encountered hazardous conditions, they had enough skills and autonomy to respond in an appropriate way. The capacity of these small teams for self-regulation and self-adaptation was a function of the wholeness of their work task.
The authors of the study make it clear that the new technology was incompatible with the old work system: “With the advent of coal-cutters and mechanical conveyors, the degree of technological complexity of the coal-getting task was raised to a different level. Mechanization made possible the working of a single long face in place of a series of short faces”.
The organizational construct of a “longwall” production unit was based upon a series of shifts with cycle groups of 40-50 men, their shot-firer, and the shift deputies responsible for the working as a whole. The introduction of the new system disturbed the social balance: “It was impossible for the methods to develop as a technological system without bringing into existence a work relationship structure radically different …”.
In many coal mines, the consequence of the introduction of new technology was disorganization and waste: “Disorganization on the filling shift disorganizes the subsequent shifts, and its own disorganization is often produced by the bad preparation left by these teams. Every time the cycle is stopped, some 200 tons of coals are lost. So close is the task interdependence that the system becomes vulnerable from its need for one hundred percent performance at each stop”.
Autonomy and trust was replaced by blame and lack of accountability: “Since bad conditions and bad work interact so closely, it is usually difficult to pin blame specifically. Mutual scapegoating is a self-perpetuating system, in which nothing is resolved and no ones feels guilt”, the authors of the study observe.
Not all coal mines that deployed new technology suffered from these problems. The mines that let teams of multi-skilled workers form spontaneously and take on responsibility for the entire mining operations cycle did much better [Pasmore 2019]. The new form of organization that emerged features men who allocated themselves to tasks and shifts.
Although the tasks are those of conventional mechanized systems, management and supervisors do not monitor, enforce, and reward single task execution. The multi-skilled group takes over some of the managerial tasks as it had in the pre-mechanized organization, such as the selection of group members and the informal monitoring of work. Problems are solved by teams as they are encountered, resulting in operations running more smoothly and safely.
Pasmore and his co-authors list a set of socio-technical systems design principles:
Wholeness: the work system should be conceived as a set of activities that make up a functioning whole, rather than a collection of individual jobs
Teams: the work group should be considered more central than individual contributors
Process: variance or deviation should be identified and handled as close to their point of origin as possible
Self-direction: internal regulation of the work system is preferable to external regulation by supervisors
Multi-skilling: job and team design should be based on polyvalence or multi-skilling rather than single-skilling
Slack: the work system should preserve some room for slack
Joint-optimization: the individual should be viewed as complementary to the machine rather than as an extension of it
Incompletion: since the context of the organization will continue to evolve over time, no organizational design can be considered “finished”
To this day, these principles remain valid and should influence the enterprise that deploys agility at scale.
Autonomous teams are capable of self-organization. They are more resilient when they face adverse conditions, and can adapt when circumstances change.
Self-organization refers to the emergence of an order that results from the collective interactions of the system’s components. Self-organization is central to the formation of numerous structures, including biological ones. For example, there is no centralized control in a neural network. All the nodes are connected directly or indirectly to each other, but none is in control. Yet, together, they learn from complex patterns of inputs.
Self-organization cannot happen in an enterprise that:
Has a command and control culture
Distributes the work in a piecemeal manner, the pieces being too small to self-organize
Team autonomy, which is a precondition to agility, is hard to achieve at scale. First, the enterprise needs to trust its people, otherwise they will not enjoy the freedom to act. Second, effective alignment mechanisms are necessary to avoid chaos; see the four alignment levers in Agile Governance. Third, the work system should be designed to regroup activities that together make a functioning whole, otherwise the work will lack meaning.
Agile teams can be classified into three categories: stream-aligned, platform, and competency teams.
Stream-aligned teams make a functioning whole because they are responsible for all the activities necessary to deliver valuable streams of work. They are closer to external or internal customers because they deliver value to them. Stream-aligned teams usually interact with customers and are able to quickly integrate their feedback.
A great number of streams exist in an Agile at scale organization. The intentional architecture defines a modular decomposition of the architecture at all levels of the enterprise. Stream-aligned teams are assigned the responsibility of segments of the enterprise at different levels of granularity. For example, a “team of teams” can be entrusted the responsibility of lending products that target small businesses. At a lower level of granularity, a small “two-pizzas” team can be entrusted with the responsibility of the customer appointment management feature.
When assigning responsibilities to a team, it is critical to ensure the resulting cognitive load will not be too high [Skelton 2019]. When the capacity of a team is spread too thin over a scope that is too large, it affects team morale and work quality. Taking cognitive load into consideration when defining the scope of Agile teams is critical.
Another consideration is the “Dunbar number”, which is a limit to the number of people with whom a person can maintain stable social relationships. Robin Dunbar found a correlation between a primate’s brain size and the average social group size. Extrapolating this result to humans, the Dunbar number estimates that the size of a stable and cohesive human group should not exceed 150 to 200 people.
When the architecture of a system and the structure of the organization that is responsible for that system are at odds, the likelihood that the structure of the organization will win is high. This is why the Inverse Conway Maneuver recommends shaping the organization so that communication lines mirror intentional architecture boundaries.
This document recommends the decomposition of the enterprise into segments that are:
Orthogonal, to prevent teams from working on the same things
Loosely-coupled, to minimize inter-team dependencies
Agile Organization at Scale summarizes the ideas developed in this section.
Platform teams deliver an architecture and a set of integrated components to internal customers.
For example, the automotive industry develops platforms that consist of the floor panels, suspension system, firewall, and rocker panels. It constrains the architecture of the product. It provides a structure for major components by determining the body size and type of engine and transmission [Cusumano 1998].
In software engineering, a software product line is equivalent to an automotive platform. It is a “set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [Northrop 2012].
Stream-aligned and platform teams are at risk of becoming silos if they are not completed by another type of organizational construct: competency teams.
Competency teams regroup people from the same discipline or competency area. Competencies can be of various types, ranging from “hard” engineering disciplines to “soft” disciplines such as anthropology or psychology.
Competency teams can take various forms, ranging from a virtual organization, such as Spotify’s Chapters or Guilds [Kniberg 2019], to a functional department which regroups similarly-skilled people to manage their career and develop specialized knowledge.
Competency teams can also take the form of enabling teams, as described by Matthew Skelton and Manuel Pais [Skelton 2019].
In technology companies, Marty Cagan reports that a product team is generally composed of a product manager, a product designer, and somewhere between 2 and about 10 to 12 engineers [Cagan 2018]. Product teams fall into the category of stream-aligned teams. Product teams are stream-aligned.
A product team is composed of highly skilled people who work together for an extended period. True collaboration between product, design, and engineering roles resembles the type of collaboration described in the experience report of Learnings from Socio-Technical Systems. A product team is not a hierarchy. Product team members typically continue to report to their business unit; for example, engineers may report to an engineering manager.
Product teams have the responsibility for all product-related work, including the full customer experience. When the scope of the product is too large, a product team can be composed of sub-teams. Each sub-team is then responsible for a smaller but meaningful piece of that experience, and for the features that deliver it.
A product manager leads a product team. This is not a management role, but a true leadership role that requires those assigned to be among the strongest talent in the enterprise. Marty Cagan claims that a product manager who operates according to the Silicon Valley model must, like a CEO:
Possess a deep knowledge of customers, the market, and the industry
Understand enough of the design and engineering disciplines to elicit meaningful design conversations and make architecture decisions when consensus cannot be reached
Be personally credible vis-à-vis key stakeholders such as general management, sales, marketing, engineering, finance, legal, customer support, etc.
The product owner role definition differs depending on the Agile framework:
The Scrum product owner is responsible for ensuring Agile teams build a product of the highest possible value
If the product responsibility is shared between several Agile teams, the product owner manages only one product backlog.
The SAFe product owner is no longer responsible for ensuring a product of the highest possible value is built
The responsibility for delivering value moves to the product management team. Product backlog gets replaced with program backlog. Program backlog gets broken down into team backlogs, for which product owners are responsible.
Marty Cagan compares and contrasts the product owner role with the product manager role. He observes product owners tends to be less qualified than product managers. Too often, a product owner is a “recycled” project manager or Project Management Officer (PMO) who does not possess enough experience, competencies, and skills to truly play a product manager role. When a true product manager is appointed, it is critical that they play a product owner role too.
Unlike most product owners who prioritize features, successful product managers prioritize outcomes rather than product features.
Unlike the project‐oriented model, which is all about getting product features developed and deployed, a product team is accountable for business outcomes. Success is measured through experience and business results metrics.
The chief engineer is an entrepreneur and architect. They represent the voice of the customer and are accountable for the economic performance of the product; for example, a new car model. They have enough technology and business insight to solve cross-disciplinary problems.
The chief engineer has a passion for the new product and can inspire excellent engineers. They are too busy designing the product and the value stream that will produce it to have the time to manage team members. Functional departments manage people and capitalize knowledge in their engineering discipline.
Lean Chief Engineer Model illustrates how the system works.
The Lean Product Development organization is quite similar to Marty Cagan’s product team model; a similarity worth acknowledging as these practices come from different industries and were developed independently. Both models also differ from the way Agile frameworks usually define the product owner role.
A capital management example is used here to compare and contrast a siloed command and control organization with an Agile one. This section shows how the wholeness and multi-skilling principles from socio-technical systems characterize the new Agile capital management organization.
Regulators issue minimum capital requirement regulations. Banks are mandated to compute the amount of liquid capital they need to cover for credit, market, and operational risks. The capital requirement numbers matter because they set a cap on growth and impact returns on equity. Because the bank was not managing its capital to the satisfaction of regulators and shareholders, the executive committee decided to launch a program to fix it; see Initial Program Organization.
This is a classical program structure run by a program director assisted by a project manager. The co-sponsors of the program are business-line heads and their Chief Financial Officers (CFOs). The scope is huge; it covers all businesses such as retail banking, Corporate & Investment Banking (CIB), global markets, and consumer finance in all geographies.
Work streams are functionally aligned; for example, capital management models to improve the Risk-Weighted Asset (RWA) calculation, or the data quality to generate more accurate data. Each work stream regroups experts in a domain. For example, portfolio securitization experts are knowledgeable enough to decide which securitization structure is better to reduce the RWA.
After six months of operation, the program delivered few if any results. Why?
True cross-functional work did not happen: work streams were optimized from the perspective of their own discipline; cross-functional issues discussed in steering committees were not properly investigated, and decisions were influenced by internal politics rather than facts
The cognitive load of functional work streams was too big; having to understand all of the business lines and all of the products
It was difficult for work stream leaders to develop trust relationships with key people across all business lines, product groups, and geographies; i.e., the Dunbar number limit
Since the bank had been successful at deploying agility on the IT side, business executives decided to radically change the capital management setup; see Agile Capital Management.
Though the topic was regulatory, program sponsors identified two client constituencies; regulators and shareholders. Two expected outcomes were defined:
Strict adherence to rules for regulators
Improved return on equity for shareholders
Capital management shifted from a temporary program structure to a set of permanent and cross-functional teams. The scope of each team was bounded by their business line and their products.
New capital management teams were now stream-aligned. The front line became responsible and accountable for the quality of capital management numbers. For example, the “Consumer Loans Capital Management” team took ownership of the regulatory capital consumed by the consumer lending business.
The cognitive load of stream-aligned teams is reduced compared to the former program streams. Each capital management team only needs to know their own business and products; not all of the bank’s businesses and products. Team members can remain capital management generalists because they get the support of the experts who staff competency teams.
Functional experts, such as “Capital Management Modeling” specialists or “Securitization” specialists, were regrouped into competency teams to provide support to stream-aligned capital management teams.
How this model works is illustrated here using the securitization example. Securitization is about creating composite financial instruments, real or synthetic, by pooling various financial assets. The issuer sells this financial instrument to investors. Securitization offers the bank an opportunity to free up capital.
The CFO defines the overall securitization strategy. However, it does not have enough operational knowledge to study the feasibility of securitizing enterprise loans. In this example, the “Enterprise Loans Capital Management” team is responsible for defining the specific enterprise loans securitization strategy and is accountable for the outcomes: compliance with regulations and reduction of regulatory capital consumption.
The new Agile organization helped improve the quality of regulatory capital management KPIs, accelerate RWA production lead time, and reduce operating costs. Far fewer issues are reported and regulatory capital consumption decreased by 15% on a like-for-like basis.