La velocidad es un concepto ágil muy importante que le sirve a los equipos para poder comprometerse al trabajo de una iteración. Sin embargo, una vez entendido el concepto, hay que tener cuidado en no usarlo para motivos equivocados, y evitar al máximo cometer algunos errores básicos.
En este artículo vamos a ver 3 anti-patrones sobre el concepto de velocidad; comprenderlos y evitarlos nos ayudará a mejorar nuestro proceso de desarrollo.
#1: Cuando terminado no es terminado
Primero, vamos a definir "velocidad": La velocidad es la cantidad total de unidades de estimación para los elementos terminados en una iteración. La unidad de estimación puede ser cualquier cosa que elija el esquipo: días ideales, horas, puntos de historia. La naturaleza del elemento varía también: características, casos de uso, historias de usuario. La iteración es una cantidad fija de tiempo en donde trabaja el equipo para terminar estos elementos. ¿Parece simple? Bueno... hay un concepto que a veces se pasa por alto: ¿qué significa terminado?
Uno de los errores más frecuentes es no tener en claro la Definición de Terminado (¡o directamente no tenerla!). El Pensamiento Lean nos dice nada está realmente terminado hasta que entrega valor; en software eso significa: código ejecutándose en producción siendo usado por usuarios reales. Cuando una historia se considera terminada debería ser con calidad productiva: debe poder ir directamente a producción si el negocio así lo decide.
Algunos síntomas que podrían indicar problemas con la definición de terminado:
- "Está terminado, pero [necesitamos escribir pruebas de aceptación / no está integrado con otro sistema / no está probado /....]"
- "Está terminado, pero le falta un poquito".
- Llevar la historia a producción lleva mucho trabajo adicional.
- Después de terminada, la historia pasa al backlog de otro equipo.
- Escuchar cosas como "la velocidad del equipo de desarrollo" o "la velocidad del equipo de testing".
- Contar la mitad de los puntos o porcentajes porque "si no las contamos va a parecer que no hicimos nada".
¿La solución? Recordar que la velocidad es tan sólo un número que brinda información para que el equipo interprete y pueda mejorar su progreso. Hay que olvidarse de hacer un seguimiento de la velocidad y en cambio enfocarse por completo al Flujo de Valor y qué tanto valor tienen las cosas que llegan a producción. Todo el resto es desperdicio.
#2: Inventar puntos
El segundo anti-patrón es cuando los equipos empiezan a inventar puntos para sumar a su velocidad. Como la definición de velocidad es muy simple, resulta facil engañar a la métrica para aparentar progreso. Si a un equipo se lo mide por su velocidad (siguiente anti-patrón), van a empezar a incrementar sus estimaciones: "si duplicamos todas las estimaciones, el tamaño relativo se mantiene, pero nuestra velocidad se duplica!". Este es un comportamiento extremo que sale a la luz rápidamente, pero puede ocurrir a menor escala y pasar desapercibido.
El problema puede originarse en el equipo, y también lo pueden generar los Líderes de Proyecto / Scrum Masters cuando se les "ocurre" formas de inventar puntos para contarlos como velocidad:
- Contar la "mitad de los puntos de una historia" o porcentaje de la misma (ver el antipatrón anterior)
- Dividir una historia para contar el trabajo parcialmente completo como "terminado", y hacer el seguimiento de lo que queda en una historia separada (dividir historias es una cuestión del negocio y no debe ocurrir por cuestiones de seguimiento: sólo debería ocurrir cuando aparece una forma incremental más simple de entregar valor en porciones más pequeñas).
- Contar puntos por tareas técnicas. Esto suele ocurrir mucho en iteraciones que tienen deuda técnica acumulada, y por lo tanto no les queda mucho tiempo para trabajar en historias nuevas. El Líder de Proyecto decide entonces inventar una "historia de refactor", la estiman con un valor alto, y así demuestran cuánto esfuerzo puso el equipo en hacer el refactor.
- Contar puntos por arreglo de bugs ocurridos en otras iteraciones. Un equipo terminó historias en la primera iteración, pero en iteraciones posteriores empezaron a aparecer bugs, lo que impacta negativamente en la capacidad del equipo de entregar nueva funcionalidad. En vez de aceptar la disminución de velocidad para demostrar cómo impactó la falta de calidad al equipo (deberíamos evitar los bugs en primer lugar, ¿no?), el Líder de Proyecto decide estimar y contar los puntos de las "historias de bugs", y así la velocidad aparente mantenerse constante, cuando en realidad se entregó mucho menos valor.
#3: Usar la velocidad como medida de rendimiento
Ya lo vimos muchas veces: La velocidad no mide la productividad de un equipo. De hecho, intentar hacerlo puede generar anti-patrones muy peligrosos. Algunos anti-patrones relacionados:
- Comparar la velocidad entre equipo: "¿Por qué el equipo A va más lento que el equipo B?". ¿Quizás porque usan distintas escalas para estimar? ¿Quizás la duración de la iteración es diferente? ¿Quizás la composición del equipo es distinta? Hay tantos factores que influyen en la velocidad que sólo resulta útil compara la velocidad de un equipo con el mismo equipo (e incluso así, sólo sirve para medir tendencias). El valor absoluto no tiene mucho significado.
- Medir velocidades individuales: como lo menciona Pat, este es un uso MUY PELIGROSO de la velocidad, y de hecho puede dañar el proceso y desalentar la colaboración.
- Insisitr en aumentar la velocidad: es común tener una velocidad más baja al inicar un proyecto que tiende a incrementarse después de algunas iteraciones. A pesar de eso, varios equipos intentan empujarse para mejorarla hasta que alcanzan un límite natural (¿quién no quiere ir más rápido?). La velocidad mide la capacidad del equipo de entregar y, como tal, tiende a estabilizarse (si tenemos un proceso estable y no se está engañando la velocidad). Un simple gráfico puede ayudar a visualizar este hecho. Como lo dijo Deming, en un proceso estable, la forma de mejorarlo es cambiar el proceso.
Es importante recordar que la velocidad es una consecuencia de la realidad actual (los equipos, los procesos, las herramientas). Sólo se puede mejorar el proceso una vez que esté estable y se conozca su capacidad. La velocidad es un número que nos informará sobre la capacidad del equipo. No nos va a decir cuánto valor se está entregando, ni qué tan rápido avanzamos. Podemos estar entregando un montón de puntos haciendo consesiones con la calidad, y sin importar cómo lo midamos, va a impactar negativamente nuestra capacidad de ir más rápido a largo plazo. Como dicen:
La forma para avanzar más rápido es avanzar bien
Dejemos de usar la velocidad como herramienta para medir productividad; usemos la velocidad como una herramienta de diagnóstico para mejorar nuestro proceso de desarrollo de software.
