Você provavelmente tem o aplicativo do Spotify baixado no seu celular e o acessa regularmente para ouvir músicas, podcasts… A empresa de streaming revolucionou o modo de ouvir música, a remuneração de artistas e há algum tempo vem influenciando também a forma de as empresas organizarem suas equipes, especialmente as de tecnologia ou de consultoria que trabalham com times alocados por projeto. Isso porque o modelo de organização desenvolvido por eles, conhecido também como “Spotify Squads”, deu tão certo que vem sendo copiado por muita gente.
A estrutura em Squads dá muita velocidade, pois evita esquemas de aprovação, afunilamento de decisões no topo e dependência de outras equipes. Mais do que organogramas e estruturas hierárquicas, o foco principal do Spotify é a comunidade. Henrik Kniberg, que já trabalhou lá como coach de métodos ágeis, publicou um vídeo em 2014 que detalha como funciona essa Cultura Ágil de Engenharia de Software.
O Spotify começou como uma empresa pequena, de tecnologia, que adotava os conceitos mais básicos do Scrum e se organizava em times pequenos e multidisciplinares. Mas com o aumento considerável no número de colaboradores, os conceitos do Scrum foram ficando pelo caminho e eles decidiram que aquilo poderia ser opcional.
Foi aí que eles perceberam que os princípios do Manifesto Ágil são mais importantes do que um método específico. O antigo papel de “Scrum Master” passou a ser o do “Agile Coach”. E qual a diferença? Esse líder agora está menos preocupado em seguir passo a passo a metodologia e mais voltado a estimular e dar suporte ao time para uma melhoria contínua. São “líderes servidores” mais do que “mestres de processo”.
Afinal, o que são Squads?
As equipes multidisciplinares passaram a se organizar em Squads, times pequenos auto-organizados, em geral com menos de 8 pessoas de diferentes funções e que possuem responsabilidades de ponta a ponta.
No exemplo acima, este Squad é composto por um Product Owner ou Product Manager (que vai gerir o desenvolvimento do produto de todas as suas perspectivas), por um engenheiro/desenvolvedor de back-end (que liga determinada funcionalidade aos algoritmos da empresa); por um engenheiro de front-end (que programa a interface visual), por um tester (profissional responsável por encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante a confecção de um software) e por um designer (que desenha a UX e a UI dessa funcionalidade).
Cada Squad é geralmente focado em um segmento do produto, como design, desenvolvimento ou manutenção. Além dos objetivos de curto-prazo, cada Squad tem uma missão de longo prazo, como “fazer do Spotify o melhor lugar para se descobrir música”.
Os Squads funcionam com um nível muito alto de autonomia. Como Kniberg diz no vídeo, essa autonomia é muito importante porque motiva as pessoas. “E pessoas motivadas criam coisas melhores, mais rapidamente”, ressalta ele. Sem falar que a autonomia proporciona aos funcionários um senso de propriedade coletiva. Eles são parte de um todo maior, membros ativos (em vez de passivos) da equipe, “fazendo uma contribuição geral positiva para a organização”. É claro que essa liberdade não é infinita. A missão do Squad e objetivos de curto-prazo costumam ser negociados a cada trimestre.
Além de autonomia, uma outra palavra começada com A é muito importante para o modelo Spotify: alinhamento. Todos os Squads precisam estar alinhadas com a estratégia da empresa, que é mais importante do que a missão individual de qualquer time. Fazendo uma correlação, os Squads são como músicos de uma banda de jazz. Cada um toca individualmente, mas a música boa que ouvimos é a junção de todos os sons.
Quando o vídeo foi lançado, segundo Henrik, o Spotify tinha mais de 50 Squads, distribuídos em quatro países. Gerenciar esses times, e fazer com que eles atuem de forma independente, mas em prol do todo, não é uma tarefa fácil. Era necessário ter algum tipo de estrutura além dos Squads. Foi então que surgiram as Tribes, ou tribos, em bom português. A Tribe pode conter uma série de squads que tenham funcionalidades e objetivos similares.
Uma outra estrutura que surgiu foram os Chapters, grupos horizontais que reúnem profissionais das mesmas áreas de competência, como, por exemplo, desenvolvedores, designers de UI ou Agile coaching. Cada Chapter tem um líder-servidor que guia o aprendizado e o desenvolvimento funcional dos membros.
Assim, se você é por exemplo um engenheiro, você pode trocar de Squad que seu gestor imediato continuará sendo a mesma pessoa.
Há ainda a Guild, que é uma comunidade de interesse que usa uma lista de discussão ou outro tipo de comunicação informal dentro do Spotify. As Guilds têm caráter voluntário e são formadas conforme interesse das pessoas nos temas que as originam, podendo, portanto, perpassar por diversas Tribes. Qualquer um pode entrar ou sair de uma Guild a qualquer momento.
Resumindo:
Tribe: Matriz leve, com cada pessoa sendo membro também de um Squad e um Chapter
Squad: uma dimensão primária focada na entrega e qualidade do produto.
Chapter: Grupo formado com base em áreas de competência.
Guild: Uma comunidade de interesse leve na qual pessoas de toda a empresa se reúnem e compartilham conhecimento de uma área específica.
A foto é bonita, mas como Kniberg explica no vídeo, a realidade não é tão linear assim.
De qualquer forma, em vez de criar regras e processos complicados para gerenciar seus lançamentos, a ideia do Spotify foi simplificar o processo organizacional para incentivar as entregas menores, mas mais frequente. Para eles, entregas devem ser rotinas, não dramas.
Até porque, para o Spotify, errar não é problema. Ao longo do ciclo de desenvolvimento de um produto, a empresa reconhece que vai cometer erros e que isso é inevitável. Então, por que não falhar mais rápido? O Spotify está mais interessado em consertar rapidamente as falhas do que na prevenção delas. Eles levam isso tão a sério que alguns Squads têm uma “Fail Wall” (parede do erro) para que todos vejam os equívocos e possam aprender com eles.
Sem falar que, antes de decidir construir um novo produto ou recurso, eles tentam se informar com pesquisas se as pessoas realmente querem esse produto, e se isso resolve um problema real para elas. Em seguida, eles encontram uma narrativa, fazem um release para a imprensa mostrando todos os benefícios e, mais tarde, constroem um protótipo. Uma vez que sintam que vale a pena, eles vão em frente e constroem um MVP (produto mínimo viável) para um percentual de usuários finais, usando técnicas como teste A/B para medir o impacto.
Falamos um pouco aqui da organização dos Squads e da mentalidade por trás do desenvolvimento de produtos do Spotify. Exemplos de como esse processo acontece na prática vocês podem e devem conferir no vídeo. De qualquer forma, vale lembrar: o modelo “Spotify Squads” não é uma tecnologia social, ou seja, não foi desenvolvido e testado por especialistas em design organizacional. Era apenas como Spotify funcionava na época em que o vídeo foi lançado. A realidade é muito mais complexa. Até porque o Spotify tem pouca padronização.
Nem tudo são flores. Para alguns especialistas, essa auto-organização desses times cria alguns desafios de gestão devido à falta de organização, de um líder claro que dê feedback e ajude na gestão de carreiras. Os times altamente colaborativos também, por vezes, dificultam a avaliação da performance individual. Outro ponto importante: o Spotify Squads pode não fazer sentido se aplicado em outras áreas/organizações que não trabalham com desenvolvimento de software. É difícil aplicar essa metodologia a uma área de RH, por exemplo.
Aqui na Homem Máquina nós não nos organizamos por Squads. É natural que cada empresa tenha seu próprio cenário e suas próprias necessidades. Algumas não precisam de processos tão complexos, outras aplicam estruturas organizacionais extensas para conseguir atingir seus objetivos. Se você está buscando aumentar o nível de maturidade e cultura de design no seu time, você pode baixar nosso e-book Guia da Cultura de Design ou conheça nossos serviços de “Squads as a service” com profissionais tanto de design quando de desenvolvimento de software.
