I have worked recently to contextualize the decision-making framework for scaling and de-scaling networks of teams. This blog post examines each of these orders and provides a little more context to help you understand what you may need to do on your own team.
This reflects my current understanding and beliefs, but I am always open for discussion and growing my learning.
As a reminder, the five orders of scaling an Agile team are:
- Don’t scale
- Create independence
- Create interdependence between teams
- Create interdependence between products
- Manage dependencies between work to be done
1. 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 law 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)
When building a product, you may have to contend with fixed costs and time, so you should focus on leveraging the scope of what you can produce. To do this, first assess that you 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 the application of good lean-agile practice, does the team have all the skills they need to develop the product? Can they reasonably acquire these skills without additional people joining them? The ideal team size is probably smaller than you think.
Don't add people or teams if the foundation of your team is not strong first. It will ultimately cost more and take longer to get less done.
2. Create independence
Once you are confident that a single, high-performing team is not able to develop and incrementally improve a product to maximize for early and continuous value, you may need to consider scaling the number of teams.
While it’s always best to not scale unless necessary, the next order of scaling is to create 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 is that multiple high-performing and collaborative teams are each able to independently realize value early and often.
3. 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 product's demands, but the requirements and work can be contained together in a single Product Backlog.
In this instance, you need to 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.
4. Create interdependence between products
At the fourth order of scaling, it has been determined that a single Product Backlog is too complex and demanding to be managed by a single competent Product Owner.
Therefore, you need to 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 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. 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 organizational 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.
5. 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.
Conclusion
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 the next part: A de-scaling roadmap for agile teams.
