Foro Scrum

El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones basada en lo que se conoce.

Tener más de nueve miembros requiere demasiada coordinación. Los equipos de desarrollo grandes generan demasiada complejidad para que un proceso empírico pueda gestionarla

La guía de Scrum cita esos problemas con estar presente en equipos de más de 9 miembros. Estas son preocupaciones, no puntos de falla, y un equipo de Scrum de más de 15 miembros puede funcionar. Sin embargo, no será tan eficaz como un equipo de tamaño adecuado. Lo ideal sería separarlos en dos equipos, y seguir la Guía Nexus para escalar Scrum a varios equipos. Ese es el método de Scrum.org para escalar Scrum. También podría buscar en SAFe, como un segundo método para el escalamiento ágil.

El mayor problema que encontrará probablemente no es el trabajo, sino los eventos. Mantener la caja de tiempo de un Scrum Diario a 15 minutos puede ser un reto con 7 personas, y duplicar el tamaño del equipo lo hace mucho más difícil. La ampliación de la caja de tiempo es un no-go (después de 15 minutos, se empieza a perder los beneficios de una reunión «stand up»), y vas a tener que preparar mejor los otros eventos aclarando las cosas de antemano.

Según entiendo, tu trabajo como Scrum Master en este escenario se hace más difícil, pero no imposible. Puedes tener un equipo Scrum de 15 personas, pero como los eventos se basan en la duración del sprint y no en el tamaño del equipo, te encontrarás menos en el papel de servidor y más en el de líder. Tienes que poner un enfoque adicional en asegurarse de que las cosas se hacen de manera eficiente, porque tienes menos espacio (y menos tiempo) en tu horario como un margen de error. Que alguien se salga por la tangente va a tener un impacto más profundo en un equipo grande que en uno pequeño.