The Five Orders of scaling agile teams
A decision-making approach to scaling (and when not to)
I have been doing work recently to help contextualize the decision-making framework for scaling and de-scaling networks of teams. This reflects my current understanding and beliefs. Any constructive feedback to either validate or challenge my perspective would be very welcome.
In summary, the five orders of scaling are:
- Don’t scale
- Create independence
- Create interdependence between teams
- Create interdependence between products
- Manage dependencies between work to be done
Don’t scale
If you can achieve your goals with a single team, do not scale. Employ the minimum number of people required to meet your strategic outcomes. — Manifesto for Scaling Agility principle #1
The first order of scaling is not to do it. Brook’s law is one of the forces in motion here, the observation that adding more people will delay a project even longer. This is in part due to Metcalfe’s law, looking at network complexity. This shows us a team of four people has six lines of communication and six individual relationships to sustain. Eight people have 28 connections (4.7x more) and 12 people have 66 connections (11x more!). The more connections, the more difficult to maintain a collaborative team.
If you have a single team and it cannot deliver effectively using Agile principles and practices, do not scale. Succeed with a single team first — Manifesto for Scaling Agility principle #2
If we accept fixed costs and time when considering product build, then scope is the variable we can leverage. We must first assess that we are effectively maximizing the work not done (principle #10 from the Agile Manifesto) and optimizing for early and continuous delivery of value (principle #1). These principles manifest through strong product ownership competency, and technical competency in developing effective solutions.
As well as application of good lean-agile practice, does the team have all the skills they need to develop the product, and can they reasonably acquire them without additional people joining them? The ideal team size is probably smaller than you think.
Don’t add people or teams if the foundation is not strong first, as it will ultimately cost more, take longer and all in order to get less done.
Create independence
Once we are confident that a single high performing team is not reasonably able to satisfy the demands of developing and incrementing a product to maximize for early and continuous value, we may look at scaling the number of teams.
Again, the principle of not scaling unless we have to applies, and the next order of scaling is to seek creating independence in the work to be done. Can the scope of a product be divided into two or more aspects where decision-making, learning, and development are independent of each other? Within the context of Scrum, for instance, could two Product Backlogs be created with two teams able to inspect and adapt their product incrementally without being dependent on the other team? With this order of scaling, the outcome would be multiple high performing and collaborative teams, each able to independently realize value early and often.
Create interdependence between development teams
The third order of scaling is applied when reasonable efforts to create independence between two or more product teams have been exhausted. More than one team is needed to satisfy the demands of the product, however the requirements and work to be done can be contained together in a single Product Backlog.
Therefore, scale the teams but not the product.
Large Scale Scrum (LeSS) and Nexus Scrum both provide scaling frameworks that optimize around a single Product Owner and a common Product Backlog. Nexus focuses on humans managing dependencies through an Integration Team. LeSS promotes low process and coordination overhead through the principle of just talk and communication in code.
LeSS provides guidance on how to scale the Product Owner role. Before applying higher orders of scaling beyond this, all effort should be made to effectively enable a single entrepreneurial Product Owner to be accountable, empowered, and effective.
Create interdependence between products
At the fourth order of scaling, it has been determined that the single Product Backlog is too complex and demanding to be managed by a single competent Product Owner.
Therefore, scale the Product Backlog, and the Product Owner role. Multiple teams form a network of interdependent teams, each with a Product Backlog and managed by a Product Owner.
LeSS Huge provides the Area Product Backlog pattern for containing subsets of the overall Product Backlog requirements, and the Area Product Owner for managing these. Together they form a Product Owner Team, that must be high performing and collaborative in their own right, and the Product Owner maintains final decision-making authority.
Scrum@Scale provides the Chief Product Owner role, who coordinates priorities with the Product Owner Team. This framework attempts to reduce the network complexity presented in Metcalfe’s law by forming a team of teams, called a Scrum of Scrums (not to be confused by the event of the same name, popularized by SAFe). Other teams in a wider network treats the Scrum of Scrums as a single node in the network. The Chief Product Owner operates at the Scrum of Scrums level. In larger organization constructs, this might scale again to a Scrum of Scrum of Scrums. With this scale, team autonomy and decision-making from those closest to the work requires a transformational (strategist) action logic from leadership to protect and sustain it.
Manage dependencies between work to be done
To this point, all attempts have been made to live into and respect the beliefs of an agile mindset. Autonomy and empowerment of those closest to the work has been a primary consideration, as has the application of good lean-agile principles and practices to support early and continuous delivery of value.
Most cynically, the final order of scaling could be considered a dis-order arising from the false perception of control. In order to scale the organization to meet the demands of the product, teams of specialists are formed to own specific parts of the value stream; specific parts of the technology domain; or specific parts of the workflow. Dependencies compound, and teams of people are needed to manage these. Centralization increases and effectiveness decreases, and this scaling order requires more scale. Many organizations across many industries are here today.
Like the big crunch at the end of time, the next order of scaling is to de-scale. My article on the evolution to one team wholeness presents some of the boundaries that must be crossed for such organizations to achieve de-scaled team agility. The question remains, how agile do you actually need to be?
Read Part 2: A de-scaling roadmap for agile teams.
