Understanding “scale”

Agile started at the team level. Both Scrum and eXtreme Programming were designed and created for single teams. Scale back in 2004 meant three teams working together. So what do we mean by scale now? .

Scale is not defined by the size of a company but more by the relationship of business stakeholders to the teams involved in building what they want. We view scale as occurring at the group level in a company.  Many companies with thousands of developers in technology are not really large scale if they are comprised of independent sub-groups.A company may have one development organization or several. We think of scale as being at one of five levels:

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 degree of shared services (e.g., business intelligence) and ops is used in common 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 and requires shared services for the entire organization besides. Each program competes for funding from one main budget. These may represent a division in a very large company. 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

Clearly 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, 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), allocating our capacity, managing conflicts for capacity when more than one item is being worked on, and so on, are needed.

The bottom line is that even though the scales of the company have great variance that all companies have the issue of portfolio management. In particular, how do you decide what to work on and apply limited capacities to it.

Dynamics of scale

There are several factors that affect the difficulties of changing an organization:

• 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. The picture below depicts how the size of an organization alone does not define the scale involved.

Why scale matters

The scale of an organization will affect the approach one takes.

At small scale it is simple enough to start all of the teams doing some team-level approach such as Scrum, Kanban, XP, or Team Agility. Everyone can be trained at the same time and pretty much work in the same manner.

Mid-scale requires more effort but a principle based approach using well-defined steps that result in an emergent method can be used. If the size of the organization being transformed is more than 125 people (Dunbar’s number) then it is likely that working on groups up to 125 people at a time is best.

Large-scale may require a predefined approach to get started. However, staying with the well-defined approach will almost certainly lead to stagnation as no one-sized fits all.