“El dolor de hoy es el éxito del mañana”. Esta frase suena como una enseñanza de autoayuda, pero está vinculada a un valor esencial en los métodos ágiles: ¡La mejora continua!
Para explorar este tema, decidí incluir otras frases clave:
“¡Los métodos ágiles no resuelven los problemas, sino que los exponen!”
La exposición de los problemas es lo que estamos buscando cuando aplicamos los métodos ágiles. Los métodos no resuelven los problemas, son las personas quienes los resuelven. Al darles visibilidad, las personas pueden: involucrarse en la discusión, debatir la causa raíz, proponer experimentos para solucionar el problema, metrificar, etc. Valoramos la gestión visual, por ello son tan comunes los postits en la pared.
“¡El problema tiene que doler!”
A menudo vemos empresas que implementan prácticas para absorber los problemas en lugar de eliminar la causa raíz. He aquí algunos ejemplos:
Ejemplo 1: “Tenemos un problema de calidad, así que vamos a montar un equipo de calidad.”
Eso no resuelve la causa raíz. Es más, disimular el verdadero problema hace que la situación dure para siempre. Cuando hay un equipo de calidad, los otros equipos pueden “relajarse” y tal vez la calidad se reduzca aún más. Es un clásico ejemplo de un ciclo negativo, derivado del disimulo del problema.
Ejemplo 2: Otro ejemplo relacionado con la calidad que típicamente ocurre en TI: lista de bugs. La lista de bug es una manera de absorber el problema sin causar el dolor que provocaría interrumpir lo que estamos haciendo y corregirlo inmediatamente. A corto plazo parece razonable, pero como no duele, es muy conveniente simplemente colocar bugs en la lista y “algún día lo resolveremos”. Nuevamente, un ciclo negativo puede surgir de la acumulación de bugs. La acumulación puede ocurrir porque creamos más bugs de los que corregimos, o no hacemos una discusión de causa raíz, o bugs que surgen como consecuencia de bugs anteriores, o una combinación de estos factores.
Ejemplo 3: Release train. Hay una parte de la comunidad ágil que defiende la existencia de un ciclo largo para la liberación sincronizada de una nueva versión (release). Pero ahora buscamos ciclos cada vez más cortos en métodos ágiles para obtener resultados completos, que agreguen valor y recopilen un feedback real. Está claro que en las grandes organizaciones, las dependencias entre los equipos son un gran dificultador, por lo que debemos enfrentar este problema. Sin embargo, los “release trains” de 3 meses que algunos defienden, justamente ocultan esos problemas de dependencia. En lugar de hacer frente y resolver el problema, una vez más estamos creando mecanismos para convivir con él.
“Fail fast, learn faster”
El objetivo no es hacerlo bien a la primera, sino hacer que en la próxima iteración sea aún mejor. Comprender que cada sprint es un experimento y que queremos validar el avance en cada iteración. Saber cómo mejorar es más importante que hacerlo bien a la primera (como en matemáticas, la derivada es más importante que el valor de la función). Es decir, creemos mucho más en la capacidad de reacción que en el intento de perfección.
“¡El dolor de un sprint puede significar el éxito del siguiente!”
En Scrum, hay dos reuniones muy importantes al final de cada sprint, dirigidas a la mejora continua: review y retrospectiva.
Review es el momento de recibir feedback sobre lo que se hizo en el sprint. Es la cúspide del ciclo Scrum, ya que es el momento más placentero, cuando estamos ansiosos por ver la reacción de las personas a nuestro progreso. El feedback no siempre es positivo. Ej.: “está faltando esto” o “sin eso no podemos lanzar”. En ese caso, debemos usarlo como un impulso para el éxito del próximo sprint. Así que hagamos ‘esto’ o ‘aquello’. De esta manera lograremos el éxito.
En retrospectiva, la reunión más importante de Scrum es cuando discutimos las mejoras para todo lo que está más allá del producto: personas, procesos, colaboración, etc. Si hay una frustración en el equipo, con una buena facilitación, esa frustración se manifestará en la retrospectiva. Tenemos que usar esto como un resorte de impulso en la búsqueda de esta mejora.
Por lo tanto, vale la pena reforzar la frase inicial, que sirve para toda la vida:
¡El dolor de hoy es el éxito del mañana!
Si quiere convertirse en un Scrum Master o Product Owner, le invito a participar en los cursos de formación de Certified Scrum Master (CSM) y Certified Scrum Product Owner (CSPO).
