How to Efficiently Scale Agile
There are two ways to scale agile: horizontally or vertically.
When a company scales agile horizontally they increase the number of specialized teams required to produce customer value.
On the other hand, when a company scales agile vertically they increase the number of cross-functional people within a single team so the team can produce customer value from discovery to delivery without any cross-team dependencies.
Both models strive to achieve economic efficiency within the product development lifecycle.
But innovators and early adopters of emerging frameworks like Fluid Scrum, Fast agile, and Continuous Discovery are finding vertical scaling better than horizontal scaling.
The Economics of Scaling Agile Horizontally
When a company scales agile horizontally they are trying to leverage economies of scale through specialization.
To do this, companies split people into teams based on role around a specific technology or business capability.
A common workflow is for a UX team specialized in collecting and distilling customer feedback outputting work to a design team specialized in turning ideas into high fideility prototypes outputting work to an engineering team specialized in coding designs into working product all overseen by a product manager who specializes in managing these hand offs.
This example is extremely reductive.
But the core idea is that each of these specialized teams operate independently but must work collectively to product customer, and in turn, business value.
Intrateam Efficiencies
The hope of specialized teams is their ability to self-improve to reduce operating costs.
Any improvement in one team are immediately translated into profit.
For example, if an Engineering Team at a profitable company reduces their server infrastructure costs by $1,000 then the company immediately realizes $1,000 in additional profit.
The hope is that successful self-improvement across each specialization will trickle up to this bottom line.
However, regardless of how efficient a single specialized team is, every team has a finite amount of capacity.
Cookie Cutter Scaling
Whenever a single team becomes a bottle neck that cannot be solved by better practices, dependent teams become idle and are not producing customer value.
To minimize idle time, companies try to build specialized teams in a way that is easily duplicated.
This way, when a bottleneck emerges the company can simply duplicate the team to provide more capacity.
As this cookie-cutter scaling gets deployed, it becomes necessary to standardize how teams hand-off work.
Intake Commoditization
Cookie-cutter scaling requires companies to use backlogs and standardize (commoditize) backlog items to minimize idle time by giving teams with a continuous supply of work.
Standardizing hand-offs between dependent specialized teams lets any team pass work down to any other team that has capacity: decoupling teams.
This lets each specialized teams cookie-cutter scale up or down to meet the current or expected capacity of the company and ensures teams are always fully utilized.
The pitfall is that teams are no longer reacting to the open market.
Surviving by Edict
Companies must adapt to the open market to survive.
But when the market changes, decoupled specialized teams working only from backlogs cannot calculate the new value of old ideas.
For example, if Engineering Team A was about to start Backlog Item#1234 but they learned in the newspaper a competitor tried and failed at that idea last week what should they do?
Possibilities are
- Ignore the information and do the work as if nothing was learned
- Delete the item because it already failed
- Sent the item back up the chain with this new information in mind
- Other
Each of these possibilities require an authority that exists outside of the specialized teams and is aware of market conditions to make these decisions.
This authority must continuously revalidate, reprioritize, and manage backlog items based on new market conditions so that each specialized team is maximizing the value they produce.
If a company is producing valueless work, that is waste.
Since this authority has a unique cross-company view of the work and teams involved, only this authority can coordinate urgent work.
For example, only this authority can tell specialized teams to halt all in-progress work so they can immediately jump onto time sensitive critical work coming down the pipeline.
In most companies, this authority is the specialized product management team.
Without this centralized authority, companies would be unresponsive to changes in the open market.
Realizing the Costs Scaling Agile Horizontally
Scaling agile horizontally achieves economic efficiency through reducing operational costs and maximizing utilization.
Traits managed through local optimizations within each specialized team and growing backlogs managed by cookie-cutter scaling with the overhead cost to formalize when, why, and how people work together.
Backlogs become fragile as the market changes.
Hand-offs lose meaningful context and encourage a fire-and-forget mentality leaving little room for clarity because the central authority must weigh that clarity against new in-progress work from upstream teams.
This cost of scaling agile horizontally is realized in hand-off meetings, support documentation, and log feedback loops and people jump from project to project and increase the chance for miscommunication and jeopardizing the customer and business value of the work itself.
So, emerging agile frameworks are finding success scaling agile vertically by creating huge generalist teams to embrace the power of individuals and interactions over processes and tools.
Agile for Modern Product Development
Scaling agile vertically is when a company adds more cross-functional people to a single team so that the team can produce customer, and business, value without any external dependencies.
In the Continuous Discovery framework this means a single team is capable of both discovery and delivery work.
Discovery is when a team generates and validates an idea in the market before quickly moving to delivery where that same team then turns the idea into customer and business value.
Unlike specialized teams, this self-sufficiency ensures generalist teams are never waiting (i.e. max utilization) because the team has all the necessary skills to always keep itself moving forward.
Too Much Pizza?
Cross-functional teams are seen in many companies at smaller scales following the two-pizza rule.
The two pizza rule suggests that teams should be no larger than than 8 to 12 people and as a corollary encourages scaling agile horizontally.
However, as companies grow to include UX, Design, DevOps, Security, Support, Data, and many other roles it becomes impractical to find and create such a 12 person unicorn team.
So again naturally companies think to divide people into smaller more specialized teams to cover all these areas.
But frameworks like Fast Agile and Fluid Scrum are proving that huge generalist teams deliver end-to-end value faster than chains of specialized teams at sizes of 50 or more people.
Breaking the two-pizza rule allows for huge generalist teams to cover all required roles to own the entire product delivery lifecycle without the overhead of backlogs or a centralized authority like specialized teams.
Instead, huge generalized teams break down walls and create shared goals to let specialized people have cross-functional customer and business focused conversations through self-organization.
Self-organization
Huge generalist teams stay adaptive through self-organization.
Self-organization allows people to contribute in whatever way they see fit with the mission to always keep the team moving forward.
This allows the team to evolve with the market like an animal in the wild without the bureaucratic cost of standardizing when, why, and how people work together.
Likewise, self-organization encourages innovation from anywhere and by anybody which lets huge generalist teams easily adapt and jump on new opportunities within the market.
Letting huge generalist teams react to the open market without the need for a centralized authority to manage the work to be done.
Characteristics which make huge generalist teams more economically efficient because they are self-regulating.
Too Much Context Switching?
A common concern with self-organization is that people will jump from fun idea to fun idea to the determent of keeping the lights on or never actually finishing anything.
In practice though, individuals own their work from start to finish and only switch when (a) the work is done, (b) the work is learned to not worth doing, or (b) to help others.
These three actions all naturally maximize value produced and utilization.
Self-organization works because impassioned people work collectively inside the big picture to always keep the most valuable work moving forward.
Conclusion
Companies know individuals and interactions are more valuable than commoditized processes and tools for modern product development.
Companies today build cross-functional teams but do not add enough of the right people to truly realize their potential.
The common two-pizza rule does not give teams enough role diversity or capacity to meaningfully be self-sufficient to do both discovery and delivery work.
Additionally, specialized teams remove people from the innovation process and increase the amount of bureaucratic overhead required to bridge the communication gaps between them.
Scaling agile horizontally strives to achieve economic efficiency by driving costs down at the lowest levels of an organization and that such overhead is natural.
But huge generalist teams of 50 or more people evolve organically with the open market without such bureaucratic overhead or gaps in communication showing a different path forward.
Self-organization allows huge generalist teams to efficiently reorganize themselves around the most valuable customer or business work to be done with true end-to-end ownership.
Ownership created from specialized individuals and interactions over bureaucratic processes and tools to build more mission driven, adaptable, and customer orientated products.
