Agile Team Organisation: Squads, Chapters, Tribes and Guilds

Agile Team Organisation: Squads, Chapters, Tribes and Guilds

There is a growing trend around agile company organisation reorganisation with Agile and Scrum. A structure made popular by the Spotify model, converting your organisation into Squads, Chapters, Tribes and Guilds.

Why Reorganise?

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

“Don’t just fix the product, fix the process too”

If we look at real life examples of company’s who have failed, who cope with legacy technology, and those who embrace change and innovate. The image speaks volumes:

One of the key reasons is scalability. As your company grows, you need to be in a position to expand and grow easily and painlessly. Especially in smaller companies. For example when you have a small startup, usually roles are quite vague and people generally do what ever it takes to get things done. This is fine in the early days because you need to move fast and deliver, but as you grow this is not a sustainable model.

Conflict

You will find there will start to be conflict. People stepping on each others toes which is only resolved usually by assigning roles and responsibleness.

Scrum promotes that you have feature teams, fully autonomous teams that have end-to-end responsibility for what they build:

Naming convention

Many companies utilise this; Spotify being the most famous at the moment and are currently the poster-boy for Agile. In my own experience this is one of the most optimal ways to manage product development. This spawned the creation of the ‘Spotify Model’. In the Spotify model, they also rename their development teams ‘Squads’ which is a cool idea to get over the stigma that a Development Team should only contain developers. 

I have looked into other companies that have adopted this naming convention, and some that have even come up with their own such as:

• Crew
• Party
• Unit
• Faction
• Troop
• Lineup

The impact

Although renaming your team won’t automatically change everything and make your team instantly more effective. If you are making some organizational changes, restructuring or adapting scrum from waterfall — its a good way to detach yourself from the old way of doing things and can make the change more of an impact.

The Spotify model also introduces the terms ‘Tribes’, ‘Chapters’ and ‘Guilds’, which I have experienced (not with the naming convention). The objectives of these teams is a great way to promote teamwork, collaboration and innovation, as well as giving team members ownership and a sense of enablement.

Scaling at Spotify

The Spotify Model

See below the example from the Spotify model. With a brief explanation on how they structure into Squads, Chapters, Tribes and Guilds.

With the Spotify Model, they split its teams up into very small ones that own a certain part of functionality end to end. For example the search or recommended artists. A squad (scrum team) will have a dedicated product owner who will feed them user stories to build. This is the pretty standard set up for any organisation doing scrum. These squads sit together and have one long term mission. 

They have all the skills and tools needed to design, develop, test and release to production, being an autonomous, self-organising team who are experts in their product area. They are kind of like mini start ups.

Granularity

Spotify goes quite granular with its teams, so these squads are grouped together in what they call ‘Tribes’. These are a collection of squads within the same business area. For example their could be a tribe focusing on mobile. The squads within a tribe sit in the same area, and there are usually 100 or less per tribe.

 The Spotify Model implements such things as shared lounges to create inter-squad interaction, and regular informal team events and get together where the squads share what they are working on. There is a role of Tribe Leader who is responsible for providing the right environment for all the squads.

Chapters

Chapters are another way that The Spotify Model promotes team collaboration and innovation. Chapters are a group or team members working within a special area. So for example a squad might be made up of front office developers, back office developers, database administrator and testers. So a chapter could be a ‘front office chapter’, where front office developers get together and exchange ideas or get help on challenges and new technologies. 

For example one developer might start using AngularJS on a new feature, and will relay to the rest of the chapter his experience and discuss on how other squads can use it. 

This is a great way to promote innovation and ‘cross pollination’ of ideas across teams. There is a role of Chapter Lead who is the line manager for chapter members. They are responsible for developing people and setting salaries, but they remain part of a squad and still do day-to-day work.

Guild

Finally, there is the concept of a guild. A guild is a community of members with shared interests. These are a group of people across the organization who want to share knowledge, tools code and practices. 

Each guild has a co-coordinator, and such guilds include: web technology guild, test automation guild or even an agile coaching guild. There can also be guilds on such things as photography, design or any other common interest.

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. 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.

Although you might not be able to implement this model, there are some things that you can take away from it:

Renaming your ‘Teams’ / Squads

Iif 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.

Autonomy

However, your team must represent this, they need to be a fully autonomous, cross functional team that has full responsibilities and little to no dependencies on others. Ideally teams should be around 5 to 7 people in size. 

This ensures that they can be easily managed and any meetings can be kept efficient, any smaller and there is no real value and any larger the team becomes more difficult to manage.

Chapters

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

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:

• Performance monitoring / optimisation
• Testing automation
• Security & vulnerabilities.
• Services & Architecture
• Documentation & centralised information center (Wiki)

You can even add badges or logos for your teams to add a bit of ‘fun’ to it.

Below are examples taken from an online gaming/betting website:

Clans

Team

Guilds

Tribes

Tribes are a bit more difficult. 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.

GUILD CON

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.

You could also arrange ‘hack days’ or team challenges for your guilds, to come up with a new concept, idea or prototype to be judged at the end of the day for a prize.

By doing something like this, give the guilds more of a sense of purpose, and can be great for team building

Summary

There are many ways you can reorganise and restructure your teams, but remember — renaming and changing where people sit will not solve all your problems. Using Squads, Chapters, Tribes and Guilds. might not be best for you. Your architecture and organisation 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.

Some questions

Some questions you should ask yourself are:

• Can your teams scale with growth? Think about different scenarios; what id your company needs to produce a new type of product? What if your company goes into a new market? What if your company buys another company?
• 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?

Although this method is great and very idealistic, it too comes with its difficulties.

For example, with so many ‘micro’ teams, it can become difficult to ensure knowledge does get transfered, and the teams don’t become siloed. 

This for sure is needed if for example one squad needs to do some work on another squads code base, and even on a product level.

Everyone still needs to be in sync and going towards the same strategic goal. 10 squads going in their own direction isn’t going to help anyone. This is why vision is so important, which I will cover in a separate post.

If you want to see more about how Spotify structures into Squads, Chapters, Tribes and Guilds here with the Spotify Model:

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Social Media

Please check me out on social media:

• Facebook
• Instagram
• Medium
• Link
• Pinterest