Retrospectivas ≠ Mejora Continua
Por Hiroshi Hiromoto, @hhiroshi
Etiquetas: retrospectivas, mejora continua, kaizen
Mi descubrimiento sobre las retrospectivas
En mi primer contacto con Agile, y en particular, con el Agile Manifesto, lo que más me resonó fue el doceavo principio, este dice:
"A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia." [Agile Manifesto]
A partir de ese momento, encontré en Agile un puente entre la pasión que tengo por mejorar continuamente cualquier aspecto de mi vida y mi trabajo, que en esa época estaba relacionado a la construcción de software.
Casi en simultáneo, descubrí Scrum y su famosa ceremonia llamada la retrospectiva, que podemos definirla como:
"Una reunión donde un equipo se junta para realizar una introspección de su forma de trabajo en busca de generar acciones de mejora."
Inmediatamente la reconocí como la ceremonia más valiosa. De ahí en adelante profundicé mi conocimiento sobre esta reunión en particular: leí libros, aprendí técnicas, facilité muchísimas retrospectivas y ayudé a equipos a mejorar las suyas.
La promesa de las retrospectivas
Si revisamos la guía oficial de Scrum, nos encontraremos que el propósito de la retrospectiva se define como:
Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras.
Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.
Y adicionalmente, en conversaciones, charlas y conferencias es muy común escuchar definiciones alternativas como:
Generar mejora continua en Scrum
Lograr que el equipo mejore continuamente
Ser el motor de la mejora continua
Es en este paradigma, donde encuentro la imposición de una promesa que las retrospectivas están asumiendo, sabiendo que son incapaces de cumplirlas. En mi opinión para generar mejora continua se requiere kaizen, que Masaaki Iman define como:
"Una estrategia para ganar a través del desarrollo de las personas" [Imai 1995]
Lamentablemente, las retrospectivas están lejos de ser una estrategia.
La retrospectiva es solo una reunión de planificación
La palabra "solo" no busca darle una connotación despectiva a reunión sino que busca incidir en una realidad que, tengo la seguridad, es congruente con las retrospectivas en las que han podido participar u observar. Cabe resaltar que no me refiero al mundo de las retrospectivas mal facilitadas, sino que hasta la retro perfecta es una reunión de planificación.
Para introducir la idea me parece importante compartir un paralelismo entre el ciclo Shewhart o PDCA y la reunión de retrospectiva. Las siglas de PDCA corresponden a:
P: Planificación (Plan). En esta etapa se planifica la mejora que se quiere realizar. Se plantea una hipótesis.
D: Ejecución (Do). En esta etapa se ejecuta el plan diseñado en la etapa anterior.
C: Revisión (Check). En esta etapa se revisa el resultado del experimento y se lo compara con el resultado esperado en la hipótesis.
A: Ajustar (Act). En esta etapa se capitaliza el aprendizaje generado en el ciclo de experimentación y se acciona según el aprendizaje.
El ciclo de Shewhart ha sido usado históricamente para buscar mejorar continuamente procesos desde el año 1920, y ha conformado la base de esquemas más modernos.
Si tratamos de hacer una comparación entre la retrospectiva y el ciclo PDCA nos encontraremos que la retrospectiva refleja la etapa de planificación del ciclo (la P) y deja de lado la ejecución, revisión y ajuste.
Adicionalmente al problema sobre que la retrospectiva es una reunión de planificación con una promesa que no puede cumplir (es inviable desde solo la planificación), tenemos que añadirle que en los últimos años hemos estado obsesionados con esta planificación.
La obsesión en el plan está entre nosotros
Artículos con títulos como "10 tips para mejorar tus retrospectivas"o libros con “25 técnicas innovadoras para facilitar retrospectivas” o la típica pregunta del Scrum Master sobre ¿Cómo hacer las retrospectivas más divertidas? son solo algunos ejemplos del nivel de obsesión que tenemos con esta reunión de planificación y el plan que resulta de ellas.
Lo curioso de esto es que muchos de los que practicamos Agile compartimos un discurso en donde se pondera más el software funcionando (o la generación de valor, en estos tiempos más modernos) que los documentos y planes. Sin embargo, en el tema de la mejora continua de nuestra forma de trabajo seguimos encasillados en cómo generar mejores planes o planificaciones que en mejoras funcionando (o aprendizaje capitalizado).
El foco tan intenso en el plan hace que perdamos foco en otras cosas como en la ejecución del plan o aún peor en la capitalización del aprendizaje de esa ejecución.
Este patrón de sobre-foco, únicamente en la retrospectiva, lleva a muchos equipos, a perder el interés en las retrospectivas, al tildarlas de improductivas, aburridas e innecesarias. Y como daño colateral, una pérdida de interés en la mejora en general.
"Las retrospectivas son inútiles"
La anterior es una frase que he escuchado más de lo que me gustaría, usualmente es mencionada por miembros de equipos que están atrapados en retrospectivas mal facilitadas o retrospectivas cuyos planes quedan solo en planes.
Si me hubieran preguntado qué opinaba sobre esa frase hace tres años atrás mi respuesta hubiera estado orientada a que el problema es cómo estaba siendo llevada esa retrospectiva. Hoy en día, soy consciente de que la frase es verdad, "las retrospectivas son inútiles" si no generan cambios, y esos cambios no se generan en las retrospectivas.
Es por ello que en lo que resta del capítulo los invito a soltar nuestra obsesión por la planificación y a centrarnos más en la ejecución y el aprendizaje asociado.
Foco en la experimentación
El cambio se genera en el momento en el que se modifica un comportamiento (ejecución), por lo tanto, me gustaría hacer un pequeño cambio y sustituir ejecución por experimentación. La principal razón es que cuando uno experimenta deja explícito que el plan que generó es más una hipótesis que una receta certera y nos obliga, no sólo a comenzar a hacer foco en ejecutar los planes, sino a revisar el impacto de los mismos.
Es así que cuando decimos que vamos a centrarnos más con la experimentación, esto incluye la búsqueda de formas en cómo facilitar:
La ejecución de las hipótesis
La validación de los resultados del experimento (la diferencia entre lo que esperaba y lo que pasó)
El descubrimiento del aprendizaje generado y la forma en cómo concretar el mismo (capitalización de aprendizaje)
Esta visión nos permite no sólo complementar las retrospectivas para, ahora sí, generar mejora continua, sino también nos permite encontrar en las retrospectivas el gatillo** perfecto para generar ciclos de experimentación. Esto último se vuelve fundamental a la hora de lograr la parte "continua" de la mejora continua.
Los hábitos y sus gatillos
La posibilidad de ver a las retrospectivas como gatillos, nos abre la puerta al mundo de la generación de hábitos, y es el último ingrediente para poder cumplir la promesa inicial de "generar mejora continua en Scrum", es decir, lograr que el equipo mejore continuamente o ser el motor de la mejora continua.
La estructura de los hábitos está definida de la siguiente manera según Charles Duhigg [Duhigg 2012]:
Un gatillo
Una acción
Una recompensa
Es así que podemos usar a la retrospectiva como gatillo para accionar la ejecución de un experimento y lo que nos estaría faltando es generar una recompensa para cerrar el círculo.
Invitación
Para finalizar este capítulo les quiero hacer una invitación a que evalúen su nivel de obsesión con las retrospectivas y destinen un poco de ella a valorar más el experimento sobre el plan, y otro poco a facilitar la generación de hábitos para lograr continuidad.
Last updated