Etiqueta: desarrollo

Mucho se ha hablado sobre el tamaño del equipo Scrum, Agile y casi cada cliente, jefe y colaborador con los que he trabajado hacen esta pregunta en algún momento ¿cuántas personas incluimos en los equipos?. La Guía Scrum ofrece muy poco luz al respecto, sugiriendo 10 o menos miembros por equipo en su última actualización, pero sin darnos contexto o razones para estos números.

El Tamaño del Equipo Scrum no es Sólo un Número

La verdad es que no existe un número universalmente correcto para asegurar un óptimo rendimiento en un equipo, pero sí sabemos que un equipo Scrum debe considerar ciertos factores que debería incluir, más allá de lo números:

• Equipo multifuncional. Habilidades y capacidades suficientes para construir el producto,
• Miembros dedicados al equipo. Miembros dedicados a uno, y sólo un, equipo,
• Miembros estables. Membresía consistente y de largo plazo dentro del equipo^[1],
• Diversidad de pensamiento. Un suficientemente amplio rango de actitudes, creencias, generos y patrones de pensamiento^[2].

Ahora bien, los puntos anteriores ya por sí mismos representan reto para algunas organizaciones, pero al menos gozan de un consenso importante, sin embargo, no son las únicos. Una vez que el equipo está formado, hay otros factores importantes que deben atacar los equipos de alto rendimiento, entre otros se pueden mencionar:

• Seguridad psicológica. Ambiente seguro para compartir ideas y tomar riesgos^[3].
• Comunicación igualitaria. El miembro más expresivo no debería comunicar más del doble de información que el más callado^[4].
• Mente abierta y disponibilidad para aprender^[5].
• Visión compartida. Todos conocen y acuerdan objetivos^[6].
• Roles claros. Todos conocen sus responsabilidades y las espectativas de su labor^[7].
• Asesoramiento externo (coaching). En Scrum esto lo lleva a cabo el Scrum Master^[8].

¿Y todo esto que tiene que ver con el tamaño de los equipos? Bueno, estos factores no viven aislados en el vacío y sólo porque yo lo digo, así que exploremos la evidencia para que juntos descubramos que es lo más importante para su equipo. Después de todo, no hay una respuesta universal 🙂

Muchos Números por Todos Lados

Cuando hablamos del tamaño de los equipos a los adentros de varias organizaciones, el tema parece mucho más controversial y poco acotado por decir lo menos. En el peor de los casos, los líderez encargados de asignación de personal responden armando equipos guiados por supuestos e incluso en función del agobio causado por fechas y presupuestos poco realistas y de horizontes inadecuados, perjudicando así al rendimiento de equipos y la misma organización a mediano y largo plazo.

En lo días tempranos del agilismo, los textos XP y Scrum sugerían que el tamaño óptimo de miembros era 7±2, aplicando el número de George A. Miller, posteriormente se ajustó a 6±3, hoy en dia el número sugeridos es 10 o menos de acuerdo con la Guía Scrum.

El sustento original para la postura de siete personas, más o menos dos (7±2), proviene de una investigación de psicología muy nombrada del psicólogo investigador George A. Miller publicada en los años 50s, donde según los resultados de este estudio, hay límites en la cantidad de información que podemos procesar y retener en nuestras cabezas.

Más recientemente en 2010, Nelson Cowan afirmó que Miller era demasiado ambicioso y que el límite ideal era solo de cuatro y no de de siete^[9].

También, Ikujiro Nonaka y Hirotaka Takeuchi estaban formulando el tamaño ideal del equipo después de realizar investigaciones y crear nuevos productos en compañías de tecnología como Fuji-Xerox, Canon, Honda, Epson, Brother, 3M y Hewlett-Packard^[10] .

Muchos otros citan ejemplos históricos que se remontan al ejército romano, que utilizaba pequeñas unidades militares de alrededor de 8 personas. Otros observan a los bonobos, uno de los parientes genéticos más cercanos a los humanos, a menudo divididos en grupos de 6 a 7 para buscar alimento durante un día. Ambos admiten convenientemente el número 7±2, pero dado que ninguno de los ejemplos se trata de equipos que realizan trabajo de conocimiento, la relevancia de esto para el agilismo es limitada.

Como puede ver el tema ya tiene tiempo discutiéndose y puede ser algo confuso, pero gracias a ello tenemos algunas pistas, pero vale la pena tener más fuentes que nos ayuden a sustentar nuestra desición.

¿Qué Pasa a las Relaciones Cuando los Equipos Crecen?

A los adentros de un equipo, cada individuo tendrá conexión con otro individuo creando con ello un relación única; entre más grande el equipo, más relaciones. La ecuación que describe esto es N(N-1)/2; pero ¿qué significa esto? y ¿cómo puede ayudarnos? para averiguarlo recordemos problemas de matémáticas de escuela y convirtámoslo en algo que podamos usar en la vida real.

La ecuación anterior nos dice cuántas relaciones diferentes existirán dentro de un equipo de cierto tamaño, siendo N = el número de personas en el equipo. Entonces, en el primer gráfico ejemplo de un equipo de 5 personas, donde N=5 tenemos 10 relaciones: 10 combinaciones diferentes de miembros del equipo que se relacionan con otros miembros del mismo equipo.

En el segundo ejemplo, donde N=7, tiene 21 relaciones y en donde N=9 en el tercer gráfico tienen 36 relaciones. Cada par de personas representa una relación, y esa relación define la forma en que colaboran. Los equipos de alto rendimiento, por su naturaleza, deben tener relaciones sólidas entre cada uno de los miembros del equipo para colaborar de manera efectiva.

Saber esto es importantes para usted y su equipo, porque es cierto que cada nueva persona agrega algo de productividad individual al equipo, pero también aumenta los gastos generales de comunicación en forma de un número de relaciones que crece exponencialmente. Para aumentar un equipo de 5 a 7 personas, hay que duplicar con creces el número de relaciones. Para pasar de 7 a 9, no se duplica del todo, pero el salto sigue siendo grande.

¿Qué tan costoso es mantener estas relaciones? Como anécdota, después de haber estudiado las interacciones de los miembros de varios de mis equipos, puedo decir que en equipos de 7 u 8 personas, cada día se dedican más de 90 minutos por persona a interactuar con otros miembros del equipo^[11]. Esto excluye el tiempo dedicado a técnicas como pair programming. Parte de la interacción es hablar sobre el trabajo, pero también se dedica a socializar. Esto es bueno e importante porque es la combinación de trabajo y socialización lo que desarrolla la resiliencia y la capacidad de un equipo para manejar los desafíos de manera efectiva.

Una regla general sugiere que las personas suelen tener de 3½ a 5 horas de tiempo productivo en el trabajo cada día. A medida que un equipo crece, perdemos productividad o, más a menudo, comenzamos a retraernos socialmente en lugar de sacrificar tiempo productivo para interactuar con nuestros compañeros porque los costos de comunicación para cada miembro del equipo se están volviendo demasiado altos. Necesitamos relaciones sólidas para convertirnos en un equipo de alto rendimiento pero, a medida que crece el tamaño del grupo, comenzamos a evitar las interacciones que construyen esas relaciones.

Por lo tanto, la cantidad de relaciones entre los miembros del equipo y la inversión de tiempo que requieren deben ser un factor considerado al elegir el tamaño del equipo porque influirá en la productividad.

Más Personas Hacen el Trabajo Más Ligero… Pero Solo Hasta Cierto Punto

Lo que todos quieren creer es que si vamos de 1 persona a 2 personas, o de 2 personas a 4 personas, obtendremos el doble de trabajo realizado, incluso altos directivos de organizaciones transnacionales me lo han planteado. Pero incluso así, intuitivamente sabemos que esto no es verdad, pero ¿por qué?

En 1967 se presentó por primera vez la Ley de Amdahl, que para los que no sean ingenieros en sistemas o electrónica, trata de estimar cuanta ganancia de velocidad se puede obtener ejecutando tareas de computo corriédolas en partes de manera paralela. Esto significa que a veces hay programas de cómputo que son viables de trabajarse por múltiples procesadores al mismo tiempo (ej. procesamiento paralelo), pero otras partes deben ser atendidas una por una (ej. programación serial).

La fórmula que se deriva de la Ley de Amdahl pude parecer intimidante, pero es mucho más simple de lo que parece:

Esta imagen plantea trabajo realizado por un procesador el cual le toma 5 unidades de tiempo para completar.

Si tomamos las 5 unidades de trabajo y aplicamos 3 procesadores a las partes que se pueden hacer concurrentemente (en paralelo), no se necesitan 1 y 2/3 unidades de tiempo (5 dividido por 3) para completarse. En cambio, se necesitan 3 unidades porque 2 de las unidades de trabajo solo pueden ser realizadas por un procesador (serie). Ciertamente es una mejora en el tiempo, pero no tanto como cabría esperar al primer vistazo.

El trabajo en equipos funciona de manera muy similar. De hecho, si con convertimos todo a un gráfico podemos darnos idea de que tan eficiente puede ser el incremento en miembros de un equipo:

Enfoquémonos por ahora en la línea del 80% (la azul, en la parte superior) del gráfico. Seamos optimistas (y poco realistas) y supongamos que el 80% del trabajo se puede hacer trabajando en paralelo. Esto sugiere que cuanta más gente lo haga, más rápido se terminará, ¿cierto? Ah, pero espera. Si pasamos de 1 persona a 2 personas, no hacemos el doble de trabajo. Para obtener una mejora de 2 veces el trabajo completado, en realidad necesitamos 3 personas. 7 personas sólo crean una mejora de 3.2 veces sobre 1 persona. Para hacer 4 veces más trabajo del que hace 1 persona, ¡necesitaríamos 16 personas!

¿Qué sucede si se puede hacer incluso menos trabajo al mismo tiempo (paralelo)? ¿Qué pasa si el 50% del trabajo debe hacerse en serie (línea verde en el gráfico)? Luego, con 9 personas, todavía tenemos solo una aceleración de 1.8 veces.

¿Cual es la solución? No hay una solución fácil, pero hay cosas que puede hacer para mitigar el efecto de la Ley de Amdahl:

• Haga que la mayor parte del trabajo posible se pueda hacer en paralelo. Esto puede significar aumentar las habilidades cruzadas y la colaboración.
• Reduzca las dependencias entre equipos, para que no haya cuellos de botella ni retrasos.
• Aumente la velocidad del proceso de trabajo en general mejorando la calidad y las prácticas.

La velocidad no proviene de enviar a más personas al trabajo y formar equipos más grandes. Se trata de construir un equipo de alto rendimiento que tenga un tamaño óptimo para la eficacia, la comunicación y la calidad.

Evidencia respaldada por investigaciones

American Sociological Association

La American Sociological Association publicó un estudio de Hackman JR, Vidmar NJ llamado “Effects of size and task type on group performance and member reactions.” algó así como “Efectos del tamaño y el tipo de tarea en el desempeño del grupo y las reacciones de sus miembros“^[12].

En este estudio, hicieron que los participantes completaran una serie de tareas: una combinación de producción (escritura), discusión y resolución de problemas. Los participantes se colocaron en diferentes grupos de 2 a 7. Después de completar cada tarea, se les hizo una serie de preguntas a los voluntarios, incluidas dos que se muestran en este gráfico: “¿su grupo era demasiado pequeño?”, “¿su grupo era demasiado grande?”. Como puede ver en el gráfico, los grupos de alrededor de 4-5 de tamaño parecían tener la reacción menos negativa. El número frecuentemente tocado es 4.6. Los participantes eran estudiantes universitarios, las tareas tenían una carga cognitiva pero no estaban relacionadas con tennología, desarrollo, etc., y los grupos no estuvieron juntos el tiempo suficiente para que se formara un verdadero “sentido de equipo”. No obstante, es un dato interesante.

Por aquellos días Hackman escribió el libro Leading Teams, su regla general para el tamaño del equipo era 6^[13].

Social and Developmental Psychology Researcher Jennifer S. Mueller

La Psicóloga-Invetigadora Jennifer S. Mueller académica, autora y colaboradora de varias investigaciones fue citada en el artículo “Is Your Team Too Big? Too Small? What’s the Right Number?:”

Si las empresas están lidiando con tareas de coordinación y problemas de motivación, y usted pregunta: “¿Cuál es el tamaño de su equipo y cuál es el óptimo?”, eso corresponde a un equipo de seis. “Más allá de los cinco, comienzas a ver una disminución de la motivación”, dice Mueller. “Después de la quinta persona, buscas camarillas. ¿Y el número de personas que hablan en un momento dado? Eso es más difícil de manejar en un grupo de cinco o más”.

De Los creadores de Scrum…ni más ni menos

A partir de los estudios de George A. Miller, y trabajos posteriores, lo creadores de Scrum Jeff Sutherland y Ken Schwaber mostraron los siguientes niveles de productividad basados ​​en su propia investigación sobre el tamaño del equipo:

Equipo Agile	Productividad	Equipo NO Agile	Productividad
< 7 miembros	300 / 400 %	< 7 miembros	100% max
> 7 miembros	400 %	> 7 miembros	< 90%

Y agregaron:

Un pequeño equipo de tres a cuatro personas puede ser muy autónomo cuando sigue pautas, tiene un enfoque bien definido, y todos están físicamente en el mismo espacio. Su trabajo es a menudo consistente, responsable, alineado y bien dirigido, y la comunicación es fluida. Las cosas son relativamente fáciles cuando solo hay unas pocas personas en el equipo. Los problemas parecen aumentar junto con el número de miembros del equipo.

Ley de Brooks y Lawrence Putnam

El mítico Frederick Brooks al cual se le debe la famosa “La Ley de Brooks” establece que “agregar mano de obra a un proyecto de software tardío lo hace incluso más tardío”. Esto es debido a la curva de aprendezaje, es decir, debe capacitar a cada persona nueva en el producto o tecnología, y debe aprender todo el conocimiento no técnico relacionado, incluidas las estrategias comerciales que aborda el producto o el software ^[14].

Según importantes estudios realizados por investigadores de renombre como Lawrence Putnam:

Miembros	Esfuerzo
< 9 miembros	25% menos esfuerzo
> 9 miembros	25% más esfuerzo

Con un Equipo Agile:

Miembros	Productividad
1	25% más
5	125% más
9	225% más

En resumen, si tenemos un equipo óptimo, podemos llegar a tener una productividad del 300 al 400%.

Datos duros de Putman y Mayers

Más allá de nuestras opiniones personales, las de los clientes, jefes, miembros del equipo, también tenemos estadísticas objetivas. Putnam y Myers examinaron datos de 491 proyectos de software en una gran corporación como publicaron en su aritículo “Familiar Metric Management: Small is Beautiful Once Again“. Estos fueron proyectos con 35,000 – 90,000 líneas fuente de código. Dividieron los proyectos en grupos que llamaron buckets según la cantidad de personas involucradas en el proyecto: 1.5-3, 3-5, 5-7, 9-11 y 15-20. En promedio, los grupos más pequeños (3-5, 5-7) tardaron mucho menos tiempo (11.9 y 11.6 meses, respectivamente) que los grupos más grandes (17.1 y 16.29 meses) para completar proyectos de tamaño similar.

Cuando multiplicas el número de miembros del equipo por el número de meses, obtienes un gráfico que es aún más impactante:

Un equipo de 9 a 11 personas tardó entre 2.5 y 3.5 veces más tiempo que los equipos de 5 a 7 y de 3 a 5 para completar proyectos de un tamaño similar. Eso sugiere que los equipos de más de siete en este conjunto de datos eran solo una forma de gastar dinero más rápido debido al aumento del tamaño del equipo pero con rendimiento neto reducido.

Evidencia de proyectos Agile

Larry Maccherone, en su trabajo a través de Rally, Tasktop y AgileCraft expuestos en “Impact of Agile Quantified” a finales del 2014″, ha ayudado a construir grandes conjuntos de datos sobre prácticas en equipos Agile . Sus datos muestran:

Según los datos de Larry, parecería que los equipos de 1-3 son más productivos pero tienen menor calidad. Los equipos de 3-5 son marginalmente más productivos que los de 5-9, aunque aún pueden tener una calidad ligeramente inferior: la diferencia es pequeña. Las notas de Larry sugieren que piensa que todo el rango de 3 a 9 está bien^[16]. La razón de la menor calidad en los equipos más pequeños no es evidente. ¿Quizás por falta de estabilidad? ¿Falta de diversidad de pensamiento y experiencia? ¿Funcionalidad cruzada reducida? No podemos saberlo, pero merece consideración.

Mi Experiencia

Cuando los clientes, jefes, etc., me preguntan qué tamaño deberían tener los equipos Scrum, no tengo una respuesta “correcta”. Pero trato de compartir los datos anteriores, mis opiniones personales y sugerencias basadas en años de experiencia. Y no les mentiré, hay organizaciones donde los malos hábitos está tan arraigados que cuesta trabajo permear de manera práctica esa información (no la escuchan, lo toman suficientemente en cuenta, etc.). Pero sin lugar a dudas procuro que mis sugerencia se basen en la evidencia, en la lógica simple y el sentido común.

Por ejemplo, los equipos más grandes pasan más tiempo formándose, más tiempo normalizándose y, por lo tanto, más tiempo para alcanzar un alto rendimiento. ¿Por qué? Porque hay más relaciones que negociar. Como vimos antes, en un equipo de 5, hay 10 relaciones que deben formarse, un equipo de 7 tiene 21 relaciones, y así sucesivamente. Más relaciones toman más tiempo para construir y establecer la confianza, por lo que debe tenerse en cuenta a la hora de decidir el tamaño del equipo.

Suponiendo que todo lo demás sea igual (las habilidades necesarias para realizar el trabajo, la diversidad de pensamiento, etc.), la evidencia existente respalda la idea de que los equipos de 4 a 6 funcionan bien en la mayoría de las situaciones. Toman menos tiempo para formarse y son tan productivos como los equipos más grandes. Además, los equipos de 5-7 normalmente pueden combinar habilidades lo suficiente como para cubrir la pérdida de un miembro del equipo.

Personalmente, solo elegiría un equipo de 8 si otras presiones, como la amplitud de habilidades requerida, lo obligaran a suceder. No recomiendo equipos de más miembros, porque los gastos generales superan el valor de la persona adicional.

Con equipos de 10 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia y la de otros colegas agilistas con experiencia en escalamiento: los equipos separados de 4 y 5 hacen más que su numeroso equipo original.

Con equipos de 9 o más, recomiendo dividirse en 2 equipos. Mi propia experiencia refleja la de otros agilistas utilizando Scrum: los equipos separados de 4 y 5 hacen más que su gran equipo original.

¿Por qué no 3 o menos? Porque daría como resultado muy poca diversidad de pensamiento y probablemente sería muy difícil encontrar 3 personas con suficientes habilidades para hacer el trabajo en un proyecto complejo. También habrá muy poca colaboración, lo que se correlaciona con la reducción en la calidad que muestra la Figura n.º 2 (datos de “Impact of Agile Quantified”). Y no olvide los problemas obvios de energía 2 contra 1 que pueden hacer que el viaje sea más desafiante para un miembro del equipo.

Todo el enfoque se ha centrado en la cantidad de personas en el equipo, pero la pregunta más importante debería ser esta: ¿tiene el equipo la capacidad de llegar a “Done” o “Terminado” al final de cada Sprint? Si no es así, querrá volver a examinar y reconfigurar para lograr un tamaño de equipo más efectivo y hacer muy probablemente un re-análisis al desglose de trabajo en requerimientos, historias de usario o similares.

---

[1] “The Impact of Lean and Agile Quantified” – Larry Maccherone demostró que miembros dedicados a un sólo equipo duplicaron la productividad y los equipos estables (sin rotación) mejoraron la productividad en un 60%. https://www.infoq.com/presentations/agile-quantify

[2] Wilkinson, David. Group decision-making. Lo que dice la última investigación. The Oxford Review, Diciembre 2019

[3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr y también “Evidence for a Collective Intelligence Factor in the Performance of Human Groups“

[5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indica que las habilidades potenciales son tan importantes como las habilidades que la gente tiene actualmente para predecir efectividad.

[6] [7] [8] Wilkinson, David. Group decision-making. Lo que dice la última investigación, The Oxford Review, Diciembre 2019

[9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory

[10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management

[11] Estas son observaciones informales que cualquiera puede hacer, pero una de las investigaciones más conocidas la hizo la revista inglesa Nature Human Behavior en 2017.

[12] Stable reference: https://www.jstor.org/stable/2786271

[13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam y Ware Myers https://hbswk.hbs.edu/archive/2996.html

[14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Enlaces de interés:

El Enfoque Agile De La Planeacion
Planeación, Cono de Incertidumbre y Estimaciones en IT
¿Qué Certificación Elegir como Scrum Master

Estos son alguno libros recomendables para saber más: