Sobre times e squads

Eu duvido que você consiga passar mais do que 15 minutos conversando com alguém que trabalha em alguma empresa de desenvolvimento e produto sem ouvir a palavra “Squad”. Parece que a palavra Time foi abolida do dicionário dessa galera e agora todo mundo que passa por uma “transformação digital” trabalha no formato de Squads. Qualquer Startup que trabalhar nesse formato. Mas é difícil entender por que eles escolheram esse formato. Várias empresas que se dizem trabalhar com Squads, estão trabalhando na verdade na estrutura normal de Times Multidisciplinares. E isso não é ruim, pelo contrário.

Primeiro, eu gostaria de tentar entender melhor o que é uma Squad. Esse termo veio do meio militar.

Curiosidade: O que é uma Squad na organização militar?

Uma organização militar é baseada numa estrutura hierárquica. Essa organização hierárquica foi difundida desde os tempos do império romano. Atualmente o controle executivo, a gestão e administração de uma organização militar é controlada pelo governo, por meio da administração pública, que por sua vez é representado por algo como o departamento de defesa do país.

Se você tiver interesse, como exemplo, você pode conferir a organização do exército brasileiro a partir dessa imagem:

Se formos dar uma olhada mais de perto em como a organização dos soldados é feita, nós vamos entender que o exército é dividido em unidades. Essa organização de unidades facilita muito o comando e o controle não apenas dos soldados, mas também da informação e objetivos de batalha, exatamente pelo motivo de que é impossível alguém sozinho controlar tantas pessoas, com responsabilidades diferentes, em lugares diferentes, em prol de um objetivo comum.

Geralmente, essas unidades começam como pequenos grupos, e conforme esses grupos se juntam, eles formam unidades maiores e assim por diante.

Cada uma dessas unidades tem um tamanho específico: nos Estados Unidos, um batalhão, por exemplo, é composto por algo em torno de 800 soldados. Aqui no Brasil, assim como nos EUA, uma divisão é composta por algo em torno de 9.000 a 20.000 homens, que é composta por vários tipos de brigadas.

A segunda menor unidade que existe na hierarquia é o que chamamos de Squad. O Squad é uma sub-unidade tática de um Pelotão. O Squad é composto de um mínimo de 8 soldados e no máximo 12. Nos EUA, geralmente, são 9 soldados. O Squad geralmente pode ser quebrado no que chamamos de Fireteam, que é a menor unidade que existe, composta de 3 a 4 soldados.

Pra ficar simples: você já deve ter ouvido falar de uma série chamada Band of Brothers. Essa série conta a história de uma Companhia (de 80 a 150 soldados). Já a história do filme O Resgate do Soldado Ryan, conta a história de um squad.

Se você já jogou Battlefield, consegue entender esse conceito, dado que você faz parte de um squad, que faz parte de um exército (uma companhia — se eu não me engano, no jogo, são 60 para cada lado).

Geralmente um Squad é formado levando em conta um objetivo. Assim como no jogo e nos filmes, o squad executa um determinado comando ou uma missão específica, depois que essa missão chega ao fim, o Squad pode se desfazer. Isso não quer dizer que o Squad não irá se agrupar novamente para uma nova missão, isso só quer dizer que o squad volta para o seu grupo maior.

O Squad no desenvolvimento de Software

A estrutura de squads ficou bastante famosa quando o Spotify divulgou como eles organizavam seus times de desenvolvimento.

O Spotify escolheu essa estrutura de forma orgânica. Ela funcionou porque fez, durante um bom tempo, sentido pra eles. Mas eles não se fixaram nessa estrutura, mas continuam mudando de acordo com as descobertas dos times.

Essa estrutura de Squads é muito parecida com a estrutura do Squad militar que expliquei no início: aqui os Squads também fazem parte de grupos maiores: Chapters, Guilds e Tribes. Além de terem missões (objetivos) para resolver.

Esse formato foi tão “inovador” para época, que as pessoas começaram a copiar loucamente nas suas empresas. Hoje, várias (todas?) “empresas de tecnologia” usam esse formato, ou pelo menos acham que usam… Na maioria das vezes várias empresas usam uma forma adaptada da ideia original do Spotify. Se você parar para analisar como essas empresas se organizam de verdade, vai perceber que eles ficam entre o formato de Squads e a estrutura de times multidisciplinares. E aí é que tá o problema: uma estrutura híbrida é muito pior do que uma estrutura que uma estrutura quebrada.

A estrutura de Times

Um time trabalha, obviamente, diferente de um squad militar, embora eles tenham várias semelhanças, como por exemplo: indivíduos com especialidades diferentes, executando tarefas de acordo com essas especialidades, um objetivo comum etc. Contudo, o time não é montado e desmontado com a mesma frequência. Quanto mais um time joga junto, mais eles aumentam uma coisa que chamamos de entrosamento. Esse entrosamento é resultado da confiança a nível individual adquirida no momento dos treinamentos e dos jogos que participam. Se cada jogador conhece seu companheiro, e sabe exatamente qual o seu papel do time, e confia que ele estará no lugar certo, ocupando a posição e a função que foi definida no treino, as jogadas passam a ficar mais previsíveis. Com menos imprevisibilidade, há aumento orgânico do sucesso. Logo, o entrosamento precisa ser levado para outro nível, fazendo com que os atletas se conheçam cada vez mais. Isso é muito evidente nos esportes como o Futebol. Se você procurar, há uma série de artigos que mostram o quanto um time se prejudica se há mudanças frequentes de atletas, técnicos, liderança etc.

The connections between team members are too hard to make. — What Makes Teams Work?

Eu não manjo de futebol e por isso as próximas frases são baseadas nas coisas que ouvi por aí: naquele fatídico dia, onde a Alemanha fez 7x1 no Brasil, um monte de gente tinha teorias malucas, mas uma que fazia muito sentido era que embora o time do Brasil tivesse muitos craques, jogadores com performances excelentes, jogando em times gringos e tudo mais, els não tinham o entrosamento e a quantidade de jogos juntos como os membros do time alemão.

Quando eu me refiro a times aqui no texto, estou falando sobre a estrutura de formação de times multidisciplinares e não a estrutura Waterfall antiga que as empresas estavam acostumadas. Embora eu não seja totalmente contra, pois sei que esse formato pode ser o mais adequado para algumas empresas, eu geralmente tento ficar longe de estruturas parecidas.

Mais adiante, falo um pouco sobre as semelhanças e diferenças entre times e squads.

As principais semelhanças e diferenças entre Times e Squads

As estruturas Squads e Times, tem suas semelhanças e diferenças. Tentei descrever algumas dessas semelhanças e diferenças levando em consideração esses pontos: resolução de objetivos, multidisciplinaridade dos times, tamanho do time, rodízio dos integrantes, responsabilidade das tarefas. Com certeza deve ter outros pontos importantes que eu deixei passar, mas acho que esses cobrem pelo menos os problemas mais comuns em grupos de desenvolvimento de produtos.

Objetivos

Ambas as estruturas tem um objetivo comum. Contudo, como num time de futebol o objetivo final não muda: fazer gols. Num Squad, o objetivo é quase sempre diferente. Uma hora você precisa resolver problemas de aquisição de clientes, outro momento na experiência de atendimento do usuário e assim por diante.

Quando separamos as pessoas em times, estamos fatalmente dizendo que o escopo não vai ser mudado tão cedo e que os integrantes daquele time trabalharão naquele objetivo específico.

Nesse vídeo, o Felipe Ribeiro, desenvolvedor brasileiro, explica como o Spotify separa a interface do usuário deles por times

Já com o Squad, não há um objetivo fixo, mas cada squad pegará um objetivo priorizado, que é importante para empresa. É bem diferente trabalhar assim, mas a empresa pode ter uma lista de prioridades criada pelos stakeholders, PMs e quaisquer outros personagens, como um backlog enorme.

Não importa qual o objetivo, uma squad será montada de acordo com esse objetivo, levando em conta as especialidades e força de trabalho que o objetivo demandar. E isso nos leva para o próximo tópico: Multidisciplinaridade.

Multidisciplinaridade

Ambos os formatos precisam de pessoas com especialidades complementares. Tanto um Squad quanto um Time tradicional precisam ter todas as especialidades no grupo para completar seu objetivo de forma independente. A ideia é que se houvesse um ataque zumbi, essas pessoas conseguiriam fazer deploy sem depender de ninguém.

Como os Squads tem objetivos diferentes de tempos em tempos, as especialidades do grupo são diferentes para se adequar ao objetivo selecionado. Já o Time que tem um objetivo menos mutável, tem especialidades específicas para alcançar aquele escopo. Se um time cuida da parte do checkout de um e-commerce, provavelmente esse time vai precisar ter integrantes que manjem bastante de fluxo de pagamento, integração com soluções de pagamento e etc…

Tamanho

O Scrum diz que um time bom pode ter de 3 a 9 integrantes. Um Squad, geralmente, tem esse tamanho também. Um time muito grande gera muita coordenação para garantir a comunicação, gerando complexidade. Um time muito pequeno, perde interação e a produtividade é afetada.

Em boas empresas, quando um time começa a ficar maior do que 9 integrantes, ele é quebrado em dois times, obviamente dependendo da estrutura que a empresa optou, novos papeis deverão se planejados nesse processo. Então, se você tem um TechLead no time, provavelmente quando o time se quebrar em dois, alguém deverá fazer esse papel. Isso se aplica a outros papeis também.

Rodízio de integrantes

O rodízio de integrantes, numa estrutura de squads, é regra. Um PM não deve se “acostumar” com as especialidades das pessoas daquele Squad, pelo motivo de que provavelmente no próximo ciclo, ele trabalhará em um objetivo diferente com outras pessoas.

Já em uma estrutura baseada em Times, o rodízio deve ser feito de forma parcimoniosa. Trocar várias integrantes do time de forma frequente é prejudicial para a performance do time. Geralmente novos membros não diminuem o Throughput e Leadtime de entrega, pois os integrantes mais antigos deverão usar uma parte do tempo para passar conhecimento para o novo integrante.

Como o escopo dos Squads mudam frequentemente, é normal que mais desenvolvedores conheçam mais partes do sistema. É uma democratização orgânica do conhecimento. Quando a estrutura é baseada em times, é comum que poucas pessoas tenham um grande conhecimento de uma parte específica do sistema. Esse é um dos motivos pelo qual o Rodízio de tempos em tempos de integrantes é importante. A frequência do rodízio pode acontecer levando em consideração o turnover dos times, gestão, sub-cultura de cada time e vários outros pontos.

Responsabilidade

Quando um bug é encontrado em um determinado ponto do sistema, quem é acionado para resolver? Num ambiente estruturado em Squads, esse é um problema que cada empresa pode resolver de acordo com a sua cultura. O ponto é que a responsabilidade é pulverizada. A organização e comunicação nesse ponto precisa estar muito bem azeitada para que o fluxo não pare. O PM/PO que liderou mudanças na parte do sistema que o bug foi encontrado pode ser o responsável pela resolução, ou os times podem se organizar para encontrar os integrantes que mais conhecem daquela parte do sistema, ou um squad pode ser montado para resolver bugs conhecidos… são várias soluções que precisam ser ponderadas podem ser adequadas de acordo com cada estilo de empresa.

Essa questão é mais fácil quando a estrutura é baseada em times. Sabendo em que ponto do sistema ou processo o bug apareceu, o time responsável por aquela parte do sistema é acionada e pronto, vida que segue.

Qual das duas é melhor?

Depende. Essa é a resposta óbvia. Pense nas duas estruturas como ferramentas. Contudo, usar uma ou outra vai depender bastante do perfil de profissionais de cada empresa. É muito fácil trabalhar em formato de Squads em uma empresa onde os integrantes são experientes. Em ambientes de Squad, o senso de missão deve ser bem alto. Missão dada é missão cumprida. O Spotify usa duas palavras que são chave ao se trabalhar em formato de Squads: Autonomia e Alinhamento.

Dado que temos um problema, esse problema precisa ser resolvido de alguma forma. Quem vai decidir COMO resolver aquele problema é a Squad. Não é o Stakeholder. Não é a diretoria. Os squads precisam ter autonomia para descobrir a causa raiz e decidir como atacar aquele problema. Além disso o alinhamento deve fazer parte do processo interno da Squad e também de forma global. Como as partes do sistema não tem um dono específico, todas as Squads precisam ter um alinhamento intenso, se não a coisa toda desanda.

A estrutura de times é flexível o bastante para se trabalhar muito bem com pessoas experientes e inexperientes. Como a complexidade é menor e as pessoas sabem que elas não farão um switch de objetivos de forma frequente, eles tem mais tempo para se adaptar e virar especialistas naquele parte do sistema. Nesse ponto, os melhores desenvolvedores, PMs e Designers buscarão entender os desafios da empresa e dos outros times, a fim de melhorarem seu trabalho no time em que atuam. Provavelmente eles buscarão passar um tempo nos outros times, não porque enjoaram do que estavam fazendo no time anterior, pelo contrário, com o conhecimento adquirido atuando em outros times, eles podem voltar para o time de origem levando informações valiosas.

Conclusão

O importante nesse processo inteiro é encontrar uma estrutura que funcione na sua empresa. Copiar o formato de uma empresa pode não ser uma boa escolha exatamente porque aquela empresa resolveu o problema dela, que geralmente é diferente do seu. Todas as empresas tem alguns problemas comuns na área de desenvolvimento, mas isso não quer dizer que a solução usada em uma empresa vai resolver o problema de estrutura da sua empresa. O Spotify, a Valve e várias outras empresas, inclusive brasileiras, tem suas próprias formas de estruturar times.

Leve em consideração a cultura da empresa, conhecimento da área de tecnologia, a dinâmica do mercado, a dinâmica dos seus clientes, turnover dos devs e designers, comunicação com as outras áreas, até a forma com que os stakeholders e a diretoria querem receber reports pode influenciar no formato a ser escolhido.

Boa sorte e bons desafios! ;-)

Mais referências


Originally published at diegoeis.com.

Like what you read? Give Diego Eis a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.