O modelo de equipe Squad do Spotify foi um fracasso
(jeremiahlee.com)"Nem o próprio Spotify usa 'the Spotify model'. Você também não deveria usar."
O famoso white paper de 2012 do Spotify sobre "Scaling Agile" era apenas a aspiração deles e nunca foi totalmente implementado.
O white paper era diferente da realidade, mas como era útil para recrutamento, foi mantido, e o autor registrou isso após sair da empresa para corrigir a história.
Um texto detalhando o que havia de errado nesse modelo, o que aprender com os erros do Spotify e outros modelos recomendados
O coautor desse white paper e os coaches Agile do Spotify já diziam há tempos para pessoas de fora não seguirem isso.
"Mesmo na época em que escrevemos o white paper, já não fazíamos aquilo. Era apenas uma ambição parcial e uma estimativa. As pessoas se esforçaram para imitar algo que na prática nem existia."
Por que isso não funcionou bem?
- A gestão matricial resolvia o problema errado (Wrong Problem)
Equipes ágeis full-stack funcionam bem. Mas a gestão em formato matricial cria ainda mais problemas
→ As equipes do Spotify tinham uma estrutura duradoura, então a vantagem de não precisar trocar de gerente ao mudar para outra equipe era muito limitada
→ Os gerentes de engenharia eram responsáveis apenas pelo nível de desenvolvimento de carreira e não conseguiam ajudar no aprendizado de habilidades interpessoais e semelhantes
→ Não havia um único gerente responsável pelos engenheiros de cada equipe. Faltava para o product manager, que atuava como um mini-CEO, alguém que fizesse um papel de mini-CTO. Ou seja, não havia quem fosse responsável pelo suporte à equipe técnica nem quem negociasse prioridades. Quando surgiam divergências dentro da equipe técnica, o product manager precisava negociar com todos os engenheiros. Se isso não funcionasse, era preciso negociar com pelo menos três engineering managers de backend/web/mobile ou escalar para o responsável de engenharia do departamento.
[ O que aprender com os erros do Spotify ]
→ Em equipes de produto-design-tecnologia, normalmente há mais engenheiros, então deve existir um gerente responsável pelo conjunto dos engenheiros para criar um caminho de escalonamento em caso de conflito interno na equipe
→ Product managers devem ter um par equivalente para discutir tecnologia, como CEO e CTO.
- Dependência da autonomia das equipes
Quando a empresa é pequena, cada equipe cobre um escopo amplo de trabalho e frequentemente a equipe que lidera uma iniciativa muda.
Quando a empresa cresce, capacidades duplicadas entre equipes são reunidas em novas equipes para ganho de eficiência.
Quando há muitas equipes, a liderança de iniciativas muda com menos frequência e passa a ser possível pensar no longo prazo sobre os problemas que cada uma precisa resolver.
→ O Spotify não definiu um processo comum para colaboração entre equipes. Como cada uma participava do seu próprio jeito, a produtividade da organização como um todo caiu.
→ O "Spotify model" foi organizado quando a empresa era muito menor. Deveria ter surgido uma atualização posterior, mas isso não aconteceu. Falou-se apenas de autonomia, e a parte sobre colaboração entre equipes nunca foi concluída.
[ O que aprender com os erros do Spotify ]
→ Autonomia precisa de alinhamento. As prioridades da empresa devem ser definidas pela liderança. Autonomia não significa que as equipes podem fazer o que quiserem.
→ Um processo de colaboração entre equipes é indispensável. Autonomia não significa deixar cada equipe resolver todos os problemas sozinha.
→ A liderança também deve definir como o sucesso será avaliado, para que seja possível coordenar prioridades ao decidir sobre colaboração entre equipes.
→ Autonomia exige responsabilidade. Product Management deve ser responsável pelo valor do produto. Cada equipe tem a responsabilidade de realmente "concluir" o que foi acrescentado. Equipes maduras devem justificar sua independência mostrando valor de negócio, risco, aprendizado e o melhor próximo passo.
"Se eu pudesse corrigir uma única coisa sobre o tempo em que estive no Spotify, seria não ter enfatizado tanto a autonomia." - Joakim Sunden, ex-Agile Coach do Spotify
- Colaboração era apenas uma capacidade presumida
O Spotify permitiu que cada equipe controlasse sua forma de trabalhar, mas muitas pessoas não tinham entendimento básico de Agile.
Com isso, cada equipe precisou fazer tentativas e combinações repetidas de melhoria de processo para encontrar uma forma de melhorar seus resultados.
Não havia uma linguagem comum para avaliar com eficiência os problemas do processo, soluções ou critérios de sucesso. Na prática, isso nem era Agile; era apenas "Not-Waterfall".
O Spotify tinha "Agile coaches" para ensinar e sugerir melhorias de processo a cada equipe. A intenção era boa, mas não havia coaches suficientes para ajudar todas as equipes.
O tempo que cada coach podia dedicar a uma equipe era insuficiente para ajudar até a conclusão dos projetos e a avaliação dos resultados. Por isso, eles não eram responsáveis por nada.
[ O que aprender com os erros do Spotify ]
→ Colaboração é uma habilidade que exige conhecimento e prática. Gestores não devem presumir que as pessoas já entendem as práticas ágeis existentes.
→ Quando a empresa cresce o suficiente, cada equipe precisa de uma organização de suporte para planejar internamente e viabilizar a colaboração entre equipes. Program Management deve ser responsável pelo processo de planejamento. Program Managers dedicados devem fazer a equipe funcionar de modo que Product Manager e Engineering Manager exerçam suas competências e colaborem entre si.
- Mitos são difíceis de mudar
O Agile Scrum apresentou palavras como burndown e sprint porque, ao introduzir novos conceitos, precisava dar nomes a eles.
O Spotify introduziu novos termos como Missions, Tribe, Squads e Chapter Lead, o que criou a ilusão de que haviam construído algo que só poderia existir com uma escolha de palavras especial.
Se removermos esses sinônimos desnecessários, o modelo do Spotify é apenas uma coleção de "Cross-Functional Team" com autonomia excessiva e uma estrutura de gestão fraca.
Se o Spotify tivesse chamado as ideias desse modelo pelos nomes originais, talvez, quando o modelo fracassou, isso tivesse sido avaliado não como uma mudança de identidade cultural, mas como a busca por processos internos que funcionassem melhor.
[ O que aprender com os erros do Spotify ]
→ A maioria dos negócios só consegue sustentar algumas poucas áreas de inovação. Raramente a inovação em processos internos diferencia uma empresa no mercado. Estudar o passado pode ajudar a empresa a encontrar áreas melhores para inovar.
→ Otimize a compreensão. Para manter a produtividade organizacional, é preciso avaliar o valor de tudo o que os membros da organização precisam aprender de novo.
*** Em vez disso, faça assim. ( Claro, não existe caminho rápido. )
Se você chegou ao modelo do Spotify, provavelmente foi para estruturar suas equipes. Não pare aí: pesquise mais.
Empresas que resistiram ao teste do tempo por mais tempo do que o Spotify deixaram muito mais material escrito.
O Spotify de 2012 não encontrou uma forma de manter a velocidade e a agilidade de equipes pequenas dentro de uma organização de grande escala.
Eles olharam para fora para superar esse modelo inicial e encontrar respostas melhores, e você também deveria fazer isso.
Recomendações do autor sobre outras formas de trabalhar
-
Sua organização de produto-desenvolvimento-design tem mais de 200 pessoas? Quando eu estava na Fitbit, o "Scaled Agile Framework" funcionou bem.
-
Com menos de 200 pessoas, recomendo "Shape Up By Basecamp". Minha próxima startup será estruturada dessa forma.
-
Leia os livros "Essential Scrum" e "Team Topologies".
4 comentários
Obrigado pelo ótimo texto.
Na empresa em que estou agora, adotamos o modelo de equipe em squads do Spotify há cerca de 2 anos, mas por causa das desvantagens mencionadas no texto, muitas partes acabaram sendo melhoradas à força.
Desde o início deste ano, estamos seguindo o Shape Up, da Basecamp, e como resultado conseguimos oferecer uma qualidade de produto melhor.
Pois é. Casos de fracasso são tão importantes quanto casos de sucesso.
Quando este white paper de "Scaling Agile" foi publicado pela primeira vez, eu fiquei surpreso, compartilhei e até escrevi sobre ele no blog... é um texto impactante ;_;
Uma das recomendações do autor, "Shape Up, da Basecamp", já foi apresentada no GeekNews. Em organizações pequenas, eu também recomendo isso.
Shape Up - como pequenas organizações trabalham de forma excelente [PDF] https://pt.news.hada.io/topic?id=427
Reações de funcionários do Spotify a este texto
Fiquei lá 6 anos e isso está 100% correto. https://twitter.com/solomonjames/status/1258930064441425920
Saí em 2019, e um dos grandes motivos para eu ter saído foram os problemas descritos neste texto. https://twitter.com/ayyyylo/status/1253658456621539328
Reações de outras pessoas que copiaram e fracassaram
A Zalando copiou em 2016, mas logo percebeu que isso não funcionava bem. https://twitter.com/chilicoder/status/1253429837185691656
A Typeform também tentou seguir esse modelo e fracassou. https://twitter.com/jharmn/status/1252229296522842121
Tentamos copiar assim que o Spotify publicou no blog, e foi um desastre. https://twitter.com/braedon/status/1256122236424957953