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 thatcan react to market demand quickly is important. For me having a process and organization that emulates this is asequallyas 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 whoembrace 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 examplewhen 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 asustainable model.
Conflict
You will find there will start to be conflict. People stepping on each others toeswhich isonly resolved usually by assigning roles and responsibleness.
Scrum promotes that you havefeatureteams,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 alsorename 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 agood 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 greatway topromote teamwork, collaboration and innovation, as well as givingteam members ownership and a sense of enablement.
Scaling atSpotify
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 thatown a certain part of functionality end to end. For example the search or recommended artists.A squad (scrum team)will have adedicatedproduct ownerwho will feed them user stories to build.This is the pretty standard set up for any organisation doing scrum.These squads sit together andhaveone long term mission.
They have all the skills and tools neededto design, develop, test and release to production, being anautonomous, self-organising teamwho are expertsin their product area.They are kind of like mini start ups.
Granularity
Spotify goes quitegranularwith its teams, so thesesquads 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 usually100 or less per tribe.
The Spotify Model implements such things as shared lounges to create inter-squad interaction, andregular informal teamevents and get together where the squads share what they are working on.There is a role ofTribe Leaderwho 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 developersget together and exchange ideas or get help on challenges and new technologies.
Forexample 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.Thereis a role ofChapter 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 area group of people across the organizationwho 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 coachingguild.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 takeawayfrom 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 toflatten 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 — itsactually 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 canstart 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 complicatedinfrastructure that needs to be split this way.If you have different applications such as web, mobile web, native client / native application or native mobileapplication, do not split these.
You areintroducing 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 becomedifficult 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:
