Hoy vamos a hablar del tamaño del equipo. Sí, no es la primera vez que te hablo de ello, de los efectos de equipos grandes, etc. Pero hoy quiero irme a los estudios, a los libros y dejarte las principales referencias sobre ello.
En nada, tampoco en agilidad, hay reglas inamovibles, hay guías, principios, valores, buenas prácticas, pero sobre todo lo anterior, debes experimentar. Lo mismo aplica al tamaño del equipo. No obstante, ello no quita que haya quien necesite de estudios, referencias, datos que le den seguridad de qué hay detrás de una recomendación, y por ahí va este post.
En este caso, y en esta línea, hoy te quiero dejar los principales trabajos que nos llevaron a por qué hoy comúnmente asumimos el número 9 como el máximo recomendable para un equipo.
Putnam
La «madre» de todos los estudios sobre el tamaño de un equipo es el de Lawrence Putnam, que te detallé hace años en Por qué los equipos con mucha gente (más de 7) son menos productivos. O por qué tener equipos pequeños es una buena práctica (ágil, además) (año 2013).
Putnam, desconocido para mucha gente, pero cuyos trabajos han sido tremendamente determinantes en todo esto del tamaño de los equipos (y por eso estaba obligado a citarlo el primero), elaboró hace unos años una investigación al respecto, que inspiró a frameworks ágiles como Scrum, en lo que refiere al número de personas.
Putnam revisó 491 «proyectos» software, sus resultados evidenciaron algo que mucha gente sospechaba: cuando el tamaño del equipo crecía más allá de un número de personas el esfuerzo dedicado, lógicamente, al haber más gente, aumentaba pero el tiempo de proyecto no se reducía en la misma línea. Equipos más allá del rango de entre 5 y 7 personas aumentaban en esfuerzo… pero no reducían tiempos en la misma línea.
Y, ponía el famoso número 9 en escena, el 9 como máximo número de personas, ya que cuando se superaba era cuando realmente empezaban de manera significativa los problemas.
Jeff Sutherland
Cuando pude estar unos días en Estocolmo con Jeff Sutherland (co-autor de Scrum), el nos dio la regla del 7 más menos 2 como tamaño ideal para un equipo y nos citó el estudio de Putnam. Por cierto, que de aquella estancia que hice en Estocolmo con Sutherland salió aquella Entrevista que pude hacer a Jeff Sutherland, que te recomiendo leer.
En relación a lo anterior, Sutherland en su Scrum: The Art of Doing Twice the Work in Half the Time escribía lo siguiente, lo dejo literal:
“The classic formulation is seven people, plus or minus two, though I’ve seen teams as small as three function at a high level. What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right. More resources make the team go slower.”
Supongo que no necesita traducción, sino te resumo… pon en 9 el tope.
Jeff Sutherland y Ken Schwaber
Aprovechando que citaba antes a Sutherland… ¿qué dice del tamaño la Guía de Scrum? de la que Jeff Sutherland y Ken Schwaber son autores. Pues dice, literalmente esto..
«Fewer than three Development Team members decrease interaction and results in smaller productivity gains. […]. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.»
De nuevo, cómo no, la cifra de 9 como máximo.
Steve McConnell
Si eres lector de este blog desde hace tiempo, sabrás de Steve McConnell y mi admiración por sus libros, que decir de alguien que escribió el Code Complete, probablemte el libro de ingeniería software más vendido.
A lo que vamos. De sus libros, el que más me gusta es el Rapid Development, y yendo a nuestro tema, en el libro se citan varios estudios (páginas 287 y 288), comenta:
«Some experts say that you must have fewer than 8 to 10 people for a team to jell (Emery and Emery 1975, Bayer and Highsrriith 1994). If you can keep the group to that size, do so, If your project requires you to have more than 10 project members, try to break the project into multiple teams, each of which has 10 or fewer members.»
Por si te quieres meter más, yo ya no voy a extender mucho más el post, referencia dos estudios más: Emery and Emery del 75 y Bayer and Highsrriith del 94.
En este caso, 10 es el tope recomendado.
Mike Cohn
En Succeeding with Agile: Software Development Using Scrum, Mike Cohn, en el capítulo 10 trata este tema del tamaño del equipo, y cita, como casi todo el mundo, el obligado estudio de Putnam, y la regla de las 2 pizzas: si con dos pizzas o puedes dar de comer a tu equipo es que hay mucha gente.
El caso, aparte de tratar varios estudios, resume, de nuevo, que el tope ideal es 9 personas.
Terminando
Hay n estudios más, pero, en mi opinión, los anteriores son los más destacados, y creo que suficientes, para concluir con que 9 personas como máximo es lo más recomendado. Eso por el máximo, 9, porque en lo que refiere al número mínimo, lee… ¿Cuál es el número mínimo de personas óptimo para un equipo?,
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024