¿Por qué el Equipo de Desarrollo debe tener entre 3 y 9 miembros?


Scrum nos indica que el Equipo de Desarrollo debe componerse por entre tres y nueve personas, sin contar con el Scrum Master y el Product Owner, a menos de que estos también realicen tareas de desarrollo durante el Sprint. Dicho de otra manera, el Equipo Scrum podría integrarse por un máximo de once profesionales.


¿De dónde sale este rango “mágico” para establecer el tamaño deseable del Equipo?

No es arbitrario. Ken Schwaber y Jeff Sutherland, creadores de Scrum, se basan en la investigación empírica al respecto. El todopoderoso Mike Cohn lo muestra en un gráfico como el de abajo, que recoge el tiempo invertido en completar proyectos de software equivalentes, dependiendo del número de integrantes del Equipo.

Con menos de tres personas, será difícil que el Equipo de Desarrollo cuente con todas las habilidades necesarias para producir el Incremento, a saber: diseño UX/UI, programación back-end/front-end, testing, documentación y un largo etcétera, según el producto de que se trate. A su vez, si el Equipo se compone por una o dos personas, las necesidades de comunicación y coordinación serán mínimas.

He de decir que uno de los mejores Equipos de los que he formado parte lo formábamos tres personas. Eso sí, éramos “tres bestias”, en modo “Super Saiyan” continuo. Siempre que el Equipo sea multifuncional, mi máxima es que, cuanto más pequeño, mejor.


A partir de nueve miembros, cuidado. Las exigencias de coordinación se disparan y empezamos a notar una pérdida importante de productividad, como muestra el gráfico. Añadir miembros al Equipo solo empeora las cosas y hace que tardemos más en entregar. Lo conveniente será “partir” el Equipo y habilitar mecanismos de coordinación para esos dos o “n” Equipos Scrum (que nos llevará potencialmente a modelos de “escalado”). Este es un clásico en empresas en crecimiento, donde a esta tensión se añade la contratación de profesionales que son nuevos en la organización.

La idea expresada en el gráfico es contraria a lo que muchos puedan creer. Cuando empecé en esto del software, iluso de mí, pensaba que los desarrolladores se añadían “al peso”, que, cuantos más, mejor. A lo largo de los años he tenido que combatir esta misma falacia. Recuerdo una situación muy divertida en la que el CFO de una agencia digital bastante grande quería sumar otros veinte desarrolladores al proyecto para acortar los plazos de lanzamiento de la primera versión; y yo le decía que no, que por favor nos diera a uno solo, al mejor que tuviera 😊


¿Sigo haciendo Scrum si mi Equipo de Desarrollo tiene más de nueve personas?

Sergio, y, si en mi Equipo de Desarrollo somos trece, ¿significa que ya no estamos haciendo Scrum? Recientemente un Scrum Master me planteaba esta situación, y me decía que ellos estaban “adaptando” el framework a sus circunstancias y que, si dividían al Equipo en dos como yo sugería, ya dejaban de ser multifuncionales.

En mi opinión, si en efecto esta es la única forma de preservar la multifuncionalidad, es posible “aceptar «pulpo» como animal de compañía”, a corto plazo o durante varios Sprints. No obstante, en este caso en concreto, el objetivo debería ser resolver las carencias en habilidades que nos impiden pasar a un esquema de dos Equipos. Puede ser que tu situación sea la excepción que cumple la regla y que vuestra productividad como Equipo sea mayor con trece personas que con dos Equipos de seis y siete, pero lo dudo mucho. Prefiero no reinventar la rueda.


Bienvenidos al maravilloso mundo de las habilidades en forma de “T”

A fin de aumentar el grado de multifuncionalidad del Equipo de Desarrollo, el Scrum Master ha de procurar el ensanchamiento del abanico de habilidades de sus miembros, es decir, fomentar las habilidades de forma de “T”, de las que hablaremos próximamente…


Imagen de portada: Daily Sprint Meeting by Klean Denmark

Comparte este post

Publicado por Sergio Rodríguez

Chief Product Officer and Product Consultant for several international startups throughout his career, such as Liftshare.com, Hiyacar and Cardmarket. Agile practitioner for over 10 years and PSPO III certified. Obsessed with creating products that people love.

Posts relacionados

Comentarios

Deja tu comentario

Tu dirección de correo no será publicada. Lo campos requeridos están marcados con *

Recibe artículos sobre ágil y promociones en tu email.