Usar o termo "squad" para se referir aos times de produto ficou muito comum por causa do modelo Spotify. Isso aconteceu em meados de 2014, quando o Spotify publicou o formato de trabalho deles[1]. Você pode até ler o paper original divulgado pelo Spotify, explicando detalhadamente as motivações e as estruturas preparadas para a prática de escala agile na empresa aqui[2].
Se você parar para perceber, o que eles propuseram foi nada mais, nada menos, que uma estrutura matricial comum, como a estrutura que eu expliquei anteriormente. O ponto aqui é que eles usaram nomes que viralizaram demais no mercado, pois facilitou muito como a quebra de times dentro de uma empresa de tecnologia poderia funcionar. Logo, nomes como Guilds, Chapters e Squads começaram a ser utilizados por toda e qualquer empresa de tecnologia.
Eu falei um pouco sobre isso no último livro[3], onde comparei as similaridades e diferenças de um time e uma squad. Então, para resumir e ir direto ao ponto aqui: squads são feitas para cumprirem um objetivo que tem começo, meio e fim. Um time é feito para perpetuar dentro de um contexto específico.
Os dois conceitos podem inclusive coexistir. Uma squad pode ser montada para resolver um problema muito específico, mas importante, que tem um impacto relevante dentro de um contexto. Logo depois que esse problema (ou solução) for resolvido, a squad deveria se desfazer. Já um time, como vimos anteriormente, trabalha dentro de um contexto de frente de negócio, focado nos objetivos cumulativos daquele contexto.
Este post é apenas para assinantes
Cadastre-se agora para ler o post e ter acesso à biblioteca completa de posts exclusivos para assinantes.
Cadastre-se agora
Já tem uma conta? Entrar