Times e squads coexistem e não são exclusivos
Descubra como os conceitos de squad e time podem coexistir em uma empresa de tecnologia, e como cada um pode ser utilizado para resolver problemas específicos ou trabalhar em contextos mais amplos.
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.