Fórum de discussão

Empirismo afirma que o conhecimento vem da experiência e da tomada de decisões baseadas no que é conhecido.

A existência de mais de nove membros requer muita coordenação. Grandes equipas de desenvolvimento geram demasiada complexidade para um processo empírico de gestão

O guia Scrum cita aquelas questões de estar presente em equipas com mais de 9 membros. Estas são preocupações, não pontos de falha, e uma equipe Scrum com mais de 15 membros pode trabalhar. No entanto, não será tão eficaz como uma equipe de tamanho apropriado. O ideal seria separá-los em duas equipes, e seguir o Guia Nexus para escalar o Scrum para várias equipes. Esse é o método Scrum.org para escalar o Scrum. Você também poderia olhar para SAFe, como um segundo método para escalonamento ágil.

O maior problema que você vai encontrar provavelmente não é o trabalho, mas os eventos. Manter um tempo de Scrum diário encaixotado para 15 minutos pode ser um desafio com 7 pessoas, e dobrar o tamanho da equipe torna-o muito mais difícil. Expandir a caixa de tempo é um “não” (após 15 minutos, você começa a perder os benefícios de uma reunião de “levantar”), e você vai ter que se preparar melhor para os outros eventos esclarecendo as coisas com antecedência.

Como eu entendo, seu trabalho como um Scrum Master neste cenário fica mais difícil, mas não impossível. Você pode ter um Scrum Team de 15 homens, mas como os eventos são baseados na duração do sprint e não no tamanho da equipe, você se encontrará menos no papel de servo e mais no papel de líder. Você precisa colocar um foco extra para garantir que as coisas sejam feitas de forma eficiente, porque você tem menos espaço (e menos tempo) na sua agenda como margem de erro. Alguém a sair numa tangente vai ter um impacto mais profundo numa equipa grande do que numa pequena.