Agile Team Organisation: Squads, Chapters, Tribes and Guilds

Agile Team Organisation: Squads, Chapters, Tribes and Guilds

There is a growing trend around agile company organization reorganization with Agile and Scrum.

Why Reorganise?

Obviously building a product that is flexible, high quality and that can react to market demand quickly is important, but for me having a process and organization that emulates this is as equally as important.

  • Party
  • Unit
  • Faction
  • Troop
  • Lineup

Scaling at Spotify

See below the example from Spotify:

How Can You Implement in your Team?

This concept works well if you have a quite large organization, and you have mature scrum teams. Spotify was born an agile company, so most of these things are sewn into their DNA, but for companies or teams transitioning to scrum it can be a lot more difficult, this concept needs a not of buy-in and and motivation from the team.

Renaming your ‘Teams’ / Squads

As I said before, if you want to remove the stigma of ‘Development Teams’ only containing developers, you can rename your team to one of the suggestions earlier in the post. I like the idea of a crew; reminds me of the crew on a ship — each has their role to ensure the ship stays on track to their destination; its a good metaphor to use.


Most companies will probably have a smaller variation of this, you will have a team of developers reporting to a manager, and a team of QA reporting to a different manager. In the teams that I work with I actually like to flatten the hierarchy and remove ‘Manager’ where possible. You can adopt this model by having your front office developers reporting to a ‘lead’, back office developers reporting to a ‘lead’ and testers / QA reporting to a ‘lead’. If you have full stack developers then it might be a little more difficult, but it can still be done.


Guilds can be a little more difficult to implement, they require motivation from the team and can require some degree of coordination. I would advise to start with something small, identify a problem or something that can be improved and get together a small group of team members together to solve it. Assign a lead to the group (does not have to be a ‘lead’ or management figure — its actually better if its not because it can give opportunity to team members) and use this as your ‘pilot’. Chose something technical ideally, something that the team would enjoy to work on, this way when other team members see the results and outcome, other guilds would easier to form. You can start in such areas as:

  • Testing automation
  • Security & vulnerabilities.
  • Services & Architecture
  • Documentation & Centralized information center (Wiki)





Tribes are a bit more difficult, and I would not advise you implement unless you have a large complicated infrastructure that needs to be split this way. If you have different applications such as web, mobile web, native client / native application or native mobile application, do not split these. You are introducing dependencies then, its for better to have an autonomous team that can build a feature and deploy it on all channels, and not have to wait for another team to complete. This may require changes in your architecture or process, but in end I think its the best way forward.


If you really want to get creative, you can arrange events for your guilds. One concept I came up with was ‘Guild Con’, this could be a day where each of the guilds presents to the others on what they have been working on, share tips and knowledge or even try to recruit people to join.


There are many ways you can reorganize and restructure your teams, but remember — renaming and changing where people sit will not solve all your problems. Your architecture and organization should dictate how you want to work, not the other way around. Remember, the goal is to be able to deliver quickly, high quality products and be able to scale. Model on how you want your teams to behave and the culture you want to promote.

  • Can you make sure each one of your features or departments gets the attention and development capacity they deserve?
  • Can you keep bureaucracy at a minimum (see Spotify for MVB — it’s a great concept)? This is important for scaling so designing, releasing and developing doesn’t become painful and political.
  • Can you ensure fast planning and a clean release process?

About the Author

Ashley-Christian Hardy

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.