O que é o Modelo Spotify?

Ao criar produtos digitais, todos nós queremos sentir que estamos fazendo isso da maneira certa. E nada é mais satisfatório do que sentirmos que finalmente encontramos a estrutura ou metodologia perfeita que nos ajudará a fazer isso.

Infelizmente, existem tantas para escolher! Portanto, é importante fazer sua pesquisa e descobrir quais valem a pena tentar.

Você deve ter ouvido falar da empresa de bilhões de dólares, Spotify. E você pode até ter ouvido falar de sua estrutura inovadora para organização de equipes e escalonamento de produtos usando a metodologia ágil. Mesmo se você não estiver construindo uma plataforma de streaming de música, o modelo apresenta uma nova maneira de capacitar equipes auto-organizadas e construir um produto amado por milhões de usuários.

O que é o modelo Spotify?

O modelo do Spotify remonta a 2011, quando Henrik Kniberg e Anders Ivarsson, a pedido de seus colegas, publicaram o artigo: Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds.

Kniberg é frequentemente creditado como sendo o “inventor” do modelo, mas ele é a primeira pessoa a dizer que não é o caso! E ele também sempre fez questão de afirmar que nunca foi feito para ser algo que as pessoas copiassem ou implementassem em suas próprias empresas. “É apenas um exemplo de como uma empresa funciona.”

Nunca foi pretendido que fosse publicado como uma estrutura, mas sim como uma visão geral e genérica de como o desenvolvimento de produtos é organizado no Spotify. Inclui a hierarquia da equipe, como as equipes são organizadas e o estilo de cultura empresarial necessária para fazer tudo funcionar.

Como uma metodologia ágil, o modelo Spotify defende as necessidades de colaboração, transparência e simplicidade, o que o torna muito atraente para outras empresas ágeis que procuram fazer a metodologia funcionar para elas.

Estrutura do modelo Spotify
O modelo Spotify tem muitas estruturas e definições, que podem parecer um pouco complicadas à primeira vista:

Crédito da imagem: Scaling @ Spotify

Squads
Uma squad é descrito como a unidade mais básica de desenvolvimento e é provavelmente a mais familiar para PMs que trabalharam em equipes ágeis “típicas”. Cada squad é projetado para funcionar como uma própria mini-startup, com todas as habilidades necessárias para construir um produto (design, teste, engenharia, etc).

As equipes são auto-organizadas e cada equipe pode escolher a estrutura que funciona melhor para elas, que pode ser Scrum, Kanban ou qualquer outra coisa que a equipe goste. Isso permite que os colegas de equipe trabalhem da maneira que melhor lhes convém, o que maximiza sua produtividade e facilita sua vida profissional.

Cada squad tem sua própria missão de longo prazo e possui uma fatia específica do produto total. Embora a liderança não dite como as squads devem trabalhar para atingir esse objetivo, as squads são incentivadas a empregar princípios de produtos enxutos, como testes A / B e lançamento de MVPs. Squads têm Coaches ágeis para ajudá-los a entender como construir da maneira certa e um Product Owner que ajuda seus colegas de equipe a priorizar suas tarefas.

Tribes
As squads são construídas para funcionar por si próprias, mas isso não significa que funcionem isoladas. As squads são organizados em tribos relevantes, dependendo da parte do produto em que estão trabalhando. Embora não haja uma hierarquia oficial, um líder é atribuído a cada tribo, que garante que todos tenham o que precisam para prosperar. As tribos são projetadas para ter menos de 100 pessoas para tornar a organização administrável, e reuniões informais são realizadas regularmente para que todos tenham a oportunidade de estar em dia com o que os outros times estão fazendo.

O cruzamento entre squads é inevitável, o que cria certas dependências. Essas dependências desaceleram as equipes, sendo algo que o modelo visa reduzir ao máximo possível. Isso ajuda a livrar o desenvolvimento de gargalos e a manter as coisas em movimento com velocidade e eficiência.

Chapters
Colaboração é a chave, então talvez pareça um pouco estranho que o Spotify divide sua força de trabalho em equipes autônomas menores que parecem não estar trabalhando juntas. É por isso que o modelo apresenta os chapters.

Membros de equipes diferentes com habilidades semelhantes ou que trabalham em problemas semelhantes formam capítulos de equipes cruzadas. Os capítulos se reunirão regularmente para manter uns aos outros atualizados sobre o que estão trabalhando e para compartilhar soluções para problemas comuns. Esse compartilhamento frequente de conhecimento garante que haja uma comunicação útil entre os times e também ajuda os membros desses times a inovar juntos.

Guilds

As guildas são um pouco mais confusas, como você pode ver à cima. Onde os chapters são baseados no papel oficial de um indivíduo dentro da sua squad, as guildas são áreas de interesse mais gerais. Por exemplo, teste. Todos os envolvidos diretamente no teste irão ingressar na guilda, mas mesmo aqueles que não precisam se aprofundar no assunto para realizar seu trabalho diário, mas estão simplesmente interessados ​​no assunto, também podem ingressar para aprender.

Benefícios e desafios

Desafio: Risco para a arquitetura do sistema
Spotify tem 100 sistemas distintos que formam o produto geral. Quando as squads atualizam um, geralmente precisam atualizar vários para implementar as mudanças nas quais estão trabalhando. O risco aqui é que a arquitetura pode dar errado se todos estiverem se concentrando apenas em um pequeno pedaço dela por vez. Ter um proprietário do sistema, alguém (ou um pequeno grupo de pessoas) que possui a integridade da arquitetura, atenua esse risco.

Benefício: Autonomia
Os resultados de muitas empresas falam por si; o trabalho autônomo é o futuro do desenvolvimento ágil de produtos bem-sucedido. O principal benefício do modelo Spotify é que as equipes têm autonomia para tomar suas próprias decisões e trabalhar da maneira que melhor lhes convier. Isso incentiva a transparência, a confiança, a colaboração e a experimentação, levando a produtos melhores.

Benefício: Menos gargalos e burocracia
Quando as equipes se dirigem e tomam suas próprias decisões, são capazes de trabalhar mais rápido e evitar gargalos, que resultam em perda de tempo. O modelo incentiva a colaboração informal e o compartilhamento de informações, sem muita cerimônia ou processo formal.

Desafio: Não vai funcionar para todas as empresas
O modelo parece fantástico por fora, mas escolher implementá-lo simplesmente porque funcionou para o Spotify é um erro. É importante analisar se o modelo se encaixa na cultura da empresa, que é muito mais difícil de mudar do que a framework que você está seguindo. Reorganizar a estrutura da sua empresa é um grande risco e um grande investimento e, como o modelo do Spotify não foi projetado para ser copiado por outras empresas, pode não ser adequado para o seu.

Devemos implementar o modelo Spotify?

Provavelmente é o que você deve estar se perguntando.

Se funcionou para o Spotify, pode funcionar para nós?

Ao escolher qualquer nova estrutura, a pesquisa é fundamental. A primeira coisa a descobrir são os problemas que você enfrenta atualmente como organização. Você tem problemas com a comunicação entre as equipes ou tem uma liderança determinada a seguir o método lento da cascata? Talvez você esteja sofrendo de gargalos. Ou talvez você não tenha certeza do que está errado e está procurando copiar uma empresa de sucesso como uma solução fácil?

Você nunca resolverá seus problemas se não chegar à raiz deles. Reúna o feedback de cada membro da equipe sobre os problemas que enfrentam causados ​​pela cultura / estrutura da empresa e trabalhe para fazer uma lista dos problemas mais comuns. Em seguida, compare-as com as soluções apresentadas pelo modelo Spotify.

O modelo Spotify não é um caso de tudo ou nada. Você não precisa desmontar seu organograma e reconstruí-lo conforme o modelo. Um passo muito mais razoável seria começar a implementar alguns dos princípios ágeis que podem fazer mais sentido para suas equipes.