¡No, no subiremos nuestra velocidad!

En el último Sprint en mi equipo ocurrió algo que pocas veces ocurre: terminamos todas las historias cuando quedaban aún 4 días de Sprint. El Product Owner estaba feliz porque incluimos 2 historias más y nosotros estábamos felices porque incluimos Spikes y tareas técnicas de nuestro Backlog de mejora continua.

Al llegar la Retrospectiva algunos comentaron, como algo positivo, que habíamos subido nuestra productividad, llegando al récord de 23 puntos en un Sprint. Sin embargo, respecto del mismo hecho, yo comenté como algo negativo que habíamos sobreestimado dos de las historias. Esta diferencia de opinión respecto del mismo hecho nos llevó a discutir sobre si como equipo queremos/debemos o no tratar de subir nuestra velocidad, medida como story points entregados por sprint.

Mi postura al respecto es bastante clara, yo NO quiero subir la velocidad de mi equipo y no es que sea mediocre o conformista. Es normal que un equipo quiera mejorar en el tiempo y entiendo la tentación de tratar de entregar más en cada sprint, pero no es la velocidad lo que nos debe preocupar.

Antes de seguir con este artículo, quiero mencionar que sí conozco #NoEstimates pero como equipo hemos decidido mantenernos con los story points debido a que estamos enfrentando otros cambios, tanto metodológicos como tecnológicos y soy de la opinión, al igual que otras personas (aquí y aquí), que no es bueno hacer muchos cambios a la vez.

Ahora retomando, ¿por qué no debemos apuntar a aumentar la velocidad? Al menos a mí se me ocurren tres razones.

Mejora continua versus velocidad

En mi equipo usamos la escala de Fibonacci para estimar y consideramos tres factores que contribuyen en el tamaño de una historia:

1. Repetitividad. ¿Hemos implementado en el pasado algo similar en el pasado?
2. Riesgo. ¿Existe algo desconocido en el proceso, organización, definiciones, stakeholders? ¿o algo conocido pero que no sabemos si nos va a afectar?
3. Complejidad. ¿Cuántas tareas se necesitan para completar esta historia y cuál es su complejidad?

Como parte de la mejora continua, estamos preocupados permanentemente de estos tres factores y, cada vez que logramos implementar alguna mejora en uno de ellos, las historias se van haciendo cada vez más chicas. Déjenme ilustrar esto con un ejemplo para que quede más claro.

Supongamos que en el Sprint 1 tenemos que implementar un mantenedor para una tabla de configuración. Después de varios refinamientos estimamos la historia en 8 puntos, ya que identificamos lo siguiente:

1. Vamos a usar un ORM con el que nunca antes hemos trabajado. (baja Repetitividad, crece tamaño).
2. Tenemos que generar todas las vistas manualmente, incluyendo formularios y validaciones. (sube Complejidad, crece tamaño).
3. No está claro quién es el dueño de la Base de Datos. (sube Riesgo, crece tamaño).
4. El proceso de creación de tablas es manual en cada uno de los ambientes (desarrollo, beta, uat, producción). (sube Complejidad, crece tamaño).

Al terminar el Sprint 1, conversamos estos temas en la retrospectiva y, luego de hablarlo con el PO, incluimos en el Sprint 2 una tarea técnica para automatizar la creación de vistas a partir de un modelo y otra para automatizar la creación de tablas al pasar de un ambiente a otro.

Por otra parte, el PO logró reunir a los stakeholders y se llegó a un acuerdo sobre quién es el dueño de la Base de Datos.

En el Sprint 3 debemos implementar otro mantenedor, para otra tabla del sistema. ¿Cuántos puntos debiéramos darle a esta nueva historia? Dado que los 4 aspectos anteriores fueron mejorados o resueltos, ahora el equipo estima la historia en 2 puntos. Ahora podemos hacer 8 mantenedores por Sprint en vez de 2, ¡pero nuestra velocidad sigue siendo la misma!

La verdad es que esto no es realmente un problema, sólo hay que saber mirar los hechos detrás de los números.

Predicitibilidad versus velocidad

Una vez un jefe de proyecto, nuevo en la agilidad y acostumbrado a cartas Gantt y a la planificación anticipada y detallada, me comentó que finalmente se había convencido con esta nueva forma de trabajar y que incluso los ejecutivos ya estaban convencidos. Lo único que no lo tenía feliz era que el equipo, Sprint tras Sprint, no alcanzaba a entregar lo que había comprometido.

A este jefe de proyecto no le importaban si eran 10, 20 o 500 story points, lo que le importaba era tener una certeza (o un buen grado de certeza) de qué iba a entregar el equipo de aquí a dos semanas más.

¿Qué sentido tiene querer aumentar la velocidad de un equipo cuando se usa una medida tan arbitraria como story points? ¿a quién le sirve que aumente algo que es medido en una escala que nadie entiende fuera del equipo? Más vale la pena que el equipo se enfoque en mejorar su predictibilidad, no su velocidad.

La trampa del inconsciente

Dejé para el final la que quizás es la más obvia de las razones. Si uno tiene como objetivo aumentar la cantidad de puntos entregados por sprint, entonces lo más fácil es asignar números más grandes al estimar. No que las personas hagan intencionalmente trampa, pero el inconsciente nos puede engañar y llevar a este tipo de vicios, sobre todo cuando la capa de management introduce metas del tipo “aumentar en 20% la velocidad por semestre”, o peor aún cuando asocia la velocidad de un equipo a su evaluación y/o a su bono de desempeño.

¿Cómo sabemos si vamos mejorando?

Si no subimos nuestra velocidad, entonces ¿cómo sabemos si vamos mejorando? Existen muchas otras métricas que podemos implementar y gestionar: cantidad de defectos en producción, cobertura de pruebas automáticas, performance, complejidad ciclomática o satisfacción de los stakeholders, por nombrar algunas. Es importante entender eso sí que todas las métricas tienen ventajas y desventajas, todas pueden generar vicios y trampas inconscientes y que no nos podemos llenar de métricas porque tener muchas es lo mismo que no tener ninguna, pero eso podría quedar como tema para un futuro post.