Entendendo o verdadeiro significado do “modelo Spotify”
Na última semana tive a oportunidade de participar de um curso com dois Agile Coaches que trabalharam no Spotify
Na última semana tive a oportunidade de participar de um curso com dois Agile Coaches que trabalharam no Spotify (Joakim Sunden que hoje está no Crisp e Henrique Imbertti do Luizalabs). O objetivo do curso era detalhar o modelo Ágil usado no Spotify, o qual ficou comumente conhecido como “modelo Spotify”. Isso mesmo, com aspas. Pois a provocação é justamente essa: não existe esse “modelo” que muitos acreditam.
O objetivo deste texto é compartilhar alguns insights e reflexões que tivemos no curso para ajudar e inspirar outros. São eles:
1 — Não existe um modelo definido. Até mesmo na época em que foram distribuídos o vídeo e os documentos sobre esse modelo, não era algo que todos os squads no Spotify usavam. E nem mesmo um modelo único. Era uma fotografia de idéias que estavam funcionando em um contexto para alguns times da empresa. Então o primeiro conceito aqui é a desconstrução da idéia de um padrão ou um sistema homogêneo em relação a construção e regras desses squads em que todos da empresa seguiam. Cada time estava em um estágio de maturidade diferente e seguiam regras que faziam sentidos à eles, desde que dentro dos limites que a empresa operava.
2 — O Spotify nunca passou por uma transformação. Ou seja, o “modelo” não é um framework a ser seguido à risca em empresas que estão em processo de transformação. Ele serve de inspiração para as empresas, mostrando como o Spotify resolveu um problema: organizar a área de RnD (pesquisa e desenvolvimento) para obter melhor produtividade e escalar os times sem perder a noção de pertencer à um grupo. Isso dado o contexto do Spotify. Não significa que adotar squads (isoladamente) em uma empresa vai ser a solução dos problemas (que é grande parte da fotografia que tenho visto nas empresas). Um exemplo que foi dado é a empresa holandesa ING que passou por uma transformação de fato e criou(olha que coisa bonita) um modelo ágil inspirado em conceitos do Google, Netflix e Spotify. Há bastante material disponível sobre esse processo de transformação da empresa inteira e por todas as filiais no mundo. Uma frase usada no curso ajuda a entender esse ponto:
The design can be good, but adjustments make it great
3 — O Spotify é uma empresa de desenvolvimento de produtos. E isso faz toda a diferença. Como eles trabalhavam com o PMO? E os gerentes de projetos que …? Então, eles nunca tiveram esse problema. O que é bem diferente (for god's sake) de os desenvolvimentos não terem data. Eles até brincaram que em uma conferência o presidente falou uma frase de impacto: “a gente não entrega no prazo, a gente entrega com qualidade”. E adicionaram: “ele deve ter se arrependido muito por ter dito isso”. É claro, no mundo real, invariavelmente temos compromissos com datas. Mas desde que sejam datas que fazem sentido (com os seus motivos muito bem explicados) e não “fake dates” para agradar egos. Entretanto, não é um “então não tem mais data” e nem um “então tudo tinha data”. Algumas coisas seguiam datas declaradas (e que faziam sentido) nos OKRs, outras estavam em processo de teste de hipóteses e podiam falhar.
4 — O verdadeiro modelo Spotify é, na minha interpretação, um conjunto de valores e princípios que guiavam os times. Ou como eu tentei definir para fazer sentido: um metamodelo — um modelo que define modelos. Esse conjunto de valores e princípios que juntos fornecem a possibilidade de se criar múltiplos modelos aderentes ao objetivo. Esse conjunto não é nenhuma fórmula mágica na teoria mas tem sim o seu prestígio por ter conseguido ser seguido em níveis corporativos na prática.
5 — Algumas coisas foram reforçadas da minha experiência com ágil, outras foram novidade. De forma geral (bem macro): Autonomia, motivação, adaptabilidade — entre outros conceitos — combinados a se chegar em um objetivo, formam a base do que é o metamodelo.
Autonomia não é ser livre para fazer o que bem entender e sim autonomia significa se sentir livre para agir, dentro das suas capacidades, para contribuir em direção a um objetivo coletivo — definição de um outro agile coach do Spotify (mais detalhes aqui).
O alinhamento (e a busca constante por esse alinhamento) permite a autonomia. Outra forma de entender alinhamento é alinhamento = intenção (o que) + racionalização (por que?) + restrições (quais restrições no como).
Adaptabilidade é como realizar as tarefas em um contexto VUCA (volatile, uncertain complex, ambiguous). Contextos VUCAs são quase 100% no desenvolvimento de software. Ainda sobre adaptabilidade, o principal motivo de não se ter um único “modelo Spotify”. Cada squad se adaptava de um jeito e continuamente ia se adaptando para chegar no objetivo. Eram fracamente acoplados mas fortemente alinhados. Por isso, quando se mostrava a maneira de se trabalhar de um squad aquilo era uma fotografia de um filme que estava ainda rodando. Ou como ficou marcado para mim:
It’s about moving
6 — Outros dois valores formam a base da cultura, são bem fortes, fáceis de entender e difíceis de se ver em prática: confiança e foco em recuperação de falhas. Confiança na prática significa não ter relatórios de apontamento de horas, política de gastos de viagem e eventos, acesso direto à produção. Mas qual é o ponto aqui de verdade? É que se você não gasta tempo e energia micro-gerenciando os funcionários, então você pode gastar tempo e energia em outras coisas. Na mesma idéia de preservar energia e tempo, o foco em recuperação de falhas ao invés de focar em evitar falhas faz o mesmo sentido. Afinal, quando se falha, e se recupera rápido houve uma lição aprendida. E quando compartilhamos essas falhas como lições aprendidas a nível corporativo, toda a empresa (e não só o squad ou tribo) aprende também. Um sub-produto desse conceito é: quando publicar (release) é fácil, a publicação é frequente. Quando a publicação é difícil, a publicação é rara.
7 — Minimum Viable Bureaucracy e Minimum Viable Agility: Dado que a burocracia impede o potencial do Ágil e a ausência da burocracia é o atalho para o caos. Deve se discutir qual é a mínima burocracia viável, bem como em times que já estão em um nível de maturidade alto (agile nirvana) começar a pensar em minimum viable agility, ou seja, como customizar e enxugar as práticas ágeis, sem perder o mindset e princípios ágeis e obter o mesmo resultado. Achei esse artigo que tem bastante informações sobre o tema.
8 — O mais importante na empresa era o squad autonomo e produtivo. Principais características desse squad: autônomo, auto-organizável, com um objetivo claro, multi-funcional e ter a responsabilidade fim-a-fim (era dono do processo, qualidade e operação). Fácil de falar, difícil de fazer.
9 — Todas essas idéias, valores e princípios colocados em prática geram uma coisa muito importante: motivação e engajamento. Como Steve McConnell definiu: “a motivação tem um papel maior na produtividade e na qualidade do que qualquer outro fator”. E buscar o engajamento do time é a maneira mais barata e mais rápida de se entregar.
10 — Por fim, esses pontos são os que mais fizeram sentido dado o meu conhecimento e experiência. Ainda assim creio que eu nem arranhei a superfície. Não falei sobre tribos, dibbs, OKR, golden paths, etc. Ou seja, obviamente esse tema não se esgota aqui. Porém, ainda vejo empresas usando o termos squads e tribos e achando que estão no modelo Spotify. Essa adoção “rasa” não é novidade. Já vimos isso acontecendo com empresas usando post-its, paredes coloridas e sprints de duas semanas achando que estavam sendo ágeis.
