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 logo no início evitará que você alcance o estágio mais ineficiente da equipe.

Cada produto é diferente, assim como as equipes que trabalham nele. Portanto, dividir uma equipe também exigirá que você tome algumas decisões que refletem 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 produto 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 dividir a equipe ou adicionar uma nova é quando seu orçamento aumenta. Isso pode ocorrer com uma nova rodada de investimento em uma startup ou com novos objetivos para seu produto em uma empresa. Se o aumento do orçamento for tão substancial que sua equipe crescerá 3 vezes 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 pessoas novas à lista. Se, digamos, você tem planos de 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 o regra das 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 Scrum sugere ter entre três e nove membros da equipe que estão realmente executando o backlog do sprint. Isso significa que você não incluiria o product owner ou scrum master no total, a menos que algum deles esteja implementando os itens do sprint backlog.

Esses números parecem fazer sentido intuitivamente, mas também há alguma matemática por trás deles. Se você pensar em uma equipe, cada pessoa é como um nó e eles se conectam a outros nós. Estas são as relações interpessoais entre companheiros de equipe. Eles podem ser amigáveis, competitivos, rancorosos ou atenciosos. Qualquer que seja a relação entre duas pessoas, ainda é um elo que requer alguma capacidade mental de cada pessoa. Conforme a equipe cresce, esses números desses links não crescem linearmente. A fórmula para links 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 Guia do Scrum, acabamos com entre 3 e 36 links. Se crescêssemos para 15 pessoas, teríamos mais de 100 links. Uma equipe desta só poderia operar com eficiência se suas funções fossem muito bem definidas e raramente se sobrepusessem ou se houvesse alguns subgrupos não oficiais. Nenhum é o caso ou desejado ao trabalhar com base nos princípios do Agile.

Sinais de que a equipe está ficando grande demais

Daily Scrum

Às vezes chamado de standup diário, o scrum diário é uma reunião de toda a equipe para discutir o progresso e os impedimentos do sprint. O Scrum Guide sugere cronometrá-los em 15 minutos e esse é um bom teste de tornassol 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:

ajuste de desempenho em sql server passo a passo

• As reuniões diárias não são eficientes. As pessoas estão entrando em muitos detalhes. Ou não há uma ordem clara para falar e leva tempo para os companheiros falarem. Talvez o product owner ou 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 ser que você simplesmente tenha muitas pessoas na equipe. Você também deve começar a notar que as pessoas estão perdendo o interesse porque há um limite para a quantidade de informações que uma pessoa pode absorver. Se muitas pessoas estiverem fornecendo atualizações, será difícil acompanhar o progresso de todos e ter uma compreensão do status da equipe . Isso faz com que as pessoas se voltem para si mesmas e reflitam apenas sobre seu progresso, em vez de procurar oportunidades para ajudar os outros.

Grooming e Sprint Planning

Tanto o grooming quanto o sprint planning são atividades relacionadas à análise de histórias de usuários e à estimativa de seu tempo ou tamanho de entrega. Embora ter mais pessoas possa ajudar a equipe a tomar decisões melhores, 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.

Tal como acontece com a reunião diária, não confunda uma sessão de planejamento ineficiente com a equipe ser muito grande. Em última análise, é função do mestre do scrum fazer com que as cerimônias do scrum sejam eficientes e eficazes.

Retrospectivo

Durante uma retrospectiva, os membros da equipe podem resolver quaisquer argumentos 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 as diferentes partes. Uma equipe é tão poderosa quanto seus membros estão dispostos a comprometer suas diferenças.

No entanto, como acontece com o planejamento de sprint, muitos membros da equipe criam muitos links, todos os quais são potenciais pontos de conflito. Comece percebendo 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

Aparentemente, 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 serem consideradas que podem ter um grande impacto no sucesso futuro das novas equipes.

Moral da Equipe

Provavelmente, uma das coisas mais importantes a se ter em mente é o moral da equipe. No final do dia, são as pessoas da equipe que terão que trabalhar na nova composição. Se a equipe estiver madura em termos de princípios do Agile, 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 por estar em equipes separadas.

Equipes multifuncionais

O Scrum promove equipes multifuncionais “com todas as habilidades de equipe necessárias para criar um incremento de produto”. Isso é válido 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 desejam se dividir em equipes de back-end e front-end. Isso pode fazer sentido em algumas ocasiões raras, mas como um gerente de produto , você deve desaconselhar isso na maioria das vezes. Uma equipe cheia de front-enders não consegue entregar sozinha um incremento de produto e vai 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 um especialista em QA. Depois de dividir uma equipe, especialmente se não estiver contratando muitas pessoas novas, surge um dilema sobre o que fazer com essas funções. Eles deveriam dividir seu tempo entre as equipes? Você deveria contratar novas pessoas, que seriam dedicadas a apenas uma equipe? Eles devem trabalhar com as equipes de desenvolvimento ou fazer parte da equipe de produto?

Na verdade, não há um bom conselho único para isso, porque cada produto é muito diferente. É melhor tomar essas decisões em conjunto com a equipe, tendo em mente que pode ser necessário corrigir o curso ao longo do caminho.

As equipes devem ter pendências separadas?

Se uma equipe for dividida, a questão natural é se eles deveriam trabalhar com a mesma carteira de pedidos ou ter outras separadas. Podemos olhar para o Framework Agile escalado para orientação.

[email protegido]

[email protegido] é uma metodologia desenvolvida pelo criador do Guia Scrum. [email protegido] não é muito prescritivo e não descreve especificamente como lidar com as pendências do produto. No entanto, nota dois pontos:

como contornar o código CVV

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

Então, em essência, [email protegido] imagens das novas equipes com seus respectivos POs e backlogs. Ele apenas adiciona algumas estruturas adicionais para coordenar o trabalho entre as equipes. [email protegido] 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 larga escala (LeSS)

Menos promove uma abordagem interessante para o backlog do produto. No LeSS, um product owner 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 da lista de pendências do produto para as equipes. Nesse caso, as equipes de desenvolvimento multifuncionais 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 às perguntas.

Priorizar reuniões

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

Sua participação nas sessões de planejamento de sprint dependerá da maturidade das equipes. Se as equipes incluem muitas caras novas ou não trabalham com o Agile há muito tempo, alguma orientação de sua parte será necessária. Mesmo se você se sentir confiante em permitir que a equipe planeje sem a sua presença, certifique-se de estar disponível para entrar ou bater um papo por voz com a equipe durante os planejamentos, se houver alguma dúvida.

As revisões do Sprint deverão continuar sendo sua prioridade e todas devem ser atendidas. As revisões do Sprint são uma chance de obter feedback em primeira mão de todos os stakeholders presentes e da própria equipe. É um momento em que as suposições são validadas e não deve ser esquecido.

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 junto com todos eles.

Certifique-se de que você pode confiar neles para dar 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 de scrum.

Apresente Scrum of Scrums

Às vezes chamado de meta scrum, um scrum de scrums é uma nova cerimônia que normalmente é apresentada como escala de processos de 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 de scrums todos os dias para discutir o progresso e os impedimentos. Essa cerimônia também é usada para destacar quaisquer problemas técnicos entre as equipes que possam precisar ser resolvidos.

Considere expandir a equipe de produto

Se sua configuração de scrum requer 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, ao mesmo tempo que adiciona gerentes de produto juniores para lidar com algumas das tarefas diárias. Eles podem realizar algumas tarefas como garantia de qualidade (QA), escrever especificações para histórias de usuários ou criar modelos de alto nível para novos recursos.

Analistas de negócios. Outra forma é ter um ou mais analistas de negócios trabalhando nas equipes ou junto com elas. O gerente de produto pode trabalhar com analistas de negócios para identificar as premissas do produto e, então, permitir que os analistas de negócios encontrem maneiras de validá-las por meio de pesquisas ou novos recursos.

Conclusão

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

• Reunião diária. Se você ultrapassar o prazo de 15 minutos durante as reuniões diárias e perceber que as pessoas começam a perder o interesse.
• Planejamento de sprint. Se você acabar em impasses durante o planejamento do sprint, cada vez com mais frequência.
• Retrospectivo. Se você começar a perceber que está ficando mais difícil chegar a um acordo durante as retrospectivas.

Tudo isso aponta para o fato de que pode ser necessário 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 fazer isso:

• 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 único.

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 reuniões. Pense em quais cerimônias do Agile valem seu tempo e quais podem ser ignoradas.
• Envolva-se com os scrum masters. Use scrum masters como proxies de sua equipe e reúna informações deles.
• Expanda a equipe de produto. Adicione pessoas para trabalhar com você e ajudá-lo em tarefas repetitivas diárias ou conduzir pesquisas de usuários e análises de mercado.

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

Compreender o básico

Quantos desenvolvedores há em uma equipe scrum?

De acordo com o Guia Scrum, a equipe de desenvolvimento deve ter entre três e nove pessoas e deve ter todas as habilidades necessárias para entregar incrementos de produto. O número de desenvolvedores geralmente é ditado pelas necessidades do produto e geralmente fica entre dois e cinco desenvolvedores em uma equipe scrum.

Quem são os membros de uma equipe scrum?

Uma equipe scrum é multifuncional e inclui todas as pessoas necessárias para entregar um incremento de produto. A maioria das equipes scrum terá um product owner e um scrum master dedicados. O resto da equipe pode incluir desenvolvedores, designers, testadores ou analistas.

O que é uma boa equipe scrum?

Uma boa equipe scrum é multifuncional com todas as habilidades necessárias para criar um incremento de produto. Deve incluir desenvolvedores, designers, testadores, analistas, etc.

Qual é o tamanho recomendado para uma equipe scrum?

O Guia do Scrum recomenda ter de três a nove membros da equipe em uma única equipe.