Grande demais para escalar – Guia de tamanho ideal da equipe Scrum

Ouça a versão em áudio deste artigo

Esteja você trabalhando em uma pequena startup ou em um novo produto em uma grande empresa, provavelmente chegará a um ponto em que terá muitas pessoas em uma equipe. Identificar os sinais desde o início evitará que você chegue ao estágio mais ineficiente da equipe.

Cada produto é diferente e as equipes que trabalham neles também. Assim, dividir uma equipe também exigirá que você tome algumas decisões que reflitam suas circunstâncias. Algumas coisas a considerar são:

• Como manter a integridade do know-how quando os colegas de equipe não estão mais trabalhando juntos
• Você deve dividir as funções (por exemplo, equipes de front-end e back-end)?
• As novas equipes devem ter backlogs separados?
• A equipe de gerenciamento de produtos deve crescer de acordo?

Quando você deve começar a criar uma segunda equipe?

A indicação mais óbvia para começar a pensar em uma divisão de equipe ou adicionar uma nova equipe é quando seu orçamento aumenta. Isso pode ocorrer para uma nova rodada de investimentos em uma startup ou novas metas para seu produto em uma empresa. Se o aumento do orçamento for tão substancial que sua equipe crescerá 3x ou mais, então é óbvio que você terá que dividir sua equipe atual para distribuir know-how. No entanto, as decisões não se tornam tão claras quando o aumento do orçamento é incremental e você acaba adicionando algumas novas pessoas à lista. Se, digamos, você planeja aumentar sua equipe de 7 para 11 pessoas, isso exige uma divisão? Agile promove equipes pequenas, mas também promove indivíduos e interações sobre processos e ferramentas. Ter duas ou mais equipes inevitavelmente cria mais processos para poder trabalhar em sincronia.

O que dizem os especialistas?

Jeff Bezos, o fundador da Amazon, tem usado a regra de duas pizzas para reuniões e equipes. Isso significa que cada um deve ter apenas o número de pessoas que duas pizzas podem alimentar no almoço.

O Guia do Scrum sugere ter entre três e nove membros da equipe que estão realmente executando o sprint backlog. Isso significa que você não incluiria o proprietário do produto ou o scrum master no total, a menos que um deles estivesse implementando os itens do sprint backlog.

Esses números parecem fazer sentido intuitivo, mas também há alguma matemática por trás disso. Se você pensar em uma equipe, cada pessoa é como um nó e se conecta a outros nós. Estas são as relações interpessoais entre os companheiros de equipe. Eles podem ser amigáveis, competitivos, rancorosos ou atenciosos. Qualquer que seja o relacionamento entre duas pessoas, ainda é um vínculo que exige alguma capacidade mental de cada pessoa. À medida que uma equipe cresce, esses números desses links não crescem linearmente. A fórmula para ligações entre nós é \(n(n-1)/2\). Aqui está o gráfico de crescimento do link:

O gráfico ilustra claramente, do ponto de vista matemático, por que as equipes operam com mais eficiência quando não são muito grandes. Se pegarmos os 3 a 9 membros da equipe sugeridos pelo Scrum Guide, acabamos com entre 3 e 36 links. Se crescermos para 15 pessoas, teríamos mais de 100 links. Uma equipe desse tipo só poderia operar com eficiência se suas funções fossem muito bem definidas e raramente se sobrepujassem ou se houvesse alguns subgrupos não oficiais. Nem é o caso ou desejado quando se trabalha com base em princípios ágeis.

Sinais de que a equipe está ficando grande demais

Reunião diária

Às vezes referido como a reunião diária, o scrum diário é uma reunião de toda a equipe para discutir o progresso e os impedimentos do sprint. O Guia do Scrum sugere cronometrar isso em 15 minutos e esse é um bom teste decisivo para o tamanho da equipe. Se você começar a perceber que sua equipe está ultrapassando a barra de 15 minutos, isso pode indicar uma de duas coisas:

• Os scrums diários não são eficientes. As pessoas estão entrando em muitos detalhes. Ou não há uma ordem de fala clara e leva tempo para os colegas de equipe falarem. Talvez o proprietário do produto ou o scrum master esteja usando o scrum diário como uma oportunidade para fornecer várias atualizações não relacionadas ao sprint.
• A equipe é muito grande. Se os scrums diários forem eficientes, mas você ainda estiver ultrapassando os 15 minutos, pode simplesmente ter muitas pessoas na equipe. Você também deve começar a perceber que as pessoas estão perdendo o interesse porque há um limite para a quantidade de informações que uma pessoa pode receber. Se muitas pessoas estiverem fornecendo atualizações, fica difícil acompanhar o progresso de todos e entender o status da equipe . Isso faz com que as pessoas se voltem para dentro e reflitam apenas sobre seu progresso, em vez de procurar oportunidades para ajudar os outros.

Grooming e Sprint Planning

Tanto o grooming quanto o planejamento do sprint são atividades relacionadas a quebrar histórias de usuários e estimar seu tempo ou tamanho de entrega. Embora ter mais pessoas possa ajudar a equipe a tomar melhores decisões, ter muitas pessoas pode levar a equipe a um impasse. Sempre há maneiras diferentes de realizar a mesma tarefa e o número de argumentos de cada lado aumenta com o número de pessoas na equipe.

Assim como no scrum diário, não confunda uma sessão de planejamento ineficiente com a equipe sendo muito grande. Em última análise, é o trabalho do scrum master fazer com que as cerimônias do scrum sejam eficientes e eficazes.

Retrospectivo

Durante uma retrospectiva, os membros da equipe podem resolver quaisquer discussões ou conflitos e encontrar maneiras de melhorar seu processo de trabalho. As retrospectivas nos ensinam a arte do compromisso, pois nos faz buscar um terreno comum entre diferentes partes. Uma equipe é tão poderosa quanto seus membros estão dispostos a comprometer suas diferenças.

No entanto, como no planejamento do sprint, muitos membros da equipe criam muitos links, todos os quais são pontos potenciais de conflito. Comece a perceber se você está encontrando cada vez menos pontos em comum durante as retrospectivas. Pode ser um sinal de que a equipe é muito grande e se beneficiaria com a divisão.

Como dividir a equipe

À primeira vista, dividir a equipe é uma tarefa relativamente fácil. Divida os membros da equipe em dois grupos, certifique-se de que cada um tenha pessoas com experiência semelhante e defina os objetivos para as novas equipes. No entanto, há algumas coisas a considerar que podem ter um grande impacto no sucesso futuro das novas equipes.

Moral da equipe

Provavelmente, uma das coisas mais importantes a ter em mente é o moral da equipe. No final das contas, são as pessoas da equipe que terão que trabalhar na nova composição. Se a equipe é madura em termos de princípios ágeis, ela deve ser capaz de fazer a divisão por conta própria. Este é o resultado mais desejável porque os membros da equipe conhecem melhor seus relacionamentos internos - quem trabalha melhor com quem e quem poderia se beneficiar de estar em equipes separadas.

Equipes multifuncionais

Scrum promove equipes multifuncionais “com todas as habilidades como uma equipe necessárias para criar um incremento de produto”. Isso vale ao dimensionar para duas ou mais equipes. Para muitos desenvolvedores, especialmente se eles são novos no Agile, a tendência natural é pensar ao lado das linhas técnicas. Por exemplo, as equipes geralmente querem se dividir em equipes de back-end e front-end. Isso pode fazer sentido em algumas raras ocasiões, mas como gerente de produto, você deve desaconselhá-lo na maioria das vezes. Uma equipe cheia de front-enders não é capaz de entregar um incremento de produto por conta própria e naturalmente começará a pensar mais na capacidade técnica, que é o que os une. Em vez disso, eles devem se concentrar no cliente e em como satisfazer suas necessidades.

Outra consideração interessante são as funções de não desenvolvimento na equipe. Em várias situações, uma equipe pode incluir um designer, analista de negócios ou especialista em controle de qualidade. Depois de dividir uma equipe, especialmente se você não estiver contratando muitas pessoas novas, surge um dilema sobre o que fazer com essas funções. Eles devem dividir seu tempo entre as equipes? Se você contratar novas pessoas, que seriam dedicadas a apenas uma equipe? Eles devem trabalhar com as equipes de desenvolvimento ou fazer parte da equipe do produto?

Realmente não há um bom conselho único para isso, porque cada produto é muito diferente. Essas decisões devem ser tomadas em conjunto com a equipe, tendo em mente que você pode precisar corrigir o curso ao longo do caminho.

As equipes devem ter backlogs separados?

Se uma equipe está dividida, então a questão natural é se eles devem trabalhar com o mesmo backlog ou ter outros separados. Podemos olhar para o Scaled Agile Framework para orientação.

Scrum@Scale

Scrum@Scale é uma metodologia desenvolvida pelo criador do Scrum Guide. Scrum@Scale não é muito prescritivo e não descreve especificamente como lidar com backlogs de produtos. No entanto, observa dois pontos:

• O processo em nível de equipe é o mesmo descrito no Guia do Scrum.
• Os proprietários de produtos formam uma equipe de proprietários de produtos, onde criam uma única lista de pendências unificada. Isso é feito para evitar a duplicação de trabalho e criar visibilidade dentro da empresa. Ao mesmo tempo, as equipes têm seus backlogs separados que alimentam itens do backlog unificado.

Então, em essência, o Scrum@Scale cria imagens das novas equipes com seus respectivos POs e backlogs. Apenas adiciona algumas estruturas adicionais para coordenar o trabalho entre as equipes. Scrum@Scale funciona melhor com várias, dezenas ou centenas de equipes, mas pode fornecer alguns insights valiosos, mesmo se você estiver trabalhando com duas equipes.

Scrum em grande escala (LeSS)

O LeSS promove uma abordagem interessante para o backlog do produto. No LeSS, um proprietário de produto trabalha com duas a oito equipes. Pode parecer impossível para um PO trabalhar com tantas equipes. A filosofia do LeSS é que o PO trabalha em um nível abstrato e delega as responsabilidades de refinamento do item do backlog do produto às equipes. Nesse caso, as equipes de desenvolvimento multifuncional também devem incluir o conhecimento do domínio do negócio para poder entregar um incremento de produto. No LeSS, há apenas um backlog.

Como se manter atualizado

Para um gerente de produto, várias equipes significam mais trabalho acompanhando o progresso e respondendo a consultas.

Priorizar reuniões

Se você estivesse participando das reuniões diárias de uma única equipe, continuar esse hábito provavelmente será improdutivo. Considere os scrums diários como uma chance de dar uma olhada nas equipes e lembrá-las de que você está disponível para discussões.

Sua participação nas sessões de planejamento do sprint dependerá da maturidade das equipes. Se as equipes incluem muitas caras novas ou não trabalham com o Agile há muito tempo, será necessária alguma orientação do seu lado. Mesmo que você se sinta confiante em deixar a equipe planejar sem a sua presença, certifique-se de estar disponível para conversar ou conversar com a equipe durante o planejamento, se surgir alguma dúvida.

As revisões da Sprint terão que continuar sendo sua principal prioridade e todas elas devem ser atendidas. As revisões do Sprint são uma chance de obter feedback em primeira mão de qualquer parte interessada presente e da própria equipe. É um momento em que as suposições são validadas e não devem ser perdidas.

Envolva-se mais com Scrum Masters

Embora você possa estar reduzindo seu envolvimento com algumas das cerimônias do scrum, você deve dobrar sua parceria com o scrum master. Pode haver mais de um agora após a divisão da equipe; nesse caso, você precisaria trabalhar em estreita colaboração com todos eles.

Certifique-se de que pode confiar neles para fornecer uma visão honesta do progresso da equipe e de quaisquer problemas que surjam durante os sprints. Esses relacionamentos permitirão que você se mantenha atualizado sem a necessidade de se envolver em todas as cerimônias do scrum.

Introduzir Scrum de Scrums

Às vezes chamado de meta scrum, um scrum de scrums é uma nova cerimônia que normalmente é introduzida como escala de processos scrum. É uma réplica do scrum diário em um nível superior. Cada equipe designa um embaixador, todos os quais se reúnem no scrum of scrums todos os dias para discutir o progresso e os impedimentos. Essa cerimônia também é usada para destacar quaisquer problemas técnicos entre equipes que possam precisar ser resolvidos.

Considere expandir a equipe de produto

Se a configuração do scrum exigir que o gerente de produto se envolva ativamente com a equipe, considere adicionar mais pessoas ao lado do produto. Existem algumas maneiras de abordar isso.

Gerentes de produto júnior. Um caminho é assumir um papel mais estratégico para si mesmo enquanto adiciona gerentes de produto juniores para lidar com algumas das tarefas diárias. Eles podem assumir algumas tarefas, como garantia de qualidade (QA), escrever especificações para histórias de usuários ou criar maquetes de alto nível para novos recursos.

Analistas de negócios. Outra maneira é ter um ou mais analistas de negócios trabalhando nas equipes ou ao lado delas. O gerente de produto pode trabalhar com analistas de negócios para identificar suposições de produtos e permitir que os analistas de negócios encontrem maneiras de validá-las por meio de pesquisas ou novos recursos.

Conclusão

À medida que sua equipe cresce, é provável que você comece a perceber alguns sinais de que ela está se tornando muito grande, especialmente em:

• Scrum diário. Se você estiver ultrapassando o prazo de 15 minutos durante as reuniões diárias e perceber que as pessoas começam a perder o interesse.
• Planejamento de sprints. Se você acabar em impasses durante o planejamento do sprint com mais e mais frequência.
• Retrospectivo. Se você começar a perceber que está se tornando mais difícil chegar a compromissos durante as retrospectivas.

Tudo isso aponta para o fato de que você pode precisar dividir a equipe. Dividir uma equipe é aparentemente uma tarefa fácil, mas também tem consequências duradouras e todo gerente de produto tem algumas coisas a considerar ao fazê-lo:

• Moral da equipe. Idealmente, você deve deixar a equipe decidir como deseja se dividir para minimizar o número de boas relações de trabalho descartadas.
• Equipes multifuncionais. As equipes devem ter todas as habilidades necessárias para criar um incremento de produto.
• Backlog do produto. Decida se suas equipes terão um backlog separado ou unificado.

Manter o controle de duas ou mais equipes exigirá que você priorize. Um gerente de produto eficaz deve planejar como se manterá atualizado com as novas equipes:

• Priorize as reuniões. Pense em quais cerimônias ágeis valem o seu tempo e quais podem ser ignoradas.
• Envolva-se com scrum masters. Use scrum masters como proxies de sua equipe e colete informações deles.
• Expanda a equipe de produtos. Adicione pessoas para trabalhar com você e ajudar com tarefas repetitivas diárias ou realizar pesquisas de usuários e análises de mercado.

Ao utilizar essas sugestões, você poderá ter uma divisão limpa da equipe. Se suas equipes continuarem crescendo e você estiver adicionando ainda mais equipes no futuro, você deve ler sobre Scaled Agile Framework, que fornece sugestões de estrutura e processo para Agile em escala.