Tribes, Squads, Chapters and Guilds are an important, part of Spotify's Agile terminology. It's a useful set of terms, but it can get confusing. That's fine for Spotify, but it becomes a bit of a problem when deployed anywhere else. That's not to say it shouldn't be used but instead that the terms we use in Agile need to be demystified before we start using them widely. After all, Agile should ease complexity, not increase it. In this blog post we’ll take a look at what tribes, guilds, squads and chapters actually are, and how they compare to one another in plain English.

As a very quick overview - Tribes, Guilds, Squads and Chapters compared:

• Chapters organise by skill sets.
• Squads then collect clusters of people from different Chapters and have them all work towards delivering a product or service. 
• Guilds are looser collectives of people who are organised around a shared interest or goal, (they remain in their Chapter and Squad while being part of a guild)
• A Tribe is a whole cluster of Chapters and Squads (with Guilds running through them). It’s a big collective group all organised around achieving a big central mission for the organisation.

The first time someone suggested that the team I was in should be referred to as a Guild, I wasn’t sure whether to laugh (can I look forward to being clustered into ‘Battalions’ by 2024?) or cry (what fresh hell is this and why does everyone seem to know about it but me?)

Three or four years since then, I’ve become a convert to the terminology. However, I still have empathy for anyone who views these titles as a particularly off-putting part of Agile. This 4 minute read is an attempt to demystify the terms - and provide a few pointers for making it work.

This stuff is always in flux and being iterated in different directions, so expect organisations to have a few different norms and definitions, but the below will be enough to get anyone started with some fairly solid, universal concepts. Right, enough background, here we go…

What is a chapter in Agile?

A Chapter is a bit like a traditional team. It's a group of people who all do a similar thing, with related skills. If you’re an accountant, you’d expect to be in a team with the other accountants. The same goes with Chapters. 

An organisation will typically have multiple Chapters clustered around what people are employed to do. So far, so simple. However, in the days of traditional teams, the collective would have some shared high level deliverables that they work to achieve as a whole.

The problem here is that sometimes different parts of the organisation have very different needs. Organisational to-ing and fro-ing - as demands change - and trying to balance competing priorities can prove maddeningly slow and clunky for all involved. As such, leaders of an Agile bent started to organise people within Chapters around separate deliverables for different parts of the organisation.

Okay, so what are Agile Squads?

Squads are teams of around 8 people. They are pulled from different Chapters, to work together on a certain product or service.

The diagram above shows one person from a specific area, but it doesn’t have to be like that; squads can be resourced in whichever way most effectively fits the specific deliverable. 

These Squads don’t necessarily exist forever. They come together only for as long as they’re required or useful, and can be split up again when the work is done. Members might be swapped out for ones that are better suited to the next project. 

When people leave a Squad, they remain within their Chapter. They can either be deployed into a new Squad somewhere else, or work on useful internal things for the Chapter. 

Most organisations will have a few different Squads, all focusing on distinct projects and initiatives. This is helpful for two reasons. On the one hand it means that each squad is oriented towards the ultimate deliverable, and providing value to the end user (whether that’s an external customer or just another part of the business). It means the product or service the squad is working on is central to every day’s work, rather than being some abstract thing you rarely consider or come across in your role. On the other, it means that there are people with diverse skill sets working together on the same project - this means different capabilities and different perspectives are brought together to solve a problem. That means the approach to problem-solving will be more robust and comprehensive.

Why Chapters are an important foundation for Squad work

There’s sometimes a concern that the Squad model can lead to duplication, or that it becomes difficult to scale. That’s why the Chapters are there as a base. People still have links back to people with similar backgrounds and skill sets, so as a result, best practice gets discussed and discovered through word of mouth between people in each Chapter.

What is a Guild in Agile terminology?

Guilds are created around initiatives the organisation wants to encourage or support. From Respect & Inclusion to Internal Process Innovation, Guilds offer a chance for people with similar passions and concerns to work together on their chosen or given subject. Similar to Squads, Guilds can be stood up and down as desired, depending on the subject area.

Importantly, Guilds exist across Chapters and Squads without displacing anyone from their current area. You can be part of multiple Guilds at once if you have the time; some Squads might have multiple people in the same Guild, while other Squads have no representation. That shouldn’t be a problem provided work is getting delivered well (from both the Squad and the Guild).

What is a Tribe?

A Tribe is the overall category that Chapters, Squads, and Guilds sit within. People will sit within a Tribe, while being part of a delivery Squad deployed from a Chapter, and quite possibly contributing to a Guild all at the same time. 

Unsurprisingly, Tribes tend to be relatively big compared to the composite groups that they contain (circa 80-150 people, but again this will vary from context to context). An organisation is likely to have many different Tribes, all organised by key missions, such as improving the in-App experience, or delivering new products. The Tribes can still communicate with one another, and share best practice. However, it is likely each tribe will have less overlapping needs and goals, simply because of the different nature of what they are trying to achieve.

Making Tribes, Guilds, Squads and Chapters work in practice

So, that’s the lingo dealt with. If that all makes sense and you want to think about making it work in practice, here are a few things worth remembering:

Missions Matter. The whole enterprise falls over if you get your missions wrong, and people end up being organised into separate Tribes despite actually having very similar goals requiring similar tools, skills and ideas. Think carefully about what your organisation is trying to do, and put defined and distinct missions in place.

Releases Require Regulating. With everyone working on different things and to different timelines, things can get out kilter on the day when something new is released. This will inevitably lead to a mess where things don’t work. 

Two common ways exist for making this more manageable (possibly more than two, but these feel most important to me). Firstly, using platforms and code which allow you to build in a modular way, where uploads can happen separately without breaking other components. Secondly, ‘release trains’ where information regarding what is planned to be released and when is shared across the organisation in a coordinated manner. This, published well in advance, gives sight of the plans to everyone with linked dependencies and catches problems early.

Communicate Constantly. This doesn’t mean constant meetings. It means make the work Chapters, Squads, Guilds and Tribes are delivering as public as possible. Share as much information as feasible, so that if anyone wants to know what software people are using, or who is in charge of what, they can find out easily. This is vital in avoiding duplication and needless mistakes.

Micromanagers Make Mistakes. This whole construct depends on trust. Chapter or Squad Leads who want tight control of what their people are doing will break the whole model. People need to move between different responsibilities and communities as required, with an aim to create well-rounded and self-sufficient team members. It might feel nerve-wracking at first, but anything new and progressive always does.