¿No son excesivos los costes de tener a todo el equipo presente en las reuniones de Scrum?

Equipo completo reunido ante un tablero

Observo una y otra vez un error muy común que consiste en poner únicamente el foco en los costes de algo, obviando lo que nos dice la Agilidad, hay que mirar también cuales son los costes por no hacerlo.

Si calculamos los costes de tener a todos los miembros del equipo de Scrum en las diferentes reuniones, podemos llegar a priori a la conclusión que dedicar a todas esas personas dos días de cada diez, en caso de sprints de dos semanas, puramente a reuniones, puede resultar un coste innecesario. Pero recordemos el lema que dice:

"Piensa dos veces
y codifica bien a la primera"

A veces he oído a algún cliente o gerente de consultora sentenciar: "¡Es mejor que dediquen ese tiempo a codificar, que para eso se les paga!". Suelo contestar que con esas reuniones nos aseguramos de que los equipos construyan a la primera lo correcto, con esas reuniones comprenden lo que han de construir. Y les pregunto: ¿Cuál sería el coste si los desarrolladores no construyen lo correcto a la primera? y, si son conscientes de que tal como muestran las estadísticas del Standish Group, que estudian miles de proyectos de todo el mundo al año, desde mantenimientos pequeños hasta gigantescos proyectos de reingeniería, ¡alrededor de un 80% de lineas de código nunca llegan a producción por malentendidos, retrabajo, etc!

Ya no suelo entrar en que además con Scrum construimos guiados por valor de negocio, lo que nos asegura que mediante estas reuniones el equipo está trabajando en todo momento en lo que más valor aporta. Recordemos que negocio sabe lo que quiere, no lo que necesita, eso madura durante el camino y se materializa en cambios necesarios y deseables.

Pero entremos más a fondo, ¿qué puede ocurrir si no hacemos esas reuniones?

• Escasa colaboración entre negocio y equipo de desarrollo.
• Comunicación pobre de las necesidades de negocio.
• No se identifican los malentendidos, con lo que estos emergen en etapas tardías del proyecto y sus consecuencias pueden generar incidencias y deuda técnica.
• Desarrollo por capas horizontales, diseñamos pensando en el todo, lo que nos lleva a batches largos de trabajo perdiendo así la entrega frecuente de valor de los ciclos cortos.
• Fases largas de testing y de resolución de incidencias, con lo que alargamos los batches ya de por sí largos.
• Resistencia al cambio, con lo que los ciclos de absorción de cambios también son largos y dolorosos.
• Miembros de equipo focalizados en sus tareas, lo que implica poca colaboración y poca creatividad.
• Finalmente una baja motivación, las reuniones de Scrum hacen que todos sientan que participan del proyecto y que aportan. Recordemos que el propósito es una de las motivaciones intrínsecas más fuertes.

Curvas que son ejemplo de como se pueden comportar ambos costes
estas pueden variar en función del proyecto y la madurez ágil del equipo

Visto todo esto, vemos que sin reuniones trabajamos con batches largos (usualmente hasta final de proyecto o el siguiente hito), lo que produce grandes colas en el flujo de construcción, lo que a su vez produce tiempos de entrega largos, y desde la perspectiva de negocio un time-to-market bajo que puede minimizar seriamente la competitividad de la compañía.

A parte de los costes directos del tiempo dedicado a las reuniones, lo vemos en el gráfico de la derecha en la curva de color rojo oscuro, hemos de tener en cuenta el coste de la demora, en verde, que representa el coste que supone la espera en la entrega de una funcionalidad de valor. Si acometemos un proyecto abarcando el todo desde el principio, y no hacemos reuniones periódicas, perdemos oportunidades de mercado ya que no hay entrega hasta el final, perdemos los ciclos de aprendizaje que nos permiten mejorar el producto y la forma de trabajar así como también perdemos la absorción de los cambios, cambios que siempre implican un aumento del valor de negocio. En la parte de la derecha el coste de la demora vuelve a subir porque en ese caso hipotético los equipos dedicarían su tiempo a reunirse y sus entregas serían muy escasas.

La curva naranja nos muestra el coste total, podemos ver claramente que el coste menor se produce con un nivel de tiempo dedicado a reuniones de entre el 15% y el 25%, tiempo que es coherente con los eventos de Scrum.

Un alumno de uno de mis cursos de Scrum me habló convencido de la imposibilidad de hacer pair programming en su compañía, por los costes elevados que supone. De nuevo hay que preguntarse por los costes de no hacerlo.

Poner a dos personas en un solo ordenador es más costoso que poner a una sola, es de lógica, pero de lógica financiera. Si pensamos en productividad veremos que una persona ante un ordenador tiene 1 de productividad, y cuando hacemos pair programming bien hecho, integramos equipo, unificamos formas de trabajar, creamos base de conocimiento, se producen buenas ideas por colisión de ideas individuales... y todo eso hace que la productividad suela situarse entre el 4 y 6. Desde este punto de vista, el punto de vista de productividad y la lógica de los equipos técnicos, ¿pair programming tiene más costes? ¿o más bien es menos costoso?

¿Es más costoso hacer las reuniones de Scrum? o ¿es más costoso no hacerlas? - cortesía de Pixabay