La velocidad es una de las métricas más monitoreadas en equipos ágiles y una de las más malinterpretadas. He trabajado con equipos cuyos gráficos de velocidad parecían saludables —estables, predecibles y cumplían sus estimaciones sprint tras sprint— mientras que el sistema subyacente se degradaba silenciosamente. También he trabajado con equipos cuya velocidad fluctuaba enormemente y que trataban dicha fluctuación como una crisis, cuando en realidad era la señal más honesta que su proceso podía generar.
El problema no es la métrica en sí. La velocidad, bien entendida, es extraordinariamente sensible a las disfunciones.
La velocidad estable puede ocultar disfunciónes
Un gráfico de velocidad estable suele considerarse una prueba de que un equipo ha madurado. Sprint tras sprint, las cifras se acercan a la estimación. Los gráficos de evolución se ajustan perfectamente a la línea ideal. El liderazgo ve previsibilidad. El equipo, consistencia.
Lo que quizá no vean es que la estabilidad misma se ha convertido en el objetivo. Y cuando eso sucede, la métrica deja de ser un reflejo de la productividad y pasa a ser un objetivo que los equipos optimizan, a menudo en detrimento del trabajo en sí.
He observado que los equipos que optimizan la previsibilidad realizan ajustes sutiles para proteger las cifras. Limitan las estimaciones. Aplazan el trabajo arriesgado. Se centran en alcanzar la velocidad planificada en lugar de trabajar a plena capacidad con el nivel de calidad que el producto realmente necesita. El resultado es una métrica de velocidad que parece estable, mientras que la capacidad real del equipo para generar valor se estanca o disminuye.
Esta no es una preocupación hipotética. Un equipo que considera la velocidad como la medida del éxito, en lugar de como un factor más entre muchos, eventualmente dejará de mejorar. El número se convierte en un ancla, no en un indicador.
Hay información en la variación de la velocidad
El patrón inverso es igualmente común y, a menudo, más ilustrativo. Un equipo cuya velocidad varía significativamente de un sprint a otro suele ser juzgado como inmaduro, inconsistente o mal gestionado. Pero la variación en la velocidad no es inherentemente problemática. De hecho, suele ser el reflejo más fiel de lo que realmente sucede.
La velocidad se basa en los puntos de historia, que en sí mismos son una medida de complejidad, no de esfuerzo. Cuando la complejidad varía, como ocurre inevitablemente en el desarrollo de software real, la velocidad también varía. Cuando cambia la composición del equipo, las dependencias externas se transforman o la naturaleza del trabajo cambia de un sprint a otro, la velocidad reflejará esos cambios. Eso no es disfunción. Es información.
El error es tratar la variación como ruido que debe eliminarse en lugar de como una señal que debe interpretarse. Un gráfico de evolución con fluctuaciones extremas que muestra la finalización del trabajo en ráfagas irregulares puede indicar que las historias no son lo suficientemente independientes o que no se han desglosado en tamaños similares. Pero también puede indicar que el equipo está abordando un trabajo realmente difícil, que está aprendiendo sobre la marcha y que las estimaciones, por aproximadas que sean, cumplen exactamente su función: reflejar la incertidumbre.
Trabajé con una empresa de desarrollo de videojuegos donde los gráficos de velocidad diaria mostraban un patrón escalonado característico: largos periodos sin progreso, seguidos de caídas repentinas a medida que se completaban varias historias a la vez. La suposición inmediata fue que el equipo estaba bloqueado o mal coordinado. La causa real fue que las propias historias estaban estrechamente relacionadas. Las modificaciones al juego y a sus sistemas de recompensas tenían prerrequisitos que permeaban la escritura de la historia. Las historias del sprint N debían completarse antes de poder comenzar el trabajo del sprint N+1. La solución no fue exigir una velocidad más fluida, sino explicitar las dependencias, separar los prerrequisitos entre sprints (permitido) y eliminar las dependencias dentro del sprint (no permitido). Una vez abordado este problema estructural, el gráfico de velocidad volvió a ser realmente informativo. Para más información sobre las distinciones técnicas entre velocidad diaria, de sprint y promedio, he escrito una serie detallada de tres partes que profundiza en la teoría de la medición y los errores comunes.
Cuando los equipos optimizan para lo equivocado
El uso indebido más insidioso de la velocidad se da cuando las organizaciones la utilizan para comparar equipos o, peor aún, cuando establecen objetivos de velocidad. Ambas prácticas son fundamentalmente erróneas, ya que los puntos de historia no son una unidad de medida estándar. Un punto de historia en un equipo no equivale a un punto de historia en otro. El significado es contextual, se calibra dentro de cada equipo y cambia con el tiempo a medida que evoluciona la comprensión del equipo sobre su propio trabajo.
Cuando la velocidad se convierte en un objetivo, se desencadena la Ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Los equipos manipularán el sistema. Inflarán las estimaciones. Evitarán el trabajo difícil. Se centrarán en alcanzar la cifra en lugar de aportar valor. Y al hacerlo, destruyen lo único que hizo que la velocidad fuera útil en un principio: su sensibilidad a la variación.
La velocidad promedio, en particular, es peligrosa si se aplica incorrectamente. Es una herramienta de planificación, nada más. Normaliza la variación entre sprints para dar a los equipos una idea aproximada de su capacidad. Pero los promedios también son engañosos. Si siempre se busca alcanzar el promedio, basta con un sprint por debajo para reducir la cifra general. Y si la duración de los sprints varía, la composición del equipo cambia o la naturaleza de los turnos de trabajo cambia, la fórmula del promedio simple se desmorona por completo.
La información sobre la velocidad no está en el promedio. Está en la variación. Cuando ves un sprint donde la velocidad baja, la pregunta no es “¿cómo volvemos al promedio?”. La pregunta es “¿qué cambió y qué nos dice eso?”.
¿Qué mide realmente la velocidad?
La velocidad no mide el valor. No mide la calidad. No mide si se está construyendo lo correcto. Lo que mide la velocidad es el rendimiento: la velocidad con la que un equipo convierte la complejidad estimada en trabajo completado dentro de un plazo limitado.
Esta información es útil, pero solo si recuerdas lo que no te dice. Un equipo puede tener una velocidad alta y estable y aun así estar desarrollando las funciones incorrectas, acumulando deuda técnica o desviándose de los resultados que sus partes interesadas realmente necesitan. Por el contrario, un equipo con una velocidad baja o errática puede estar realizando un trabajo fundamental esencial, gestionando las dependencias con cuidado o simplemente operando en un dominio donde la complejidad es realmente alta y las estimaciones, en consecuencia, inciertas.
El error es tratar la velocidad como un indicador del éxito. No lo es. Es una herramienta de diagnóstico. Y como cualquier herramienta de diagnóstico, solo es útil si sabes lo que buscas.
¿A qué prestar atención en su lugar?
Cuando trabajo con equipos en velocidad, les pido que presten atención a dos aspectos en particular. El primero es el ritmo durante el sprint. Si un equipo avanza rápidamente en sus reuniones de pie, si las mismas voces dominan cada retrospectiva, si el nivel de compromiso se percibe como performativo en lugar de genuino, eso es una señal. Los gráficos de velocidad pueden parecer correctos, pero el sistema subyacente no funciona.
La segunda es qué sucede cuando la velocidad varía. ¿Lo trata el equipo como una crisis o como una oportunidad para aprender? ¿Se preguntan por qué este sprint fue diferente al anterior? ¿O simplemente ajustan la estimación para el siguiente sprint y siguen adelante? Los equipos que mejoran con el tiempo son los que tratan la variación como información, no como un fracaso.
La visión a largo plazo
La velocidad no es un destino. Es un punto de partida para la conversación. Es una forma de visibilizar lo que de otro modo permanecería implícito: la capacidad del equipo, la complejidad de su trabajo, la estabilidad o inestabilidad de su entorno. Si se utiliza correctamente, ayuda a los equipos a planificar con mayor eficacia, identificar problemas con antelación y mantener mejores conversaciones sobre lo que realmente está sucediendo.
Si se usa mal, se convierte en otro objetivo, otra cifra que defender, otra métrica que oculta más de lo que revela. La diferencia no está en la métrica en sí, sino en cómo el equipo —y la organización que lo rodea— decide interpretarla.
Comprender lo que realmente revelan tus métricas de velocidad requiere más que simplemente registrar las cifras: exige un cambio en la forma de interpretar la variación y el valor. Ahí es donde el coaching basado en la evidencia acelera la comprensión. Exploremos cómo se puede usar la velocidad como diagnóstico más que como objetivo. Contáctenos hoy mismo y transformemos sus métricas en mejoras significativas.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
