This is a verbatim transcript of the third video on XSCALE’s principles of agile organization, available on Youtube.

Welcome to the fourth webinar in our series on the principles of agile organization.

Peter Merel

In our first three webinars, we looked at exponential return by stacking growth curves, simple design of products in terms of their service ecosystems, and continuous throughput by opening bottleneck constraints.

These are about the business bottom line, but agile is first and foremost a way for small teams to collaborate efficiently. Today’s webinar is about how these teams can self-organize and self-align around this bottom line, but let’s begin by understanding the problem we’re trying to solve.

General ‘Buck’ Turgidson: “The aircrafts began penetrating Russian radar cover within 25 minutes.”

President Merkin Muffley: “I was under the impression that I was the only one in authority to order the use of nuclear weapons.”

General: “The idea was a retaliatory safeguard …”

President: “A safeguard?”

General: “… to discourage the Russians from any hope that they could knock out Washington and yourself and escape retaliation because of lack of proper command and control.”

Dr Strangelove, movie by Stanley Kubrick (1964)

That comedy of errors was written by defense analysts, afraid we’d blow ourselves to extinction. But Kubrick’s understanding of military command was a century out-of-date when dr. Strangelove was filmed.

Von Moltke invented ‘elf tracks tactic’ back when armies still lined up facing each other like pawns on a chessboard. He discovered that so long as small teams share a superior framework of intent, organized by direct feedback, they can swiftly outmaneuver a much greater command and control opposition.

This idea was fundamental to the German conquest of Europe in World War II. Independent squads of Panzers swarmed around the impenetrable, but immobile, 12 billion-dollar French super trench fortifications, like ants on a caterpillar.

The Royal Navy ruled the waves, until wolf packs of ravaging u-boats decimated the fleet by surfacing to attack on masts at night.

Europe had no idea how to respond and it was only rigid command and control by the German High Command that stopped the Nazis from conquering the continent from London to Moscow.

It takes real change in leadership philosophy for an organization to make mission command its entire basis.

Now we want numbers to generate change. We can only optimize what we measure. An agile organization wants a metric to distinguish between efficient structures and inefficient ones.

The maximum number of conversations that have to happen for two members of an organization to collaborate. That’s what we’re going to use. We’ll call it the collaboration loop limit.

In a little command-and-control team this limit is just four: worker 1 - manager - worker 2 back to manager and back to worker 1.

Scaling to include a program manager doubles the loop limit. At the scale of a PMO or business unit it’s triple. An Enterprise PMO of a large corporation has a loop limit of over 16 hand-offs.

As the limit grows, the time taken slows exponentially and confusion created by passing messages down lines of middlemen multiplies. The left hand no longer knows what the right is doing.

But there’s far greater complexity than this in the organization of any human body. And your left hand almost always knows what your right is doing.

In the 1960s Arthur Koestler noticed that organizations like your body have no middle managers. The palm of your hand doesn’t manage its fingers and your shoulder doesn’t manage your arm.

Each form is just a repeating pattern of the behaviors of its parts and each part is just a repeating pattern of behavior of its parts. And so on, down to atoms down to quarks.

Custer coined the word Holarchy to describe the pattern of patterns of patterns. Before him, Leibniz called them Monads and after him Mandelbrot called them fractals. In fact, all natural forms work this way.

So we don’t need any special words for them. The special word is for the only form of organization that doesn’t work in a natural way, and we already have that. We call it a committee.

Agile starts with the idea that small teams don’t have to form committees. They serve the superior framework of intent by continuously pairing, refactoring, and prioritizing bottom line throughput.

But can ‘agile’ really scale without command and control? That would be a combinatorially explosive proposition, so it’s the wrong question to ask.

The right one is: can an organization descale into agile teams without command and control?

The answer to that ends on consistent prioritization. Can we define a superior framework of intent in terms of interlocking BDD feature specs?

Indeed we can. Lean UX calls a group with this responsibility a product team. We call them a product squad, because they’re working to an agile cadence, using agile ceremonies. The product squad’s made up of business authorities, design authorities and technical authorities, collaborating to optimize bottom line throughput, as in our last webinar. It delivers BDD feature specs to feature delivery squads downstream, who in turn provide representatives to take part in it. That way estimation and prioritization are direct conversations with no middlemen.

What we need if we’re serious about self-organizing teams is a simple decision-making protocol to harness the best thinking of all the members of the product squad. Indeed of any agile squad. So here’s a well proven practice pattern that does exactly this.

The Iroquois confederacy represented the dominant civilization in North America for almost 500 years.

The Iroquois were founded in the 13th century on a code invented by two men: the famous Hiawatha and a Huron inventor they called the Peacemaker. This great law centered around a tiny practice pattern for consensus decision-making we call leadership as a service. In fact we already use this pattern as part of our agile planning poker games.

It works like this. We’ve put a person in charge of decision-making timeframes and protocols. The Iroquois called them a War Chief. We’ll call them a coach.

If the team can’t reach a unanimous decision within the required time frame, there’s a second role. The Iroquois called them a Sachem. We’ll call them a leader.

If the team reaches unanimity, the leader doesn’t get to overrule them. The leader can influence their decision, but the leader only gets to make the decision if the team gets stuck. And only the coach determines when the leader is to take the decision out of their hands.

That prevents command and control compromising the self-organization of the team. The assignment of a leader role is best varied depending on the expertise and commitment required to each decision.

In Jobs’ Apple, domain-specific leaders were called DRIs - directly responsible individuals. Every agenda item in an apple meeting had to have a clearly identified DRI. Each DRI leveraged the other’s innovations to drive their particular direct responsibilities. So the throughput of the team became a product, rather than a sum of the throughput of its members.

Leadership as a service provided by the DRIs makes the difference between a collaborating team and a compromising committee.

“Do you know how many committees we have at Apple? No? Zero. Have no committees. No committee. We are organized like a start-up … whole business. And there’s tremendous teamwork at the top of the company which filters down to tremendous teamwork throughout the company. And teamwork is dependent on trusting the other folks to come through with their part, without watching them all the time. You have to let them make a lot of decisions, and you have to be run by ideas, not hierarchy. The best ideas have to win.”

Steve Jobs

In an agile feature delivery squad, each story attaches direct responsibility to one or two individual team members. We call it a feature squad because, the story backlog zips up to represent the team’s delivery of one releasable feature at a time.

This is a form of mission command that drives productivity and quality, but has the disadvantage of impeding the flow of learnings between the squads. So in XSCALE we recommend chapter meetings, popularized by Spotify’s Henrik Niberg.

Once a week, at a time immediately preceding squad retros, all people of a common competency meet. All the devs meet with each other and at a separate table all the testers meet and separately all the analysts and so on. The chapter meetings all occur simultaneously, so the squads are never starved of any particular competency.

The subsequent squad retros align each squad’s local improvements to the context of all the squads in the portfolio.

The product squads are likewise aligned by chapters. Each product squad defines the head of a value stream. Each is responsible for feeding features with BDD specifications to some small number of feature delivery squads.

Because the members of the product squad also fulfill BaU functions, the product squad isn’t 100% resourced like the delivery squads. It’s a virtual team that only exists through a repeating cycle of agile ceremonies.

Each product squad has a coach and a leader to empower it to make decisions using leadership as a service. These two roles work hand-in-hand no matter whether they’re providing servant leadership to the product- or feature squads in their stream.

Each feature squad must avoid colliding with its peers. System squads decouple feature squad dependencies through decentralized version control and virtualized environments, in order to empower them to integrate asynchronously. Whenever they like.

System squads each also identify a pair of servant leaders. System squads treat feature squads as customers for their services. And also as service providers for changes to the features of their services. And that is DevOps.

Each system squad also provides subject matter experts to take part in a stream’s product squad to help define its technical priorities. And analytics to quantify the stream’s bottleneck constraints.

During the weekly chapter meetings each chapter picks a representative to attend a subsequent meeting of a portfolio squad. That’s a virtual team that makes decisions about the organization of the portfolio of squads as a whole.

The portfolio squad also enrolls product leaders and systems leaders. And naturally it has its own leader and coach pair to provide it with leadership as a service. Because it makes decisions by collaboration and consensus among doers, not command and control by middlemen, the portfolio squad sharply reduces the collaboration loop limit of its portfolio.

For this to work you have to respect the Dunbar number. That’s a limit on the number of simultaneous face-to-face trust relationships a group can maintain.

Dunbar was an anthropologist to observe that when this number is exceeded in a tribal society, the tribe immediately breaks into two who fight each other.

This number turns out to be about 150, but since people also maintain trust relationships outside their portfolio, a maximum size of a hundred is prudent.

Indeed Jobs applied this limit to the original Macintosh team telling them that if they had to hire anyone beyond that he’d fire someone.

In practice we needn’t do anything so drastic: we can simply split out a stream or two as the kernel of a new portfolio.

At scale, guilds deal with issues that cut across the portfolios. There’s a guild for coaches and one for leaders each aligning on direction and approach. Guilds can be established to deal with any repeating cross-cutting concerns like legal compliance, technology tracking, marketing, environmental or social contexts. The cadence of each guild depends on the needs of its membership.

Guild meetings afford far superior communications bandwidth than traditional EPMO or scrum of scrums of scrums. The overarching intent of this model is to apply Holarchy to reduce the portfolio’s collaboration loop limit.

Squad members meet directly in chapters, so the limit there is just two. The attendance of chapter leaders at the portfolio squad bumps that up to four. Four compares very favorably with a loop limit of 12 we saw in a traditional PMO. And that’s the quantitative distinction between committee hand-offs, versus collaboration hand-in-glove.

This portfolio model also supports continuous innovation. As a value stream matures Kano effects inevitably cause diminishing return on investment. As a portfolio squad is responsible for maximizing bottom line throughput, it can flip any bottleneck stream into innovation mode.

Or it may refactor squads from the existing streams into a new steel thread stream in innovation mode. That mode of work is familiar to us from hackathons, 20% time, FedEx days and so on.

The only difference here, is that the XSCALE innovation mode involves no multitasking versus production. The mode continues until the stream has numerically established a viable business case based on the pirate throughput metrics described in our previous XSCALE webinars.

At this point the whole stream flips back into a production mode. This way innovation is not the sole prerogative of some separate skunkworks room with a bunch of creatives wearing funny hats. The creatives are fully integrated into each value stream to drive it to extropy.

Now if that’s an unfamiliar word you should check out our first webinar.

This grid illustration of the agile portfolio model is great for understanding a structure of responsibilities, but a different layout helps us see how each squad plays a part in a learning Holarchy that composites all the build-measure-learn-refactor loops into a fully agile organization.

This is called triple loop learning. Learning what to deliver to market for maximum impact, how to optimize productivity doing that, and how to learn how to do these things.

Now that third loop is the meat and potatoes of transforming your enterprise into an agile organization and this will be the subject of the fifth webinar in XSCALE Alliance’s six part series on the principles of agile organization.

I look forward to seeing you next time!