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.

“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:

Team Organisation

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.

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:

Team Organisation

Many companies utilize this; Spotify being the most famous at the moment and are currently the poster-boy for Agile, and even in my own experience this is one of the most optimal ways to manage product development. Spotify also renames 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

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.

Spotify also introduces the terms ‘Tribes’, ‘Chapters’ and ‘Guilds’, which I have experienced (not with the naming convention), but 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

See below the example from Spotify:

Team Organisation Spotify

To explain, Spotify splits 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.

As I said, 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. Spotify 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 are another way that Spotify 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, get help on challenges and discuss 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.

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, 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 lot 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 

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.

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.

Team Organisation

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.

Team Organisation Chapter

 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 / optimization
  • Testing automation
  • Security & vulnerabilities.
  • Services & Architecture
  • Documentation & Centralized information center (Wiki)

Team Organisation Guild

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 Organisation Clan

Teams:

Team Organisation Team

Guilds:

Team Organisation

 

 Tribes

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.

Team Organisation

 

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.

Team Organisation Guild Con

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

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 does this, you can go here:

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

 

See corresponding slides below:

 

Ashley-Christian Hardy
full-stackagile.com
Process hacker, optimizer and team motivator. Blogging my ideas, initiatives and innovations. Certified Scrum Master/ Product Owner & Agile Project Manager

Please don’t forget to add or follow me on the following social media!

socialmediaicons

Web: www.full-stackagile.com
Email:achardy@full-stackagile.com
Twitter: twitter.com/achardypm
Facebook: facebook.com/fullstackagile
LinkedIn: mt.linkedin.com/in/achardypm
SlideShare: slideshare.net/ashlychrstn
Medium: medium.com/@achardypm
Pinterest: pinterest.com/achardypm
Instagram: instagram.com/achardypm
Tumblr: tumblr.com/blog/achardypm

 

If you like, take something away or reference any of my content, please consider leaving a small donation to help with the running of the site! To make a small donation simply click on the button below. Thank you very much in advance!

 

21 Comments

  1. This presentation floats around since 2012. Is Spotify still doing it the same way? Nothing has changed during these four years? No improvements?

    1. I’ve recently been working on launching a project management tool which is based on an improvement of Spotify’s methodology. If you’re interested in taking a look at it let me know with a reply. 🙂

    2. Hi, I think so yes. Maybe not 100% the same, but the foundations are in place and I very much doubt much would have changed. I think they have invested a lot into this model because of its scalability, and the frameworks ability to adapt. For sure there are probably improvements made; but Spotify hasn’t really changed its business model of the past few years, so I assume their product delivery is being done the same way too.

    1. Hi Adam, thanks for the feedback! Let me know how you get on with this! If you need any more information don’t hesitate to contact me.

  2. Would like to know how this Squad/Chapter/Gilde approach works regarding the meetings.

    Would like to implement that without blowing up meeting hours.

    Best

    Ingo

    1. Hi Ingo, for sure it can be a fine line, and you don’t want to be having so many meetings that it disrupts work. What I have found is that some agile teams create specific tasks that go into their sprint planning to cover off these hours; you can even discuss in the sprint planning if they are needed for that sprint.

      Its important to maintain the existing scrum meetings, and ideally you would have a time when all the guilds have their time together, at the same time. I don’t think it needs to be more than 1 or two hours a sprint – the main thing to achieve is that the members of the guild get together and share ideas and experiences. It doesn’t even need to be all the members at once, maybe 2 or 3 meet the first sprint, 4 the next and so on. By sending round meeting notes, or even creating a shared space in Confluence or Sharepoint for these teams to communicate, or a channel in slack – you can think out side the box a bit here, there are no rules 🙂

      If you are concerned – I would even take an agile approach with it, start with one team, so how it hows, refine and review, then roll it out to another team and so on. If can be a gradual process, nothing like this can ever be implemented and work straight away – it will take some trial and error to get it right for your company.

      If you need more let me know!

      1. Hi!
        Thanks for your answer.
        For the guilds it makes sense what you write.

        But for the chapters it can be more challenging. Example from my work: our sys engineers work in the teams, but still are in chapter sys eng. and it is very important for them to sync more often. and on the other hand they have to attend all dev team meetings…

        Best
        Ingo

Leave a Reply

Your email address will not be published. Required fields are marked *