En estos tiempos en los que parece que ha calado, al menos la idea, la ejecución ya es otra cosa, de tener equipos de trabajo potentes, de alto rendimiento para algunos, altamente productivos para otros, ágiles, etc., como quieras llamarlo, sabes a lo que me refiero, hay varias palabras que siempre suelen salir cuando se toca este tema.
Palabras como multifuncionalidad, auto-organización y tamaño ideal del equipo, atributos que suelen asociarse a lo que se ha dado en llamar equipo ágil.
Hoy quería profundizar contigo en el tamaño, pero en el mínimo. Creo que está ya más o menos interiorizado que el tamaño, en número de personas, influye en la productividad, y otras cosas, que a más personas más canales de comunicación, más pérdidas en coordinación, etc. En su día ya le dediqué un post a este punto, por qué los equipos con mucha gente (más de 7) son menos productivos, todos tenemos en la cabeza el umbral “menos de 10 personas”, pero… ¿y el mínimo?
En la propia guía de Scrum, cuando habla del tamaño del equipo, podemos encontrar lo siguiente, que te resumo yo extrayendo de la misma: Con menos de tres miembros, disminuye interacción y las ganancias en productividad son pequeñas, limitando las entregas de incrementos. La guía, obviamente, también habla del tamaño máximo, que lo pone en 9. Y cuando pude estar unos días en Estocolmo con Jeff Sthuerland, co-autor de Scrum, el nos dio la regla del 7 más menos 2 como tamaño ideal para un equipo.
Según lo anterior, la recomendación es 3 mínimo, o 5 personas mínimo.
Pero este tema se ha tratado muchas más veces, no sólo en la guía de Scrum.
Putnam, en su famoso estudio que puedes encontrar en el post que te referencié antes, y que también se tomó como referencia en ciertos ámbitos ágiles, ponía el mínimo ideal en 5.
Otro sitio interesante donde encontrar información sobre “el mínimo ideal” es en popular Rapid Development de Steve McConnell. En el libro se citan varios estudios (puedes verlos por allá por la página 287 y 288), con ya sus años, y recomienda como número mínimo 8 personas. Según se argumenta, con menos de 8 personas puede que el grupo de personas no llegue a tener sensación de ser un equipo, identidad de grupo, y que si no hay un número mínimo de personas pueden dominar las relaciones interpersonales más allá de la responsabilidad y sentido de equipo.
Otra fuente digna de mencionar es el «Succeding with Agile» de Mike Cohn. En el capítulo 10 trata este tema del tamaño del equipo, cita los estudios de antes, el obligado de Putnam, la regla de las 2 pizzas (si con dos pizzas o puedes dar de comer a tu equipo es que hay mucha gente), etc. Y, aparte de las mencionadas, da la cifra de mínimo 4.
En lo que refiere al máximo prácticamente todo el mundo coincide en el 9 como máximo. En lo que refiere al mínimo hay más variación, pero 3 o menos personas ya parece un número difícil como para poder lograr una identidad de equipo y mostrar incrementos significativos.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola a tod@s! Mi experiencia en un equipo de 3 personas (donde una de ellas es el scrum master) es que aunque a simple vista pudiera parecer lo contrario, se hace más complicado/forzado el uso de scrum, en nuestro caso. La daily meeting deja de ser «daily» por ser repetitiva, ya que conocemos lo que hacen las otras dos personas casi en tiempo real. La review y retrospective se hacen muy cortas, con lo que aparentemente pueden ir perdiendo importancia. Por otro lado, el avance no es todo lo rápido esperado, ya que las entregas suelen ser pequeñas, si todo va bien, 2 o 3 historias de usuario. Además, las tareas muy técnicas como la arquitectura o la implementación de BDD las asume el equipo, por lo que puede verse reducida la velocidad aún más. También se ve afectado el punto creativo en la resolución de problemas, ya que hay menos personas que puedan aportar o dar su punto de vista. Seguramente, pensándolo durante un rato más, identificaríamos otros temas, pero estos resaltan en nuestro día a día. Salu2!
Javier donde indicas la frase «si con dos pizzas o puedes dar de comer a tu equipo es que hay mucha gente» tienes un error. Te recomiendo corregir ya que puede dar una idea distinta a la original. Saludos.
OK
Como cuarto miembro que entró a un equipo de 3 (que después se quedó en 3, contándome a mí). Con 3, dos full stack y un backend, se quedaban cortos en tiempos de entrega y había demasiado agobio para tener ideas felices. Con 4 íbamos bien, mantenimiento en back y self training en front (innovando layout mientras aprendía el framework). Aumenta la motivación del equipo porque ven ideas nuevas aprovechables + descarga de trabajo a los demás miembros = surgen ideas en todos.
Después quedamos 3 full stack y el cuarto contaba moscas (cuando llegaba a las 12:30 de la pisci), lo cual fue desmotivando uno a uno a todos los miembros, porque además el backend developer era el que tenía idea de la parte de negocio, los demás no al nivel deseable.
Esa fue la mejor y más productiva experiencia. 3 full stack y un backend con nociones de negocio. Total : 4.
PS: Se intentó ampliar la parte front con 2 más, pero no tenían ganas de aprender. Si hubiese salido creo que habría sido muy bueno. Dejas a dos sólo con front, uno solo con back + negocio, un full stack, dos en back (con nociones de front) profundizando negocio. Y produces a ritmo adecuado mientras mejoras competencias.