- Quais são os problemas auto-confessados do Spotify com este modelo?
- Issue 1: A cultura de engenharia não é uma estrutura organizacional
- Issue 2: O modelo era uma ambição e não foi totalmente adotado
- Issue 3: O modelo optimizado para uma autonomia completa da equipa
- Issue 4: A colaboração entre equipes era uma competência assumida
- O poder do modelo Spotify está nos seus princípios de engenharia e não no seu design organizacional
- Iterar usando inspeccionar e adaptar para criar o seu próprio modelo alvo
- Seja inspirado mas não copie cegamente
- Spotify não é um nirvana ágil
- A versão rápida de como escalar agile
Quais são os problemas auto-confessados do Spotify com este modelo?
Este modelo não é de forma alguma uma panaceia. Houve muitos insights daqueles que trabalharam em Spotify explicando as deficiências do seu modelo e, ao que parece, a realidade não acompanhou o ritmo do mito ágil do nirvana.
“Preocupa-me quando as pessoas olham para o que fazemos e pensam que é uma estrutura que podem simplesmente copiar e implementar. … Estamos realmente a esforçar-nos muito agora para enfatizar que também temos problemas. Não é tudo ‘brilhante e tudo funciona bem e todos os nossos esquadrões são super incríveis'”
Anders Ivarsson, co-autor do livro branco Spotify
Issue 1: A cultura de engenharia não é uma estrutura organizacional
O conteúdo original que Spotify lançou explicando o seu método chamava-se Spotify Engineering Culture. Embora tenham delineado uma estrutura organizacional, tratava-se principalmente da sua cultura de engenharia e dos seus princípios fundamentais de trabalho (ver abaixo uma lista destes).
Issue 2: O modelo era uma ambição e não foi totalmente adotado
Quando Spotify lançou seu livro branco, era parte ambição e parte realidade. Estavam a estabelecer uma visão para o futuro.
“Mesmo na altura em que o escrevemos, não o estávamos a fazer. Era parte ambição, parte aproximação. As pessoas têm realmente lutado para copiar algo que realmente não existia.”
Joakim Sundén, treinador ágil da Spotify 2011-2017
Issue 3: O modelo optimizado para uma autonomia completa da equipa
Como o tamanho das equipas cresceu, a Spotify não definiu um processo comum para a colaboração entre equipas. Quando cada equipe tinha uma forma única de trabalhar, e não havia diretrizes sobre escolhas, a produtividade geral da organização sofria.
Issue 4: A colaboração entre equipes era uma competência assumida
Como o número de equipes cresceu, reconheceu-se que era necessário um apoio dedicado para orientar e estruturar a colaboração entre as equipes. Estruturas ou processos dedicados são necessários para permitir às equipas que não estão necessariamente ligadas a colaborar em conjunto.
“Em artigos ou palestras como esta, pode dar-se conta que Spotify é uma espécie de nirvana ágil onde tudo simplesmente funciona e isso simplesmente não é verdade.”
Henrik Kniberg, Criador do Modelo Spotify
Lembrem-se que o modelo Spotify foi criado há mais de 10 anos, por isso é muito improvável que, à luz dos problemas identificados acima, e talvez de outros, este seja o modelo exato que eles estão usando agora. Spotify é uma empresa que está em constante aprendizagem e crescimento, por isso eles terão evoluído este modelo muitas vezes desde o livro branco original. No entanto, ainda há muito que podemos aprender, mesmo que não se deva aplicar o modelo directamente.
O poder do modelo Spotify está nos seus princípios de engenharia e não no seu design organizacional
A verdadeira magia do modelo Spotify estava na cultura de engenharia e desenvolvimento de produto que eles criaram para equipas ágeis rápidas, motivadas e desacopladas. Ao longo do tempo, eles desenvolveram alguns poderosos princípios centrais de trabalho que sustentaram seu alto desempenho:
- A produtividade está intimamente ligada à motivação – A motivação tem um impacto maior na produtividade do que qualquer outro fator (ver Richard Sheridan’s Joy Inc). Spotify usa a fórmula Produtividade = Esforço x Competência x Ambiente x Motivação.
- Alinhamento e autonomia – Spotify esforça-se por atingir um equilíbrio entre alinhamento (direcção central) e autonomia (auto-organização da equipa). Os gestores pintam o quadro geral mas não dizem às pessoas como chegar lá ou como resolver os problemas.
- Libertações desacopladas para reduzir o tempo de ciclo – Spotify muda a sua arquitectura para desacoplar dependências e tornar as libertações mais fáceis e rápidas. Isto permitiu lançamentos de produção mais frequentes que podem ser independentes entre equipes.
- Confie em seu pessoal – Spotify confia e apóia seu pessoal sem tentar controlá-los porque acreditam que a maioria das pessoas está fazendo o que é melhor para a organização.
- Gestores como líderes servidores – É melhor para os gestores perguntarem às equipas como podem ajudar, em vez de perguntarem às pessoas no que estão a trabalhar ou quando serão feitos.
/li> - Maximizar o valor sobre o negócio – As equipas geram ideias, fazem experiências rápidas e depois medem os resultados. A partir disto, eles ajustam a sua abordagem para maximizar o valor. Importante, eles otimizam para maximizar o valor e não apenas o resultado.
- Cultura de melhoria – As equipes são encorajadas a melhorar a forma como trabalham, e têm um modelo para o que tornaria suas vidas mais fáceis e melhores. Há recursos dedicados disponíveis para ajudar a melhorar as formas de trabalho em toda a organização.
- Cultura saudável cura processos quebrados – Processos podem muitas vezes quebrar, mas uma cultura saudável levará as pessoas a resolverem esses problemas por si mesmas.
- Definição de espectacular – Spotify encoraja as equipas a falar sobre e decidir o que as tornaria espectaculares. Afinal de contas, sem uma visão para o “awesomeness”, é pouco provável que você chegue lá. As equipas de Spotify utilizam regularmente ‘checagens de saúde da equipa’ e rastreiam as melhorias ao longo do tempo. P: As suas equipas têm uma definição de “espectacular”? Você rastreia a saúde da equipe e se esforça para melhorar continuamente?
/li> - A satisfação dos funcionários é da maior importância – o chefe de pessoal de Spotify alegou que 91% dos funcionários gostavam de trabalhar em Spotify, o que ele disse ser “claro que não é satisfatório”… tal é a fasquia alta que eles estabelecem para si mesmos.
- Os erros são OK – o chefe de pessoal de Spotify explica que são esperados erros quando você está pressionando pela inovação. Para mitigar isso, Spotify tem muitos sistemas incorporados para limitar os efeitos das falhas.
“O nosso objectivo é cometer erros mais rapidamente do que qualquer outro”.
Daniel Ek, Fundador de Spotify
Como pode ver, existem alguns grandes conceitos incorporados no modelo, mas não é um plano para um design organizacional ágil por si só.
Iterar usando inspeccionar e adaptar para criar o seu próprio modelo alvo
O contexto da sua organização, de onde você está a partir, a sua cultura, objectivos e muitos outros factores irão determinar a melhor solução para si.
Obviamente, pode pesquisar e pedir ideias emprestadas a empresas como a Spotify, Menlo Innovations, Google, ou outras empresas de elevado desempenho, mas isso deve ser apenas o ponto de partida.
Você tem de saber com clareza qual o problema que está a tentar resolver e depois criar um plano baseado na resolução do seu conjunto único de desafios.
Inspeccionar e adaptar-se é um conceito central de ágil.
Inspect é usar uma mente aberta e um feedback transparente (na maioria das vezes realizado numa retrospectiva) para olhar honestamente para o que está a funcionar e o que não está. Isto pode ser qualquer coisa desde processos, dinâmica de equipe, estratégia ou ineficiências, qualquer coisa que impeça o desempenho da equipe e reduza sua motivação e propriedade.
Adaptar é o processo de pegar os temas da introspecção e encontrar formas de respondê-los e melhorá-los. A adaptação requer criatividade e esforço e muitas vezes assume a forma de uma experiência. Um pequeno teste é realizado com um subconjunto das equipas para assegurar que a solução é viável, antes de ser implementada em toda a organização.
Este processo é então repetido cada vez que a sua organização é melhorada e se aproxima do seu estado de ser ideal.
Seja inspirado mas não copie cegamente
Há muito a gostar no modelo Spotify, se você adotar seus princípios de engenharia e modelar o espírito do que eles estão tentando fazer.
Contextos é tudo, então, a menos que você seja uma empresa sueca de transmissão de música, então é improvável que a cópia cega do Spotify resolva seus problemas.
No entanto, é muito improvável que a cópia cega do modelo funcione para você. É importante inspirar-se em múltiplas fontes, se você quiser escalar ágil na sua organização.
Se você quer escalar ágil e ter mais de 150 pessoas na sua equipe, então dois bons modelos de escalas são:
- Scaled Agile Framework (SAFe)
- Large Scale Scrum (LeSS)
Se você tem menos de 150 pessoas, Shape Up by Basecamp é um ótimo modelo para se aspirar.
Spotify não é um nirvana ágil
Espero que este artigo tenha destacado que a cultura da engenharia ágil no Spotify é muito mais do que apenas criar esquadrões, capítulos, tribos e guildas.
De facto, o Modelo Spotify é principalmente a sua cultura e equipas de alta competência, não o seu desenho organizacional. Você pode obter enormes benefícios ao adotar os princípios mesmo sem implementar esquadrões e tribos.
“Em artigos ou conversas como esta, pode acontecer que o Spotify seja uma espécie de nirvana ágil onde tudo simplesmente funciona e isso simplesmente não é verdade.”
Henrik Kniberg
A versão rápida de como escalar agile
Eu escreverei um blog inteiro sobre isso no futuro, mas por enquanto aqui está a versão rápida de como você deve escalar agile na sua organização:
- Escola claramente qual o problema que você está tentando resolver.
- Consume as melhores e mais relevantes partes dos melhores modelos de escalas da indústria, por exemplo, SAFe, LeSS, DaD etc. no seu design de destino.
- Cria um estado de destino que leve em conta as melhores práticas adaptadas ao seu conjunto único de desafios.
- Faça mudanças no seu design de estado de destino.
- Inspect and adapt constantly to find improvements based on evidence.
- Make course corrections based on the feedback.
- Rinse and repeat steps 4 to 6!