Antes de nada, el objetivo del post NO es describir dinámicas sobre retrospectivas, digamos que se ha intentado aportar una visión diferente, más en el concepto que en el detalle de como hacer una dinámica, aunque tocamos este aspecto, que es clave y tiene muchísima importancia en este tipo de reuniones, el objetivo del post es otro.

Básicamente se ha planteado este enfoque por un tema clave y bastante habitual: las retrospectivas son una de las reuniones que más tiempo suelen ocupar, y en ocasiones, de las que menos productividad se extrae.

Esto, que debería ser justo lo contrario, sin embargo es una realidad en muchos equipos «agile», en especial en equipos con cierto volumen, o cuando hay varios equipos involucrados al mismo tiempo.

 

Introducción

Lo primero que deberíamos decir es que la diferencia principal de una retrospectiva con un sprint review es que no estamos revisando el producto, la entrega, estamos revisando que hicimos, que no hicimos, que hicimos bien, qué hicimos mal, qué deberíamos cambiar, etcétera.

O en otras palabras y de manera más sintética; la idea de la retrospectiva es bastante sencilla y prácticamente todo el mundo la puede englobar (con sus matices obviamente) en que esta busca como objetivo último la mejora continua.

Ahora bien, sobre qué y de qué manera se establece esa «mejora continua» , en esto ya no hay tanto consenso, las guías y documentos «oficiales» son bastante «amplias» al respecto con frases como:

«El equipo de Scrum identifica los cambios más útiles para mejorar su eficacia» ->> De la Scrum guide.

«Permite aprender de los conocimientos y experiencias adquiridas hasta el momento y mejorar de forma continua el proceso de desarrollo» ->> Del libro Agile methods.

«Los cambios siempre se aplicarán en el siguiente Sprint, por lo que cada mejora se verá reflejada a corto plazo, mejorando la productividad» ->> De la certificación de ScrumStudy.

Pero la realidad es que una retrospectiva suele ser una reunión donde el valor de la misma se difumina conforme el proyecto es cada vez más maduro, los motivos son varios; desde que el equipo tiene diferentes perfiles (junior, senior, cambios) o se sacan más y más features y no se le da tanto foco a la mejora continua, o cuando hay rotación y el equipo es muy desigual, etcétera, pero el principal problema en las retrospectivas es justamente este: el poco valor real que se suele aportar/percibir respecto al producto.

La cuestión es que se trata de un problema básicamente debido al modelo en si, se parte de un supuesto que no siempre se cumple (en la mayoría de las ocasiones no se cumple) el cual consiste en que los equipos son capaces de tomar decisiones de un gran calado (realizar cambios en cualquier parte del proceso de desarrollo, nada más y nada menos) y que afectan directamente a la planificación estratégica, tanto a nivel de mercado, como de producto, como en plazos, como en forma de trabajo, etcétera.

Este tipo de decisiones no es habitual que se dejen en manos de un equipo de desarrollo, suelen haber «CXX» que buscan consenso o bien directamente toman dichas decisiones (si es lo correcto o no, es otro debate y pienso que NO, no es correcto y además rompe con principios ágiles presentes no solo en scrum, sino en xp y otros) pero ahora únicamente estoy «retratando» mi experiencia.

Aun así se puede llegar a un consenso y a un punto constructivo dado que, lo que todo el mundo busca en una retrospectiva es:

  • Mejorar de manera continua la productividad y la calidad del producto que estamos desarrollando.
  • Analizar como se ha realizado el sprint y las posibilidades de mejora
  • El objetivo está centrado en la mejora del marco de trabajo usado actualmente.
  • Generar positividad y ganas de crear y cambiar cosas, no se buscan culpables, se buscan soluciones.
  • Que ha funcionado bien, que no ha funcionado, qué se debe cambiar.
  • Concepto de continuidad respecto al sprint anterior y al próximo.

Ahora, el cómo llegar y sobre todo la manera de llegar alcanzar estos objetivos (hay más objetivos obviamente, simplemente era un listado de carácter general) es el principal punto de controversia, y probablemente, la razón por la cual podemos encontrar muchísima más literatura sobre esto que sobre una daily (por poner un ejemplo).

Desarrollo

También, de un tiempo atrás menos, pero desde hace unos años (actualizado a 2020) cada vez más y más, se ven multitud de dinámicas de juegos, participación, y mil ideas super creativas (y en la mayoría de casos divertidas) de cómo desarrollar este tipo de reuniones, lo cual siempre aporta frescura e ideas nuevas, pero los enfoques y objetivos pueden ser distintos al usar ciertas dinámicas, dado que NO todas las dinámicas son iguales y por tanto NO buscan los mismos objetivos.

Pero claro, a mi me sale «la vena developer» y entonces pienso en deuda técnica, en valor del producto al negocio, en satisfacción de los usuarios del software,  la calidad desde puntos de vista como la automatización de tests o las arquitecturas emergentes y en la cantidad de cosas que se van quedado en el tintero.

En esas inercias a la hora de desarrollar (con todo lo que eso supone = requisitos, pruebas, arquitectura, código, UX, integración, deploy, etcétera, etcétera) es cuando pienso en que una retrospectiva, mucho más allá de la dinámica en concreto, la retrospectiva debería perseguir unos objetivos muy claros.

Y en este punto de nuevo volvemos a las frases abiertas:

«Las retrospectivas son el camino para la mejora continua de todo el equipo, sprint a sprint«

«El objetivo no es otro que la mejora de las técnicas usadas en el dia a dia por el equipo ágil«

» Se busca que el equipo se sienta mejor, promocionando la participación y reforzando el sentimiento de equipo«

Y que son correctas y estoy de acuerdo al 100%, solo que deberían poder centrarse en acciones muy concretas.

El problema de las acciones no concretas es que suelen, o ser muy abstractas, o bien afectan e impactan, y mucho, en la organización, en la forma de trabajar, etcétera, por eso (y por la dependencia de los equipos y la verdadera autonomia y autogestion de los mismos) hay que tener cuidado en cómo se manejan las expectativas de un equipo de desarrollo en este tipo de reuniones.

 

Otra situación muy habitual, es que (en el mejor de los casos) se consiguen llegar acuerdos y se corrigen aspectos de la actual forma de trabajo, lo cual está muy bien, el problema es; que esos aspectos que se suelen conseguir consensuar para un futuro cambio suelen ser pequeños detalles y no grandes temas del «core» del modelo de desarrollo, esto es un detalle importante dado que; por un lado las expectativas y frustraciones del equipo (de todo el equipo, no solo técnico, sino también producto, que no nos olvidemos es el foco de todo…) se pueden ver afectadas y por otro, que al tratarse de modificaciones en los modelos de trabajo pueden haber partes de la organización que sientan auténtico miedo al cambio.

Esto suele ocurrir porque las retrospectivas, en muchas ocasiones se plantean/perciben de una manera aislada e individual respecto a los ámbitos globales, tanto del proyecto como del producto, como si estuvieran ligadas únicamente al producto y al siguiente sprint (o aun, peor, como si fueran parte del «pasado»)  y no como una parte del proceso de cambio y mejora global.

Además, dicho cambio y ciclo de mejora ya sabemos que no se va a parar nunca, ni jamás los daremos por concluido y terminado (si no somos capaces de ver fallos y de ir mejorando y cambiando con el paso del tiempo… tenemos un problema o no estamos en el mercado).

Es por eso mismo que muchas veces, los acuerdos de cambio alcanzados en una retrospectiva no son todo lo efectivos que deberían, o al menos en lo que se espera inicialmente de ellos, esto último es una de las realidades más complejas de gestionar cuando hablamos de motivar a un equipo (y/o organización) y hacerle creer en «agile».

En cierta manera la idea de scrum tiene «parte de culpa» de esto, dado que deja muy centrada la idea de que las retrospectivas se realizan al final del sprint y que debe estar enfocada en el sprint.

Aunque es cierto que las mejoras son (o deberían ser) para el siguiente sprint, el concepto de proyecto como un todo, de cambio global, de inclusión en toda la organización, queda bastante atrás en muchas ocasiones, especialmente cuando hablamos de modificar de manera profunda una forma o un modelo de desarrollo.

 

Un idea potente de las retrospectivas debería ser:

Los cambios acordados en una retrospectiva van a impactar en la forma de trabajo de TODO el proyecto, producto y equipo.

Y no solo en el siguiente sprint y en el equipo de desarrollo, sino de manera GLOBAL y muy probablemente a toda la organización, tal vez por ello se deberían revisar los siguientes puntos independientemente de la dinámica.

    • Autogestión ¿hasta donde llega dicha autogestión?
    • Capacidad de decisión del product owner y/o del equipo.
    • ¿Es posible cambiar la forma de trabajo de manera autónoma por el equipo?
    • ¿En cuanto tiempo ¿próximo sprint? es posible realizar dichos cambios?

Obviamente lo más habitual es que algunas respuestas no sean tan ideales como se plantean en los libros y en los principios ágiles de Lean, XP, Scrum, etcétera.

Teniendo esto claro, lo que se debería tener en cuenta es básicamente la gestión de las expectativas del equipo (en especial respecto a cambios, tiempos para llevarlos a cabo, etcétera) o nos podemos encontrar con la situación de que las retrospectivas no generarán el valor deseado (ya se sabe que una cosa es el agilismo de libro o blog 😉 y otra la realidad).

Y por acabar con este punto, otro tema a tener en cuenta son el tipo de acción de mejora, una cosa es una acción paliativa y otra una correctiva, si al final las soluciones que salen y se aplican (que no siempre es tan sencillo, ni obtener soluciones y menos aún aplicarlas) se van quedando en el saco de las paliativas, el fantasma de la deuda técnica, de las malas prácticas y del estancamiento puede aparecer muy fácilmente.

 

Las dinámicas, los formatos y el modelo

Lo primero que deberíamos tener claro es que son cosas distintas aunque se pueden complementar entre ellas.

  • Una dinámica es una forma de trabajar para conseguir un objetivo concreto dentro de la retrospectiva (que hicimos mal,que cambiamos, que no, más de esto o de lo otro, etcétera).
  • Un formato es un guión y una manera de trabajar con unos pasos concretos (preparar, anotar, consultar, votar, medir felicidad, cierres, etcétera).

Como nota personal en todo esto y a riesgo de ser «crucificado», en mi opinión, las dinámicas muchas veces tienen demasiado peso y pueden convertirse en un auténtico problema en las retrospectivas, ojo que las dinámicas son necesarias e imprescindibles, es más, si las cosas se hacen de una manera más divertida y más «motivante» todo suele funcionar mejor, el problema es cuando la dinámica es la retrospectiva en sí misma.

Otro asunto que también es delicado, es el formato de la retrospectiva.

En esto, aunque hay unas ideas comunes (preparar, recoger información, gestionar expectativas, realizar acuerdos, cierre) también hay discrepancias, al final el mejor formato será el que cumpla con los objetivos de la retrospectiva, tal vez no sea necesario apuntarlo todo en una herramienta (o si), o los tiempos pueden ser más cortos, o simplemente se pueden clasificar las oportunidades de mejora para tratarlas después,,, opciones hay muchas pero al final si el formato se convierte en un dogma de trabajo y nos somos capaces de adaptar dicho formato conforme vayamos viendo que las «exigencias del guión» cambian… las retrospectivas no serán productivas y simplemente pasará como con las dinámicas.

Como notas básicas acerca las dinámicas, las hay tipo “star fish” o «fat boy», básicamente tratan mediante un diagrama con forma de estrella para crear áreas de cosas a tratar evitando así centrarse únicamente en lo bueno y lo malo, son técnicas que pueden resultar aburridas (especialmente cuando se han realizado una y otra vez) pero son bastante efectivas.

Otras técnicas como «el barco», «los sombreros», «las 4l», «daki», «MSG» y un sinfín de ellas, aportan diferentes escenarios y formas de acometer los objetivos de una retrospectiva.

Es una buena idea darles una leída, entenderlas y probar todas las posibles, entendiendo los beneficios que aporta cada una de manera concreta, y también los «gaps» o puntos donde la dinámica en concreto no nos aportará lo que buscamos.

Por último y para concluir con este apartado, lo lógico sería adaptar la dinámica y el formato a la situación real y el momento, me refiero a que en ocasiones deberíamos de cambiar de dinámica (incluso de formato) no solo por un mero tema de aburrimiento (que también) sino porque cada dinámica y la forma de abordarla aporta cosas diferentes en momentos diferentes y en eso somos nosotros (y de forma deseable el equipo también) los que debemos encontrar la mejor manera de realizar la retrospectiva.

Nuestra propuesta

La propuesta que hacemos es bastante sencilla, y amplia:

  • Céntrate en el producto, en el valor del producto

Las mejoras en los procesos de desarrollo son imprescindibles, pero con un foco muy claro = valor del producto, las acciones de mejora, los cambios, etcétera deberían ir centrados en eso y en nada más, esto incluye; desde las propuestas hasta las dinámicas y el contenido de la reunión.

  • Se realista, acepta cambios que puedas acometer

Esto es muy obvio, pero suele ser el mayor factor de frustración en las retrospectivas, entiende donde estas trabajando, cuáles son las realidades y actúa en consecuencia, no generes falsas expectativas ni provoques conflictos, muchas veces las estructuras empresariales son las que son, y hay que saber que, cuando y como se pueden acometer ciertos cambios.

  • Sal de la reunión con un objetivo de cambio claro

No hace falta (ni se puede) cambiar todo, pero si no sales con alguna propuesta realista y factible de cambio (aunque sea «pequeña») esa retrospectiva habrá sido «un brindis al sol» con un montón de ideas, abstracciones, propuestas, etcétera y horas de desperdicio.

  • Preocupate por el equipo

Son situaciones típicas, pero no por ello menos importantes o no dejan de suceder, por poner ejemplos típicos: que nadie se sienta atacado, que todo el mundo pueda participar de manera libre, que la crítica sea constructiva, que todo el mundo sienta que su opinión es importante, etcétera.

Pero ojo, que si tenemos un CEO, CTO o CXX, un modelo de negocio, leyes o cualquier cosa que marca una forma de trabajo, o parte de la misma, de una manera concreta y NO podemos cambiar esta circunstancia, no deberíamos dejar de hacer retrospectivas, rendirse nunca es una opción, pero pelear por causas perdidas tampoco, me refiero a que lamentarse y no obtener soluciones no aporta demasiado, aporta dado que es una manera de expresar y conocer el problema, pero hay que solucionar cosas, e invertir tiempo en lo mismo una y otra vez, si no crea soluciones es puro desperdicio, y por otro lado, estoy seguro de que por muy «a corriente» que sea la situación, siempre hay margen de mejora 🙂

  • El proceso de desarrollo tiene componentes técnicos, no lo olvides

Es muy sencillo, si no vemos que tenemos un problema de testing, o de integración,o de toma de requisitos,o de definitions of done o ready, o que no somos capaces de hacer buen código,o que no entendemos la parte funcional o cualquier parte del proceso de desarrollo más elemental, de nada nos servirán los colores, sombreros, barcos, cartas, coches, juegos o lo que quieras usar, la técnica en desarrollo es importante, se trata de computación y de código, obviamente para llegar no solo vale el codigo, pero sin código y requisitos en última instancia no tenemos producto.

 

Concluyendo

Si has llegado hasta aquí, es porque realmente te interesa el asunto, en realidad una retrospectiva puede servir para muchas cosas, que tenga unos objetivos iniciales no significa que no se pueden extraer cosas positivas e información útil, por ejemplo:

– Puntos de mejora detectados

  • Sobre el modelo de desarrollo de producto
  • Sobre el propio modelo de desarrollo

– Ideas de mejora presentadas

– Número de los procesos de desarrollo afectados.

– Métricas propias de la técnica Starfish (o la que se esté usando).

– Número de nuevos items (keep, more, less, doing, stop)

– Número de cambios en “las patas” (keep, more, less, doing, stop)

Y por último, centrarse en la dinámica es más divertido, pero no es más eficiente, por tanto, si no puedes elegir (lo ideal es una dinámica realmente divertida y resultados super concisos y concretos con valor) mejor una dinámica menos espectacular y resultados más efectivos.

 

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *