Modelo Spotify: squads, tribos, capítulos e guildas

O modelo Spotify virou sinônimo de "empresa ágil" no Brasil. Bancos, varejistas e órgãos públicos renomearam gerências como tribos, equipes como squads e coordenações técnicas como capítulos. Em muitos casos, a mudança parou aí: os nomes mudaram, mas as decisões continuaram subindo pela mesma hierarquia, os times continuaram dependentes uns dos outros e o organograma ganhou uma camada nova.

Isso acontece porque pouca gente leu a fonte. O modelo foi descrito num artigo de outubro de 2012, assinado por Henrik Kniberg, consultor da Crisp, e Anders Ivarsson, agile coach da Spotify, sobre como a empresa organizava algumas centenas de pessoas de tecnologia em mais de 30 times, em três cidades. O próprio texto abre com um aviso: os autores não inventaram o modelo, e o artigo é só um retrato do jeito de trabalhar daquele momento, uma jornada em andamento. Quando alguém lesse, as coisas já teriam mudado.

Abaixo está o que o artigo realmente descreve, a lógica por trás de cada peça e o que dá para aproveitar sem transformar a ideia em organograma.

Squads: a unidade básica

O squad é a unidade básica de desenvolvimento. O artigo o descreve como parecido com um time Scrum e pensado para funcionar como uma pequena startup: as pessoas trabalham juntas e têm todas as habilidades e ferramentas para desenhar, desenvolver, testar e colocar em produção.

Características do squad, segundo o texto original:

• Missão de longo prazo. Cada squad cuida de uma parte do produto por muito tempo (o cliente Android, a experiência de rádio, os pagamentos), o que permite se tornar especialista naquele assunto.
• Autonomia de método. Alguns squads usavam Sprints de Scrum, outros Kanban, outros uma mistura.
• Sem líder formal. O squad não tem chefe designado, mas tem um Product Owner, que prioriza o trabalho sem interferir em como ele é feito.
• Apoio de um agile coach. O coach ajuda o squad a melhorar o processo, conduz retrospectivas e faz acompanhamento individual. O papel se parece com o descrito em agile coach: o que faz.
• Tempo para experimentar. O artigo menciona que os squads eram incentivados a dedicar cerca de 10% do tempo a "hack days".

O ideal descrito é um squad totalmente autônomo, em contato direto com suas partes interessadas e sem dependências que bloqueiem o trabalho. O próprio texto reconhece que, com mais de 30 times, isso era um desafio.

Tribos: grupos de squads em áreas relacionadas

A tribo é um conjunto de squads que trabalham em áreas relacionadas, como o player de música ou a infraestrutura de backend. Cada tribo tem um tribe lead, responsável por criar o melhor ambiente possível para os squads.

O tamanho da tribo tem um limite deliberado: menos de 100 pessoas, inspirado no número de Dunbar, a ideia de que a maioria das pessoas não consegue manter relações sociais com muito mais gente do que isso. Acima desse tamanho, segundo os autores, começam a aparecer regras restritivas, burocracia, política e camadas extras de gestão.

As tribos faziam encontros regulares e informais para mostrar o que cada squad estava construindo, com demonstrações de software funcionando.

Capítulos e guildas: o que mantém a empresa unida

Autonomia total tem um custo: perda de economia de escala. O testador de um squad pode estar lutando com um problema que o testador de outro squad resolveu na semana anterior. Capítulos e guildas existem para resolver isso.

Um detalhe importante, e quase sempre esquecido na cópia: o chapter lead também faz parte de um squad e participa do trabalho do dia a dia. Ele não é um gerente funcional distante, e sim alguém que continua com a mão na massa.

A matriz: o "o quê" e o "como"

O artigo reconhece que o resultado é uma estrutura matricial, mas diferente da matriz tradicional. Na matriz comum, pessoas ficam em departamentos funcionais e são "alocadas" a projetos. No modelo descrito, a dimensão principal é a entrega: as pessoas ficam em squads estáveis, multifuncionais e no mesmo local. A dimensão horizontal, dos capítulos, serve para compartilhar conhecimento, ferramentas e código.

Os autores resumem assim: a dimensão vertical é o "o quê" (o que construir em seguida, papel do Product Owner) e a horizontal é o "como" (como construir bem, papel do chapter lead). Eles ligam essa divisão ao modelo do "professor e do empreendedor" proposto por Mary e Tom Poppendieck. O empreendedor quer acelerar e cortar caminhos; o professor quer desacelerar e fazer direito. A tensão entre os dois é saudável e intencional.

Outros papéis aparecem no texto para proteger a arquitetura: o system owner, responsável pela integridade de cada sistema, e um arquiteto-chefe que coordena questões que atravessam vários sistemas, sempre com sugestões, deixando a decisão final com o squad.

Dependências entre squads

O artigo trata dependências como inevitáveis, mas a meta é reduzir as que bloqueiam o trabalho. A Spotify perguntava regularmente aos squads de quem dependiam e quanto essas dependências os atrasavam, e discutia formas de eliminar as mais problemáticas por repriorização, reorganização ou mudança de arquitetura.

Um ponto interessante: o texto conta que a empresa normalmente não fazia Scrum of Scrums, porque a maioria dos squads era bastante independente. A reunião acontecia sob demanda, quando um projeto exigia vários squads coordenados por alguns meses. Se a sua organização precisa de coordenação constante entre times, o problema provavelmente está nas dependências, e práticas como as descritas em Scrum em escala: Scrum of Scrums, Nexus e LeSS passam a ser necessárias.

Por que copiar o modelo Spotify costuma dar errado

O modelo Spotify não é um framework. Não há guia, papéis obrigatórios nem regras, e o texto original diz explicitamente que retrata um momento. Mesmo assim, ele é tratado como receita. Os erros mais comuns:

• Trocar os nomes sem mudar as decisões. A gerência vira tribo, mas o diretor continua decidindo o que cada squad faz na semana.
• Criar squads sem missão. O squad recebe demandas de várias áreas em vez de cuidar de uma parte do produto por muito tempo.
• Capítulo como departamento. O chapter lead vira gerente funcional que aloca pessoas, exatamente a matriz que o modelo queria evitar.
• Ignorar a arquitetura. Squads autônomos só funcionam se o sistema permitir entregar sem depender de outros times. Num sistema monolítico com uma fila única de implantação, a autonomia fica no papel.
• Esquecer a cultura. O artigo descreve uma empresa que já tinha confiança, experimentação e liberdade de método. A estrutura veio depois.

O que aproveitar do modelo

Mesmo sem adotar a estrutura, várias ideias se aplicam a qualquer organização com muitos times:

1. Dê a cada time uma missão estável. Um time que cuida do mesmo produto por anos acumula conhecimento e responsabilidade.
2. Mapeie e ataque dependências. Pergunte a cada time de quem ele depende e quanto isso atrasa. Use a resposta para mudar prioridade, arquitetura ou composição dos times.
3. Separe o "o quê" do "como". Quem prioriza o trabalho não precisa ser quem desenvolve a carreira das pessoas.
4. Crie comunidades de prática. Guildas custam pouco e espalham conhecimento entre times.
5. Limite o tamanho dos grupos. Acima de algumas dezenas de pessoas, coordenação informal deixa de funcionar.

Autonomia não se decreta. Ela se constrói aos poucos, com times que aprendem a decidir e líderes que aprendem a delegar. O artigo sobre times auto-organizados com Kanban mostra como chegar lá por etapas. Se a sua organização precisa de uma estrutura mais definida para muitos times dependentes, compare com o SAFe.

Por onde começar

Antes de redesenhar o organograma, responda a três perguntas: cada time tem uma missão clara e estável? Quantas entregas dependem de outro time? Quem decide o que cada time faz na próxima Sprint? As respostas mostram se o problema é de estrutura ou de autonomia. O guia completo de métodos ágeis e Scrum traz a base de práticas que sustenta qualquer modelo de escala.

Para formar as pessoas que vão trabalhar nesses times, o curso Agile Scrum Foundation da Projeto Diário cobre os fundamentos do ágil e do Scrum que todo squad precisa dominar antes de pensar em tribos e capítulos.