O modelo de equipe Squad do Spotify foi um fracasso
(jeremiahlee.com)<p>"Nem o próprio Spotify usa 'the Spotify model'. Você também não deveria usar."<br />
O famoso white paper de 2012 do Spotify sobre "Scaling Agile" era apenas a aspiração deles e nunca foi totalmente implementado.<br />
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.<br />
Um texto detalhando o que havia de errado nesse modelo, o que aprender com os erros do Spotify e outros modelos recomendados<br />
<br />
O coautor desse white paper e os coaches Agile do Spotify já diziam há tempos para pessoas de fora não seguirem isso.<br />
"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."<br />
<br />
Por que isso não funcionou bem?<br />
<br />
1. A gestão matricial resolvia o problema errado (Wrong Problem)<br />
<br />
Equipes ágeis full-stack funcionam bem. Mas a gestão em formato matricial cria ainda mais problemas<br />
→ 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<br />
→ 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<br />
→ 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.<br />
<br />
[ O que aprender com os erros do Spotify ]<br />
→ 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<br />
→ Product managers devem ter um par equivalente para discutir tecnologia, como CEO e CTO. <br />
<br />
2. Dependência da autonomia das equipes<br />
<br />
Quando a empresa é pequena, cada equipe cobre um escopo amplo de trabalho e frequentemente a equipe que lidera uma iniciativa muda. <br />
Quando a empresa cresce, capacidades duplicadas entre equipes são reunidas em novas equipes para ganho de eficiência. <br />
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.<br />
<br />
→ 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.<br />
→ 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.<br />
<br />
[ O que aprender com os erros do Spotify ]<br />
→ 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.<br />
→ Um processo de colaboração entre equipes é indispensável. Autonomia não significa deixar cada equipe resolver todos os problemas sozinha.<br />
→ 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. <br />
→ 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.<br />
<br />
"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<br />
<br />
3. Colaboração era apenas uma capacidade presumida<br />
<br />
O Spotify permitiu que cada equipe controlasse sua forma de trabalhar, mas muitas pessoas não tinham entendimento básico de Agile. <br />
Com isso, cada equipe precisou fazer tentativas e combinações repetidas de melhoria de processo para encontrar uma forma de melhorar seus resultados. <br />
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".<br />
<br />
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. <br />
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.<br />
<br />
[ O que aprender com os erros do Spotify ]<br />
→ 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.<br />
→ 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. <br />
<br />
4. Mitos são difíceis de mudar<br />
<br />
O Agile Scrum apresentou palavras como burndown e sprint porque, ao introduzir novos conceitos, precisava dar nomes a eles. <br />
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. <br />
<br />
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. <br />
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.<br />
<br />
[ O que aprender com os erros do Spotify ]<br />
→ 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.<br />
→ 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.</p><p>*** Em vez disso, faça assim. ( Claro, não existe caminho rápido. )<br />
<br />
Se você chegou ao modelo do Spotify, provavelmente foi para estruturar suas equipes. Não pare aí: pesquise mais.<br />
Empresas que resistiram ao teste do tempo por mais tempo do que o Spotify deixaram muito mais material escrito.<br />
<br />
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.<br />
Eles olharam para fora para superar esse modelo inicial e encontrar respostas melhores, e você também deveria fazer isso. <br />
<br />
Recomendações do autor sobre outras formas de trabalhar<br />
<br />
- Sua organização de produto-desenvolvimento-design tem mais de 200 pessoas? Quando eu estava na Fitbit, o "Scaled Agile Framework" funcionou bem.<br />
- Com menos de 200 pessoas, recomendo "Shape Up By Basecamp". Minha próxima startup será estruturada dessa forma.<br />
- Leia os livros "Essential Scrum" e "Team Topologies".</p>
4 comentários