Mucho se ha leído y se ha hablado sobre el tamaño de los equipos en Scrum, Agile, etc. Sabemos perfectamente, a modo de introducción y repaso, que un equipo Scrum debería de ser multidisciplinar, por definición. Es decir, todos los roles necesarios incluidos en él equipo, para hacer un Incremento de Producto válido al final de cada Sprint. Hasta ahí todo correcto. Ese es el equipo óptimo Scrum para ser productivo y autónomo. Ese es el punto de partida de todo equipo Scrum.
La guía de Scrum dice, que el tamaño óptimo de equipo, es entorno a 7 más / menos 2 personas. En resumidas cuentas, los equipos deberían de tener entre 5 y 9 personas. Pueden darse casos de equipos de 3-4 personas, perfecto. Más adelante en el artículo veremos que aporta dicho tamaño. Pero lo que queda bien claro es que nunca un equipo ha de tener más de 9 miembros. ¿Porqué?
Ya en 1983, Ikujiro Nonaka e Hirotaka Takeuchi formulan dichas afirmaciones tras realizar investigaciones y nuevos productos en empresas tecnológicas tales como Juji-Xerox, Canon, Honda, Epson, Brother, 3M, Hewllet-Packard. En dichos estudios, y posteriormente mediante Jeff Sutherland y Ken Schwaber al crear Scrum se llega a afirmar y demostrar que dichos equipos creados en torno a 7 más / menos 2 miembros generan un nivel de productividad media de un 300-400 % más que un equipo normal, un 500% si se llega a desarrollar un equipo élite o gran equipo.
Un equipo pequeño, 3-4 personas no realiza mucha interferencia, puede ser muy autónomo con unas directrices y un foco bien definido, estando físicamente en el mismo espacio, el trabajo es coherente, responsable, alineado, sin "pisarse", bien focalizado y con una comunicación fluida. Todo resulta fácil con pocos individuos en el equipo. El problema aparece al incrementar el número de miembros del equipo.
La Ley de Brooks postula que "añadir personal a un proyecto de software que va retrasado lo retrasa todavía más". Se podría incluso estimar en qué cuantía o porcentaje consigue retrasar el proyecto, pero está claro que lo retrasa, sin más. Hay que formar a esa persona en el producto o tecnología, y tendrá que aprender un conocimiento no técnico, si no ya funcional, y táctico sobre dicho producto o software.
Según grandes estudios, realizados por grandes personalidades como Lawrence Putnam, un equipo pequeño (menor de 9 personas), requiere un 25% menos de esfuerzo que uno grande para realizar el mismo producto (entre 9 y 15 personas), lo que repercute entre un 15-20 % de productividad por miembro de equipo, si calculamos una media sencilla nos restaría entre un 150-200% de productividad en el equipo.
En resumen, si con un equipo óptimo podemos llegar a tener un 300-400 % de productividad. Y por cualquier circunstancia le añadimos más gente (superando la frontera de los 9 miembros) conseguiremos que reste una productividad entre 150-200%. 300-400% - 150-200% = misma productividad máxima que con un equipo de 9 o menos miembros. Y se dice productividad máxima, lo que indica que por regla general serás menos productivo, tu producto será más caro (más miembros de equipo más coste) y se alargará en el tiempo al ser menos productivo.
Finalmente, para no extenderme más y concluir, en 1956 George Miller afirmaba y demostraba que el número máximo de relaciones e ítems que una persona puede retener en su memoria a corto plazo es de 7. Posteriormente en 2001, Nelson Cowan, demostró que Miller estaba equivocado y había sido muy ambicioso, demostró que tan solo era de 4. Con esta afirmación queda claro que entre 4 y 7 tendremos buenos resultados, todo lo que sea intentar ir más allá, estaremos impactando en productividad de equipo, y por tanto en costes y plazos.
De esta manera, ahora está muy de actualidad un término llamado "Descale" o lo que es lo mismo des-escalar. Si aplicamos los mismos principios, estudios, métricas que se han enumerado en el resto del artículo, obtenemos que un escalado de equipos de entre 4-5 equipos de 7-9 personas máximo estaríamos realizando un producto quizás con un 200-300% más de productividad que realizándolo sin Scrum. Esto nos puede dar una media de una línea de desarrollo para un producto de 50 personas, no de 150 o 200 personas. Que por cierto, tendría como máximo la misma productividad que equipos bien escalados con Scrum y de máximo 50 miembros.
