28 Jan 2022 | 3 minutos • Agilidade
Modelo Spotify
Exemplo de organização de times ágeis

Ingrid Machado
Engenheira de computação, especialista em engenharia de software. Autora deste querido blog.

Existem vários artigos sobre o modelo Spotify. Inclusive, existem diversos artigos falando que o modelo Spotify não é mais usado pelo próprio Spotify. Mesmo assim, acredito que é importante saber do que esse modelo trata, já que muitas empresas pegaram emprestado vários termos da definição original para organizar os seus times.
O que é o modelo Spotify
O modelo ilustra como o Spotify se organiza em termos de times ágeis para a construção do produto. Dentro dessa organização existem Tribos, Squads, Capítulos e Guildas.
Por mais estranho que pareça, muitos termos em inglês são misturados com o português no dia a dia de trabalho. Por isso, não traduzi a palavra “squad” e vou seguir com esse padrão dentro do post. Outra forma que costumo ver sendo falada é usar “chapter”ao invés de “capítulo”.
A intenção inicial do modelo era escalar o ágil dentro do Spotify e ter uma gestão de múltiplos times que funcionassem trabalhando em conjunto.
O artigo que descreve o modelo por completo deixa claro que é apenas uma fotografia do estado atual dos times, já que estão sempre evoluindo o formato de trabalho. Porém, é inegável a influência que esse modelo divulgado teve em diversas empresas pelo mundo todo.
Quais são os componentes do modelo Spotify
Squads
Squads são a menor unidade de desenvolvimento. A composição de uma Squad é muito parecida com a de um time Scrum: possuem todas as habilidades necessárias para gerar valor e são autogerenciadas.
Por mais parecido que sejam com um time Scrum, cada Squad decide se usa Scrum, Kanban ou Scrumban. A decisão de qual framework atende melhor ao trabalho parte do próprio time.
Cada Squad é responsável por um desenvolvimento e a divisão varia de empresa para empresa. Caso a empresa tenha mais de um produto, é possível que cada Squad assuma o desenvolvimento de cada produto. Se for uma empresa com um produto único, cada Squad pode assumir uma parte do produto (seja um módulo ou uma jornada do cliente) para evoluir. Assim como também é possível existir uma mistura dos dois formatos, onde dentro da mesma empresa existem Squads que assumem um produto e outras que assumem partes de outros produtos.
Tribos
As Tribos agrupam Squads que trabalham em áreas relacionadas.
Considerando os exemplos que dei anteriormente, imagine que um produto possui 3 Squads que estão responsáveis por desenvolver partes diferentes desse mesmo produto. Uma organização que faz sentido é incluir as 3 Squads na mesma Tribo.
Se pensarmos em jornadas de cliente, uma Tribo poderia conter Squads que trabalham em diferentes produtos, mas que todos fazem parte da mesma jornada.
As Tribos possuem um Tribe Leader, responsável por viabilizar o trabalho das Squads da melhor forma possível.
Capítulos
Com um modelo formado por diversas Squads, é normal que apareçam desafios parecidos. E, para evitar que sejam desperdiçados recursos na solução de problemas iguais por times diferentes, existe o conceito de Capítulo.
O Capítulo é formado por pessoas que possuem o mesmo papel dentro das Squads de uma Tribo. Ou seja, dentro de uma Tribo todos os testadores das Squads formam um capítulo de testes. Onde é possível compartilhar desafios, soluções encontradas e ferramentas desenvolvidas para facilitar o trabalho entre todos.
A ideia é que o Capítulo tenha encontros regulares para fazer essas trocas e evoluir todas as Squads.
Guildas
De forma parecida com os Capítulos, as Guildas também reunem pessoas de diferentes Squads. Porém, elas se expandem entre as Tribos e são relacionadas a assuntos de interesse geral. Uma Guilda sobre agilidade pode envolver POs, testadores, desenvolvedores e quem mais tiver interesse pelo assunto.
As Guildas servem para compartilhar conhecimento, ferramentas e práticas entre todos os interessados.
Por mais que esse modelo sirva de inspiração e seja modificado de acordo com a situação da empresa, é muito comum ver times de produto organizados de uma forma muito parecida.
Saber a definição de origem de cada um desses termos ajuda a não se perder nesse mar de nomes que não costumamos usar no dia a dia e deixa de ser mais um ponto a se aprender quando iniciamos em times ágeis.
Espero que tenha te ajudado a entender melhor esse tipo de organização de times.
Até a próxima!
O link do post foi copiado com sucesso!Mais conteúdos de Ingrid Machado

15 Mai 2023 • Agilidade
Métricas de fluxo
Atualmente, trabalho em um time em que migramos do Scrum para o Kanban. Seguimos trabalhando com o Jira, mas agora usamos um novo quadro. E, com essa mudança, passamos a usar uma ferramenta para a ...
11 minutos

25 Fev 2022 • Agilidade
Iniciando com um novo time
Quem acompanha o que eu escrevo já deve ter percebido o quanto eu gosto de listas e roteiros para encarar diversas situações. Eu até recebi um feedback sobre como eu me saio bem quando eu tenho um ...
6 minutos

18 Fev 2022 • Agilidade
Retrospectiva
Trabalhar por um período indefinido no mesmo time exige que se mantenha a melhoria contínua como prática. De outra forma, a manutenção do trabalho de qualidade é inviável. Pensando nisso, a agilida...
6 minutos