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! 🙂

Publicidade