In the first session of my online course, Ship better code faster, I spend a few slides discussing where Scrum and DevOps each fit on an organizational chart:

Blue represents upper management, or the C suite. Pink, middle management. Green, product management, technical leads, etc. Yellow, individual contributors (developers, designers, etc). And the rectangles at the bottom represent tools, servers, etc.

The blue oval encompassing green and yellow represents Scrum, and the second blue oval represents DevOps.

The big question left unanswered was: How do we apply Agile at the higher levels of the organization (Blue, Pink, and Green in the graphic)?

How do you scale Agile?

I think this is mostly the wrong question to be asking. Agile, as defined in the Manifest for Agile Software Development, is about individuals and interactions. This is not something that can really be scaled, in exactly the same way that an atomic family (roughly: parent(s) and their immediate offspring) cannot be scaled.

When you scale an atomic family beyond a certain size, you no longer have a family, but instead a tribe, village, city, or nation. Hopefully this macro-level organizational unit allows for healthy atomic families as well, but should never be confused with family (and rarely are, except perhaps in some extreme cases of cult followings).

In the same way, I see that an organization can be made up of many agile groups, but scaling agile itself is not really possible, nor desirable. The things that make a small group agile (team backlogs, sprints, daily communication, etc) when applied at a higher level lead to “processes and tools” and “following a plan”, rather than “individuals and interactions” and “responding to change”. In other words: they can actively hinder agility.

Instead we should focus on allowing and fostering agility, not scaling it.