Deja de medir la rapidez de los equipos ágiles y comienza a medir su velocidad

Hay ocasiones en que pareciera que los astros se alinearan como queriendo darte algún mensaje. Justo eso me sucedió anoche cuando entraba en cuenta que el mes estaba por acabarse y no había escrito mi entrada respectiva. Revisando Linked In tropecé con una publicación de Greg McKeown (autor de uno de mis libros favoritos: Essentialism: The disciplined  pursuit of less) que verdaderamente me puso a reflexionar y me dio la inspiración para escribir esta entrada.

Adicionalmente, alguien compartió en alguna red social el comic de Dilbert de hoy 30 de Agosto el cual totalmente se alinea a ese tema y es en ese momento que uno piensa "debería escribir sobre esto". Y heme aquí. Si sientes curiosidad por el comic al cual hago referencia, la entrada de la que hablo o el título de este post te provocó curiosidad, sigue leyendo...

¿Vas rápido o estás progresando? Rapidez no es lo mismo que velocidad.

Esta es la publicación de la que les hablaba. El primer reto vino al intentar traducirlo, ya que en español "speed" puede traducirse como velocidad y para muestra un botón, dejo a continuación la traducción que hace google translate:

¿Vas rápido o estás progresando? La velocidad no es lo mismo que la velocidad.

Así que me tocó investigar más para encontrar una traducción precisa. En este proceso tuve un momento de epifanía (que describiré con mayor detalle más adelante). En diversas fuentes que encontré, mencionan que ambos términos pueden ser utilizados como sinónimos junto con "celeridad", con lo cual concuerda google translate y en la práctica también solemos utilizar esos términos de forma intercambiable en las conversaciones diarias. De hecho,  la Real Academia Española define "Rapidez" referenciando a la palabra "Velocidad":

No obstante si revisamos estos términos desde un punto de vista de la física, hallaremos algo (en mi opinión) interesante. Desde esta perspectiva, las definiciones son las siguientes (según esta página):

***

Rapidez

La rapidez es una magnitud física escalar que expresa la distancia recorrida por un objeto en función del tiempo.

Para que lo entendamos mejor diremos que: las magnitudes escalares son aquellas que quedan completamente definidas por un número y la unidad de medida utilizada para su medición.

Por otra parte, la distancia recorrida por un objeto es la longitud de su trayectoria.

Veamos un ejemplo: 60 km/h es una rapidez. Significa que un objeto que se mueve, un automóvil por ejemplo, recorrerá 60 kilómetros por cada hora que esté en movimiento.

Velocidad

La velocidad es una magnitud física vectorial que expresa el cambio de posición (desplazamiento) de un objeto en función del tiempo.

Así pues, las magnitudes vectoriales son aquellas que para definirla, además de la cantidad expresada en números y la unidad de medida, se necesita indicar claramente la dirección y el sentido en que actúan.

Por otra parte, el desplazamiento se refiere a la distancia y la dirección de la posición final respecto a la posición inicial de un objeto.

Veamos un ejemplo: 60 km/h, en la dirección de la calle norte-sur, hacia el norte. En este caso hay tres datos: una rapidez (60 km/h), una dirección (calle norte-sur) y un sentido (hacia el norte).

***

Una forma interesante de verlo, es a través de esta comparativa que hallé luego de realizar una sencilla búsqueda de imágenes en google:

¿Y cuál es el punto?

Mi punto es el siguiente: en Scrum, cuando se pretende medir la velocidad de un equipo digamos por ejemplo en puntos de historia (o cantidad de historias para los que nos alineamos con #NoEstimates), lo que realmente se está midiendo es la rapidez del equipo. La prueba de ello es que la medida empleada es un escalar y una unidad de medida, por ejemplo: 75 puntos de historia por sprint.

El problema con esto es que si se mide solamente la rapidez, se puede incurrir en lo que describe perfectamente la siguiente caricatura de Dilbert y que lamentablemente he comprobado que con frecuencia sucede en la realidad:

Además la rapidez es una medida de producción o output y en mi opinión no deja de ser lo que Eric Ries, autor del libro Lean Startup llama una métrica de vanidad.

Entonces, ¿qué hago?

La respuesta corta es sencilla: deja de medir la rapidez del equipo y comienza a medir su velocidad. 

Claro, resulta fácil decirlo, pero en la práctica ¿cómo lo consigo? Bueno, primero que todo se necesita una dirección en la cual se desea avanzar. Para tener claridad en este aspecto, un artefacto que personalmente me encanta (si bien hay otros) es el Mapa de Producto Orientado a Metas o GO Product Roadmap. En este enlace se puede encontrar una descripción más completa del artefacto, para efectos de esta publicación me limitaré a comentar que es un canvas en el cual se definen los entregables de un producto a lo largo del tiempo, en función de 5 aspectos clave:

1. Fecha: momento del tiempo en el cual se planea disponibilizar el producto, puede ser un rango de fechas como por ejemplo "primer trimestre del año" o una fecha puntual como "4 de Mayo de 2019"; siendo mi preferencia la segunda opción (si se está haciendo Ágil bien,  en la fecha propuesta se debería contar sí o sí con un incremento de producto que agregue el mayor valor posible con el esfuerzo realizado).
2. Nombre: esto puede ser literalmente cualquier cosa, desde algo aburrido como v1, v1.1, v2.0, etc. hasta algo divertido como Decaf, Americano, Latte, Capuccino (estos eran los nombres de los entregables de un equipo del cual fui Product Owner y que realicé con unos amigos Colombianos - el café era nuestro punto de encuentro).
3. Meta: esta es la meta de negocio que se desea alcanzar y es lo más importante del artefacto, define cuáles son las agujas que se desea mover desde la perspectiva de negocio. Algunos ejemplos pueden ser: adquisición de nuevos usuarios, retención de usuarios, mejorar la experiencia del usuario, etc.
4. Características o Features: lista breve de las características necesarias en el producto para alcanzar la meta.
5. Métricas: cuáles son los indicadores que serán monitoreados una vez realizada la entrega que permitirán saber si se ha dado en el blanco, o se ha desviado hacia un lado, o se ha fallado completamente el tablero. Esto permite de paso entender si se tiene información del estado actual que permita utilizar a manera de benchmark más tarde, o si se debe comenzar por recopilar esa información de alguna forma. Cuidado acá de nuevo con el tema de las métricas de vanidad.

Ejemplo de un GO Product Roadmap para un juego de baile para niñas de 8 a 12 años en inglés.
Fuente: https://www.romanpichler.com/

En mi opinión (y me interesa conocer la de ustedes así que por favor comenten) creo que este artefacto nos da una muy buena idea de la dirección hacia la cual se desea avanzar a través de la definición de la meta del entregable y además nos brinda una idea sobre cómo medir el progreso a través de las métricas definidas.

Claramente, medir la velocidad del equipo en estos términos es más difícil y requiere de una mayor preparación y entendimiento del entorno (por ejemplo en la recopilación de la información necesaria para ser utilizada como benchmark). Además si no se tiene la disciplina y los mecanismos necesarios para realizar entregas continuas, se estará extendiendo el ciclo de aprendizaje lo cual no es deseable. Por ello recomiendo invertir en infraestructura que permita hacer entrega continua desde temprano en el proceso de desarrollo. De esta forma no se debe esperar hasta la fecha descrita en el GO Product Roadmap para comenzar apenas a medir la velocidad del equipo, lo cual sería caminar a ciegas durante toda la ventana de tiempo del entregable; sino que se puede hacer a todo lo largo del tiempo.

Conclusión

La forma en que tradicionalmente se mide la velocidad de los equipos en Scrum siempre me ha causado alguna incomodidad debido a que me parece engañosa, ya que la misma puede variar por una gran cantidad de factores:

• Familiaridad con alguna nueva tecnología que se desea incorporar
• Cambios en la configuración del equipo (nuevos miembros se suman y hay que invertir en su capacitación o alguna persona se retira del equipo por cualquier razón).
• Cambios de stakeholders y prioridades.
• Vacaciones, enfermedades y similares.
• Y una extensa lista de etcéteras más...

Además del riesgo de que el equipo esté avanzando muy rápidamente hacia el objetivo equivocado (o sencillamente deambulando sin dirección).

Y esta fue mi epifanía: lo que en el fondo me disgusta de esta forma de medir la velocidad, es que es una métrica de vanidad ya que realmente se está midiendo rapidez (no velocidad) lo cual es una medida de output, no de outcome. Y por lo tanto, en mi opinión, no es algo a lo que deberíamos prestarle mucha atención y quizá ni siquiera deberíamos invertir tiempo en ello. Desde un punto de vista Lean podría afirmar que es desperdicio.

***

Deseo finalizar agradeciéndoles por llegar hasta este punto (se que la publicación me quedó extensa) y compartiendo una frase que verdaderamente me inspira al punto que se ha convertido en uno de nuestros Principios Guía Simples en sINNplify (nuestra estrategia es un breve conjunto de PGSs) y que de alguna manera resume mucho de lo que quise decir con esta publicación...