Published on

Por que copiar squads do Spotify não resolve problemas de organização

Authors
por-que-copiar-squads-do-spotify-n-o-resolve-problemas-de-organiza-o

Fabio Akita retoma a crítica às metodologias ágeis para atacar um caso específico: a venda do chamado modelo Spotify como solução pronta para empresas. Ele descreve squads, tribes, chapters e guilds como uma reorganização de nomes para estruturas conhecidas, com equipes cross-funcionais, coordenação por produto e grupos horizontais de especialidade. O ponto central não é negar que essas práticas possam funcionar, mas mostrar que o modelo era uma fotografia parcial do Spotify entre 2012 e 2014, já contestada por profissionais da própria empresa. Copiar vocabulário e organograma, para ele, é perder o mecanismo que produziu aquele arranjo.

A discussão então se desloca para a ideia de modelos em geral. Akita argumenta que modelos são descrições temporárias de ambientes específicos, não projetos universais a serem implementados de cima para baixo. Para sustentar isso, recorre a sistemas adaptativos complexos, evolução, teoria do caos, redes e auto-organização. A analogia recorrente é que ordem pode emergir de agentes livres sob certas restrições, mas não por decreto. Ele distingue microgerenciamento, que gasta muita energia para manter uma ordem rígida, de anarquia, que depende de sorte, e defende operar no limite entre ordem e caos, com ciclos de aprendizado e correção.

Na aplicação às empresas, a tese passa por alinhamento, autonomia e qualidade dos agentes. Alinhamento significa direção clara; autonomia não significa democracia interna nem poder irrestrito para funcionários decidirem tudo. Para Akita, autonomia deve existir principalmente nas decisões técnicas ligadas à competência de quem foi contratado. Isso só funciona se a empresa tiver profissionais motivados por domínio técnico, não apenas por cargo ou salário, e se remover chefes, líderes e funcionários que bloqueiam decisões, introduzem burocracia ou agem de má-fé. Sem essa limpeza, Scrum, Lean, Kanban ou squads apenas escondem problemas antigos com termos novos.

A parte prática volta ao básico da engenharia: código sempre pronto para produção, integração contínua, testes automatizados, revisão por pares, deploys frequentes e backlog bem definido. Ele critica sprints longos cheios de reuniões, mudanças constantes de prioridade e microserviços usados para mascarar a incapacidade de equipes colaborarem, citando a Lei de Conway. O episódio fecha com a comparação com projetos de software livre, onde pouca estrutura, transparência útil, decisões claras e foco em software funcionando produzem resultados que muitas empresas não conseguem obter com camadas de coaches e rituais.

Assistir ao episódio original

Referências encontradas

Livros

Filmes

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.