O guia definitivo do tamanho ideal de um Time Scrum

Tenho entrado em algumas discussões sobre o tamanho ideal para um time de desenvolvimento e encontrei opiniões bastante diversificadas. Por isso, deixarei meus dois centavos de contribuição para este tema tão controverso.

Existe a corrente das pessoas que defendem o que o Scrum Guide recomenda sobre o assunto. Então, vamos analisar o que ele diz:

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint.

A observação seguinte traz bastante controvérsia:

Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar.

Decorrente deste trecho do Scrum Guide, algumas pessoas interpretam que o framework diz que o tamanho ideal de um time varia entre 3 e 9 membros, sem contar o Scrum Master e o Product Owner (a menos que eles também executem trabalho de itens do backlog da sprint). Esta interpretação leva a impressão de que o Scrum Guide prescreve um tamanho para o Time Scrum.

Particularmente, prefiro acreditar que a primeira parte faz uma recomendação e a segunda dá um exemplo das consequências de um time ser muito pequeno ou muito grande.

Tenho lido histórias de colegas agilistas que ótimos resultados com times fora dos parâmetros desta recomendação; outros, nem tanto. Isso nos leva àquela típica resposta de consultor:

Depende!

E, sim, acredito que cada sistema é único, com seus desafios em particular. Assim, a quantidade de membros que funcionará para determinado ecossistema vai depender justamente do meio ambiente no qual ele está inserido.

Obviamente as observações do Scrum Guide são muito pertinentes.

Num time menor, com duas, três pessoas, é muito mais difícil ter o benefício de técnicas como o pair programming (que não são prescritas pelo Scrum Guide, mas podem ser aplicadas para aumentar a produtividade e disseminar conhecimento). Imagine um time de duas pessoas, onde a dupla decide fazer o pair programming. Neste tempo, é possível que não consigam equilibrar todos os pratos e algum acabe caindo.

Também torna-se muito difícil fazer um brainstorm de ideias, pelo número reduzido de pessoas envolvidas em um problema. Sou um defensor da ideia de que o ambiente deve ser o mais diverso possível, mesmo que isso signifique deixar o Agile Coach completamente maluco administrando conflitos… 🙂

Na minha experiência, o maior desafio é trabalhar com times muito reduzidos. Uma pessoa não é time, duas pessoas formam uma dupla. Sendo Agile Coach, é muito mais desafiador fazer ideias emergirem do time sem dar uma pitada de opinião pessoal nestas formações.

Já gosto mais de trabalhar com times maiores, até por que gosto de ter um time bastante diverso. Mas também é bastante desafiador, pois a quantidade de ideias e humores a administrar é maior.

Independente da minha experiência ou opinião pessoal sobre o tema, recomendo fortemente que você experimente tamanhos diferentes de times. A recomendação do Scrum Guide deve ser considerada, sim, mas cada caso é um caso e deve ser analisado com todas as suas nuances.

A mensagem que deixo é: leia o Scrum Guide, mas não o trate como um livro prescritivo, cheio de dogmas. A ideia não é essa. A ideia é emergir o que funciona melhor para a sua realidade, seja neste tema ou qualquer outro relacionado ao desenvolvimento ágil.

Afaste-se de conceitos “definitivos” e “ideais”. Invente, tente! Experimente! 🙂

Anúncios

Marcelo L. Barros

Olá! Sou um cara criativo, curioso e detalhista, que, cada dia, mais se vê interessado em desvendar os mistérios desse "bicho gente"! Comecei minha carreira profissional em 1996, sou formado em Processamento de Dados pela FATEC de Santos. Naquela época tudo o que eu queria ter na minha frente era um computador e uma desafiadora regra de negócio, que se transformaria no melhor programa possível. Mas as coisas mudam! Concluí que quem faz software com qualidade são as pessoas e não as máquinas. Hoje, minha MISSÃO é ajudar pessoas e times a alcançarem seus objetivos, pois acredito que o sucesso pessoal e profissional está ligado a três pilares: FELICIDADE, MOTIVAÇÃO e SENTIDO. Como faço isso? 💡 MOTIVANDO pessoas, fazendo-as enxergar o 💡 SENTIDO das suas ações, que traz 💡 FELICIDADE por fazerem a diferença em suas vidas, suas empresas. Sou formado em Coaching pelo ICC e escrevo artigos sobre Métodos Ágeis, Comportamento, Inovação e Coaching. Vejo no lúdico a forma mais profunda de aprendizado. Procuro sempre conduzir reuniões de forma criativa, que tragam algum tipo de aprendizado aos participantes, seja por meio de dinâmicas de grupo ou jogos em equipe. Neste quesito, desenvolvi um jogo, a "Feijoada Ágil", para ensinar conceitos sobre trabalho em equipe. Se você, como eu, também acredita que eu posso te ajudar, deixe-me saber! Vamos tomar um café e, quem sabe, juntos podemos MUDAR O MUNDO!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s