Muitas equipes têm vivenciado algumas dores comuns que dão sinais de que o time/squad está muito grande e precisa ser dividido. Como também já passei por este problema antes, resolvi escrever este blogpost sobre divisão de squads para compartilhar a minha experiência.

Com base nas experiências que tive, vou mostrar abaixo algumas dicas do por quê de realizar a quebra de squads e uma forma de dividir seu time para melhoria tanto das suas entregas quanto do seu processo. Bora lá!

Primeiro passo: avaliação e decisão

O primeiro passo é identificar se o seu time precisa realmente ser dividido. Alguns sintomas podem evidenciar esta necessidade:

• Baixo engajamento em reuniões e/ou recusa em participar em reuniões, pois “isso não é interessante para meu trabalho”;
• Dificuldade em facilitar reuniões pela quantidade de pessoas;
• Diversidade de produtos/serviços/usuários dentro de um mesmo squad;
• Métricas que não mostram a realidade;
• Sentimento de “falhamos nesta entrega”, apesar de uma parte do produto ter sido entregue com valor para o usuário.

Apesar destes sintomas poderem estar relacionados a outras causas, a divisão do squad pode ajudar a resolver ou até solucionar estes problemas. Lembrando também que o seu time pode sim ser dividido mesmo tendo uma quantidade pequena de pessoas e talvez não precise ser divido mesmo tendo uma quantidade grande de pessoas. Pense nisso!

Ainda sobre as dores, um parentese sobre a visibilidade das métricas

Se o seu time utiliza de métricas para melhoria de processos, remoção de gargalos e previsibilidade, a visibilididade das métricas pode estar comprometida devido a grande diversidade de características dentro do seu time. Pode ser que haja diferença em parte do time quanto aos processos, a velocidade, natureza das demandas, tipo de produto ou usuário, e outros, que quando as métricas estão juntas, as melhorias que o processo precisa podem não estar visíveis para serem implementadas. Vou utilizar aqui uma experiência que tive em um projeto:

Neste projeto, havia uma plataforma de mobile e outra web para o mesmo tipo de usuário e uma Squad única atendia ambas plataformas. Durante o dia a dia de trabalho sentíamos algumas dores, porém elas não estavam sendo refletidas nas métricas. Após algumas discussões sobre os problemas que vínhamos enfrentando no time, entre eles: reuniões longas; atrasos em uma das frentes; discussões onde todos estavam presentes, porém poucos participavam. Percebemos que o time precisava ser quebrado e depois dessa decisão as métricas começaram a fazer sentido.

Com a quebra, percebemos que a frente de mobile e a frente de plataforma web possuíam características diferentes de desenvolvimento, apesar de seguirem as mesmas etapas no processo. Isso ficou claro quando fomos consultar o grafico de CFD após a divisão e verificamos que havia um grande tempo em espera dos cards que estavam na etapa “pronto para produção”. Tal característica se dava pelo fato da história ter que esperar ser homologada antes de ser enviada para a loja ou aguardar um conjunto de funcionaldades chaves ser implementada para, então, fazermos a release da versão, fato que não ocorria na outra frente. Outro ponto que conseguimos acompanhar com o CFD separado foi o fato de uma frente estar com poucas demandas no backlog e correndo o risco de não ter demandas para trabalhar nos próximos dias. Tudo isso ficava diluído na visualização das métricas quando os dados de ambos os times estavam juntos.

Outro ponto foi em relação ao throughput do time, que enquanto uma frente tinha um throughput semanal mais alto, o outro tinha um throughput muito mais baixo devido a uma série de fatores, como quantidade de desenvolvedores na plataforma, estrutra do software para novas funcionaldades, complexidade das demandas, entre outros. Isso impactava na previsibilidade do produto quanto consultávamos o burnup, por exemplo, pois em uma frente estávamos sendo muito pessimista e na outra muito otimista com a junção dos dados de ambas as frentes.

Se preparando para a mudança

Decidido que a divisão é o caminho, tenha em mente que seu problema não vai se resolver de forma rápida e em uma única alteração no time. Vai ser preciso realizar alguns ajustes durante o processo de mundança e o envolvimento do time é crucial. Tente fazer pequenas melhorias progressivamente em direção ao que querem alcançar e evitem grandes alterações, utilizando o conceito da curva J ou The J Curve of Change.

Uma forma de dividir: divisão por frentes.

Uma das formas de conseguir dar mais agilidade para sua equipe é manter a multiciplinaridade dos membros desta equipe. Se você pensou em dividir o squad por tipo de software, como backend, frontend e mobile, talvez esse não seja o melhor caminho se há dependências destas partes para gerar valor para o usuário.

Ao dividir o time por tipo de disciplina, você correrá o risco de uma parte do produto ou serviço que o time está desenvolvendo fique pronta e a outra parte complementar desta demore muito tempo ainda para ser finalizada. Isto é comum de se perceber em times de desenvolvimento de software quando, por exemplo, a tela de uma funcionalidade foi desenvolvida, porém a parte de backend anida não e, sem ambas o partes, o valor da funcionalidade não é entregue na mão do usuário. Com isso, atrasamos o feedback sobre a funcionalidade, aumentando o risco de integrações entre as partes entre outros problemas. Se você quer entender melhor sobre as consequências que este atraso pode trazer, recomendo este blogpost sobre Cost of Delay e um e-book localizado neste blogpost de um dos nossos consultores ágil.

Em resumo, somente a partir desta quebra é que de fato conseguimos vizualizar os problemas sentidos pela equipe. Dessa forma podemos evindenciar estes problemas, propor soluções para eles e verificar o resultados destas soluções com métricas.

Uma sugestão de divisão

É lógico que cada caso é um caso, mas uma forma que eu vejo que tem dado certo é a divisão dos squads por tipos de serviços e/ou usuários. Isso significa que em um time que contém membros com especializações em disciplinas diferentes (como backend, frontend e mobile, por exemplo), deveríamos dividir de uma forma que o time consiga desenvolver funcionalidades completas e evitar a divisão por disciplina.

O seu time pode, por exemplo, ser divido por tipos de usuários onde cada time conteria as habilidades necessárias para entregar valor de forma completa para o usuário após a divisão.

Os trade-offs dessa divisão

Das vantagens desta divisão, temos algumas que se destacam, como a rapidez da entrega de funcionalidades, a melhoria na comunicação dentro do squad, reuniões mais produtivas e em menor tempo de duração, melhor visibilidade do backlog para cada squad/frente, redução do Lead Time e do Time to Market.

A equipe onde essa divisão foi aplicada também se sentiu motivada, pois antes havia a sensação de “entregamos algo, mas e daí?” que vinha do fato de ter dois tipos de objetivos diferentes mascarados em um único objetivo dentro do mesmo time e quando uma parte atingia o “objetivo” o restante do time se sentia “atrasado”, o que causava uma insatisfação de todo o time e sendo um tópico de discussão nas retrospectivas. Com a separação, cada time se sentiu mais realizado sabendo que cada time tinha seu próprio tempo para atingir seus objetivos.

Há também algumas desvantagens, como um maior esforço para sincronizar o trabalho entre os squads e gerenciar o backlog, a estrutura do software pode não sustentar este tipo de divisão e tornar o processo lento e burocrático e recursos compartilhados, como QA, precisam de uma maior orientação sobre as prioridades dos squads.

Em resumo, acredito que dependendo do momento da sua equipe e do seu produto, vale a pena sim realizar esta divisão.

E você? Já teve dificuldades em dividir o seu time? Já realizou alguma divisão de squad? Deixe seus comentários abaixo sobre sua experiência com divisão de times!