El equipo Scrum

A principios de los 90, Jim Coplien fue invitado a evaluar un proyecto de Borland Software Corporation. Estaban creando un nuevo programa de hoja de cálculo llamado Quattro Pro para Windows. El software tenía más de un millón de líneas de código, tardó treinta y un meses y contó con un equipo de ocho personas. Eso significa que cada miembro del equipo producía mil líneas de código cada semana. Eso es más código en menos tiempo que cualquier otro equipo del que se tenga constancia. (Véase el artículo de Coplien en la pestaña Papers and Patterns).

Para averiguar por qué el equipo de Borland era tan rápido, Coplien trazó un mapa de todos los flujos de comunicación dentro del equipo: quién hablaba con quién, dónde fluía la información y dónde no. Este tipo de mapeo es una herramienta clásica que puede utilizarse para detectar cuellos de botella o acaparadores de información. Cuanto mayor es la saturación de la comunicación -todo el mundo lo sabe todo-, más rápido es el equipo. Básicamente, la métrica derivada de este tipo de análisis mide hasta qué punto todo el mundo sabe lo que necesita saber para hacer su trabajo. El equipo de Borland sigue teniendo la puntuación más alta: el 90 por ciento. La mayoría de las empresas rondan el 20%.

Lo que frena la saturación de la comunicación es la especialización, es decir, el número de funciones y títulos de un grupo.. Si las personas tienen un título específico, tienden a hacer sólo las tareas que corresponden a ese título. Y para proteger el poder de ese papel, tienden a aferrarse a conocimientos especializados. Por eso el Scrum sólo tiene tres funciones: una persona es miembro del Equipo, del Scrum Master o del Product Owner. Esto puede resultar difícil para las organizaciones tradicionales, pero es fundamental para conseguir el tipo de aumentos de productividad que Scrum puede ofrecer.

Del mismo modo que el número de funciones influye en el rendimiento, el número de personas de un equipo también tiene un efecto dramático. La dinámica de equipo sólo funciona bien en equipos pequeños. La fórmula clásica es de siete personas, más o menos dos, aunque los equipos más rápidos suelen rondar las cinco. Lo fascinante es que Los datos muestran que si hay más de nueve personas en un equipo, Velocity se ralentiza.. Sorprendentemente, más recursos realmente hacen que los equipos más lento.

En el desarrollo de software existe un término llamado Ley de Brooks. Fred Brooks la acuñó por primera vez en su libro seminal de 1975 El mítico Hombre-Mes. En pocas palabras, Ley de Brooks afirma "añadir mano de obra a un proyecto de software tardío hace que sea más tardío." Así lo confirman un estudio tras otro. Lawrence Putnam, una figura legendaria del desarrollo de software, se dedicó toda su vida a estudiar cuánto se tarda en hacer las cosas y por qué. Su trabajo seguía demostrando que los proyectos con veinte o más personas empleaban más esfuerzo que los de cinco o menos. No sólo un poco, sino mucho. Un equipo grande empleaba unas cinco veces más horas que uno pequeño. Lo comprobó una y otra vez, y a mediados de los noventa decidió hacer un amplio estudio para determinar cuál es el tamaño adecuado de un equipo. Así que analizó 491 proyectos de tamaño medio en cientos de empresas diferentes. Se trataba de proyectos que requerían la creación de nuevos productos o funciones, no la readaptación de versiones antiguas. Dividió los proyectos por tamaño del equipo y enseguida se dio cuenta de algo. Cuando los equipos superaban los ocho miembros, tardaban mucho más en hacer las cosas. Los grupos de tres a siete personas necesitaban aproximadamente el 25% del esfuerzo de los grupos de nueve a veinte personas para hacer el mismo trabajo. Este resultado se repitió en cientos y cientos de proyectos. Que los equipos grandes logran menos que los pequeños parece ser una regla irrefutable de la naturaleza humana. (Véase la pestaña Diapositivas).

Con demasiada frecuencia hay tareas que sólo puede hacer una persona del Equipo. Esto es habitual entre los equipos Scrum principiantes. Hay que solucionarlo lo antes posible. La razón es que si sólo una persona puede hacer el trabajo, y esa persona no está disponible, todo el equipo se paraliza. La gente se pone enferma, cambia de trabajo... No puede permitirse que su organización sea rehén de una sola habilidad.

Los buenos equipos Scrum se aseguran de que al menos dos personas, e idealmente más, puedan hacer cualquier trabajo. Los equipos que resuelven este problema tienden a aumentar su Velocidad. La razón es que el conocimiento colectivo, y no la habilidad individual, es lo que mejora la velocidad del equipo. Los individuos pueden flaquear, pero si el resto del equipo puede seguir adelante, su productividad no se resiente.

Quizás la mejor forma de asegurarse de que su equipo no está limitado es mediante el emparejamiento y la formación cruzada. Si sólo hay una persona que pueda hacer una tarea, asegúrate de que la próxima vez que surja esa tarea se empareje con alguien mientras la hace para que esa persona pueda aprender. Anima a todo tu personal a que se forme en varias habilidades, no sólo te beneficiarás tú, sino que ellos estarán más comprometidos y entusiasmados a medida que aprendan nuevas habilidades.

Papel: Documento de Borland sobre los equipos

Patrón: Equipo autónomo

Patrón: Equipo estable

El Scrum Lenguaje Patrón de Programación : El movimiento PLoP codifica prácticas ágiles bien conocidas que han tenido éxitol implementard muchas veces.