The Internet is full of Absolutely Correct Ways™ to implement organizations to support Agile. What’s usually missing is context and scale. There are no silver bullets and size matter. Here’s a quick run-through of how I would scale an imaginary organization in a generic setup. Your mileage may vary.
Note: all employee counts below refer to devs / product / QA / analytics / design etc. people who directly participate in the product creation process. It’s excluded feature / product teams. You will most likely need further staff for foundational stuff like devops, infrastructure, etc. Integrating product development work with those functions is a topic for another day.
1–5 Employees: Freebird
Just lean back and forget process. If you have problems at this stage, information flow, planning, and decision making shouldn’t be among them. If they are, I am in awe of your ability to create problems.
If you have to have a process instead of just simple to-do lists, just run Kanban. It’s basically just a fancy to-do list anyways. (insert trollface here)
6–10 Employees: Scrum
This is where you need to start putting the first semblances of process and structure in place. You may not really need to, but in general, you want to have them in place a tiny bit too early, rather than too late. There’s no such thing as exactly the right time, but when it’s a tiny bit too late… it’s waaaaay too late.
What you’d probably like to see at this stage is 1 Scrum team running pretty basic vanilla Scrum, making sure you’re properly getting into the habit of forecasting dates. This is the earliest point where the scale starts really supporting this method.
Other than that, planning work and disseminating information really shouldn’t pose too much of a problem… yet.
11–20 Employees: Squads
Around the time you hit 10 people, you need to start dividing & conquering as Scrum works best with teams between 5–9 in size.
Basically this stage is just like the previous stage, but you’ve just got multiple autonomous Scrum teams. You’re still probably light enough on people where most “tech types” (QA, all devs, analysts etc.) can just report into one tech manager (although you might want to consider one per max 10 to allow properly focusing on humans), but you don’t really need the concept of guilds yet.
However you slice & dice the squads, make sure to keep them as decoupled as possible. Make sure they can execute on separate missions independently. This is way too early to start introducing handoffs, dependencies and bottlenecks into your organization.
21–40 Employees: Squads and Guilds
This is the sweet spot for the Squads and Guilds model: a matrix of decoupled work and competency management.
At this stage, you’ll want to have the people split into a structure of human / competency management (Guilds = who they are making sure the do things right) and a structure of work management (Squads = what they do making sure the do the right things).
As before, it’s critical to make the squads as autonomous as possible.
This is simply because the best way to scale up Agile is to not scale it up.
Keep things small. Keep them autonomous. But leverage the guilds to keep them aligned.
If you can achieve squads that live up to that maxim, you’re on your way to victory.
41–200 Employees: Tribes
This is where you start running into actual problems. Up until this stage your problem has been quantity of information — Making sure everyone knows everything at all times.
Around this time you start realizing that your problem is actually quality of information. Nobody has the cognitive capacity to know and understand every single detail in a 50+ person company.
You need people to know all the details of a small part of things, and people who know way more things (or all the things), but in significantly less detail. Managers, chain-of-command, all that good stuff.
So, how do you achieve this? Did I already say “keep things small”?
My favorite saying about big data is “there’s no such thing as big data — just a whole lot of small data”.
The same is true for your business. Most likely it’s a whole lot of smaller operations that form a holistic business. Almost anything can be boiled down to smaller modules or components.
This is where most companies fail in their scaling: they think they can just keep adding communication and amount of information, but ultimately reach a boiling point of complacency driven by too much information and the resulting cognitive overload.
Tribes
The beauty of squads and guilds is that it provides built-in defined points of contact that keep communication paths minimal.
Those communication paths allow employing the fundamentals of horizontal scaling to building organizations. Instead of beefing up a single organization, you split into autonomous tribes executing on larger separate missions.
Within a tribe is just a set of squads and guilds that operate largely in the way a separate 21–40 person organization would.
Now, to keep these loosely coupled tribes tightly aligned, your main leverage is the guilds. The guildmasters provide an awesome mechanism for cross-tribe alignment of things like design system, tech architecture, QA practices etc. All the things that benefit from being done similarly across the organization.
Want to make a global decision on which JS build tool to use? Gather the front-end guildmasters!
Need to discuss the future direction of typography? Summon the design guildmasters.
Need to update a set of NodeJS libraries across all applications? You get the gist.
The same is true for Squads. As long as each tribe is represented by a product lead, those leads, one per tribe, can collectively represent the entire breadth of product decisions across the whole business.
201 and Beyond: You’re on Your Own, Bub
Things get really tricky and highly contextual after this, and while nothing in this article is anywhere near a silver bullet at any size, I don’t have the hubris to recommend any one-size-fits-all solution beyond this range.
But I guarantee, whatever the solution is, it all starts from splitting the problem into smaller and smaller pieces.
Disclaimers
Now, I am absolutely aware that I’m completely ignoring a whole bunch of details here. No questions about that.
First off, as noted before, this structure is just regarding the actual product delivery org. You will need plenty of other bits and pieces in place to support this madness.
Second, I’m simplifying the management structure quite a bit. An actual tribe will most likely look much more like the graph I had in my previous article:
In the example above, the Design Guildmaster would report back into the design org. Maybe to a Director or VP of UX. Similarly, QA could just as well report back to a Director of VP of Quality.
That wouldn’t really change how the tribe operates nor how the communication channels into and out from the tribe work.
Third, I’ve left the guild structure intentionally vague. It’s highly contextual and depends radically on the nature of the products you’re building.
Did I already say there are no silver bullets?
Your mileage may vary.
