Understanding “Scale”
Scale is not defined by the size of an enterprise but by the relationship of enterprise stakeholders to the teams involved in building what they want. Scale occurs at the group level in the organization. Thus, an organization with thousands of developers that are organized into many independent sub-groups is not really large scale.
There are five kinds of scale.
- No scale. This is when a group of developers comprise just a handful of teams and are driven by one product owner. They are small enough to collaborate with each other and don’t need to use any services from other teams. In other words, they are fully cross-functional and can take business requests and release and support them on their own. Typical development group size of less than 30.
- Small scale. This is when the group is driven by a handful of product owners and many of the teams require some help from others. It is likely that some services (e.g., business intelligence) are shared across the teams. The product owners are able to coordinate among themselves to provide a shared backlog for the teams to pull from. Typical development group size of 25 to 125.
- Mid scale. Several business stakeholders are driving initiatives. A handful of product managers are needed to coordinate with these stakeholders and act as their agents. Product owners act as liaisons between product management and the teams. Shared services are almost certainly present, and teams are likely organized into mostly independent programs. Typical development group size of 100 to 1000.
- Large scale. This typically is when you have multiple mid-scale organizations with common shared services and ops. Each mid-scale organization has its own shared services but also requires shared services for the entire organization. Programs may compete for funding from one main budget. These may represent a division in a very large organization. Typical development group size of 600 to 2000.
- Very large scale. A technology group that has multiple large-scale divisions that share some needed capacity.
What This Means
There is a transition from no scale to very large scale. There are two things to attend to here. When looking at what it takes to go from concept to consumption, about the same concepts are required regardless of scale. As scale increases the number of steps to manifest these concepts and the number of people involved goes up. But in all cases, there is the need to take a concept, identify it as important, and determine what part of it should be built and how we should build it (new products, extensions of existing ones and replacing products have different ways of being built). Furthermore, there is a need for allocating capacity, managing conflicts for capacity when more than one item is being worked on, and so on.
The bottom line is that even though the scales of the organization have great variation, all companies have issues related to portfolio management: how we decide what to work on and how to apply our limited capacities to it.
Dynamics of Scale
There are several factors that affect the difficulties of changing organizations with scale:
- Competition for the same budgets
- Dependencies between teams
- Requiring availability of the same services (such as operations or shared services)
- Culture adverse to change
- Lack of visibility across groups
- The organization operating out of silos
- Number of business stakeholders
There is not a well-defined line from small to medium to large scale.
With scale, increases the complexity of roles involved and it is important that all roles receive the same support through the transition. See Disciplined Agile Roles at Scale for an overview of roles at different scales.
Why Scale Matters
The scale of an organization will affect the approach one takes to agile transformation.
- At small scale, it is simple enough to start all of the teams doing some team-level approach such as scrum, kanban, or XP. Everyone can be trained at the same time and then work in the same manner.
- Mid-scale requires more effort and a principle-based approach, using well-defined steps that result in an emergent method. If the size of the organization being transformed is more than 150 people, then working on smaller groups up to 150 people at a time is best.
- Large-scale may require a predefined approach to get started. However, staying with the well-defined approach, as opposed to a principle-based approach, will almost certainly lead to stagnation as no one-sized fits all.
June 2023