La Retrospectiva como principal fuente de mejora continua

El Manifiesto Agile, pone encima de la mesa una serie de valores y principios que después distintos frameworks incluyen con prácticas concretas dentro de las metodologías que definen. Dentro de este "marco" mental, un tema central es la mejora continua para la que se invita a hacer ejercicios periódicos de introspección que nos permitan, como equipo, ver qué podemos mejorar e, igual de importante, cómo vamos a abordar y priorizar esas mejoras.

Todas las prácticas agile incorporan este concepto de retrospectiva y creo que es una mentalidad muy beneficiosa para todos los actores implicados.

En la gestión de proyectos tradicional, existe el concepto de post-mortem como un ejercicio retrospectivo para analizar qué ha ido bien y qué ha ido mal en el transcurso del proyecto que acaba de terminar. La idea es sacar lecciones aprendidas que podamos aplicar a futuros proyectos.

Sin duda, es una buena iniciativa, pero a mi juicio es insuficiente. ¿Por qué esperar a que un proyecto termine para sacar conclusiones que nos permitan mejorar? ¿Por qué no hacerlo periódicamente durante el transcurso del proyecto para sacar aprendizajes que podamos llevar a cabo desde ya mismo, en este mismo proyecto, pudiendo revertir situaciones negativas actuales?

Aunque mi experiencia se encuentra en el dominio del software, piensa en gestión de proyectos no necesariamente tecnológicos.

Seguramente, la respuesta a esta pregunta venga derivada directamente de la propia metodología de trabajo seguida. Si no validamos el trabajo realizado hasta el final del proyecto, es difícil evaluar la consecución de objetivos antes de este momento y, por tanto, trazar una linea entre nuestras acciones y los resultados de dichas acciones en los objetivos que nos marcamos. Simplemente no tenemos indicadores intermedios que nos permitan evaluarnos con ojo crítico.

Aquí, de nuevo podemos recurrir al paradigma Agile, que defiende una entrega de valor iterativa y continua, durante periodos de tiempo consecutivos que frameworks como Scrum llaman "sprints".

Agile trae consigo muchos beneficios pero también requiere compromisos por parte de todas las personas involucradas en el proyecto, que requieren un cambio de mentalidad enorme y no siempre vamos a poder conseguir.

Mi recomendación, tras haber sufrido esta situación, es que sólo hagas Agile si todas las partes entienden y aceptan sus consecuencias. Cada vez está más aceptado este cambio de mentalidad pero ni mucho menos está generalizado, o al menos, esa es mi experiencia en España después de haber trabajado con varios proveedores, sectores y clientes.

Muy importante, y aunque suene a Capitán Obvio:

• No digas que haces Agile si no lo haces estrictamente.
• No llames Agile a lo que no es Agile.

Esta opinión, es polémica dentro de la industria del agilismo y cuenta por supuesto con sus detractores que la tachan de actitud sectaria o extremista. Yo discrepo con quienes opinan así: estoy encantado con que cada vez más personas se apunten al carro e introduzcan prácticas Agile en su día a día aunque sea de forma parcial porque creo que es una evolución correcta que les traerá múltiples beneficios en su día a día, pero creo que debemos ser rigurosos al respecto. Llamar "Agile" a lo que no es Agile, nos lleva a distorsionar el término hasta el punto de desconocer realmente sobre qué aplica. Así, nos encontramos con conversaciones del tipo:

• "¿Tienes experiencia haciendo Agile?"
• Sí, ¡claro!
• Pero, ¿Agile de verdad?
• Si bueno, todas las mañanas nos juntábamos y hacemos dailies.

Eso, no es Agile. Eso es introducir alguna práctica Agile dentro de tu día a día y está genial si te sirve de algo, pero creo que es importante ser riguroso en el uso del lenguaje, sino creo que corremos el riesgo de estar llamando por el mismo nombre a cosas muy distintas, convirtiendo cualquier conversación al respecto en fuente de malentendidos.

Dejando a un lado cuestiones terminológicas, creo que las retrospectivas es una de las prácticas Agile más interesantes y de las cuales cualquier proyecto puede obtener más beneficios. Como decía, si ya estas siguiendo una metodología Agile, seguro que ya estás llevando a cabo esta práctica pero incluso si no es así, creo que merece la pena su inclusión al igual que cada vez más equipos hacen dailies aún estando en un proyecto con metodología tradicional.

Las retrospectivas se pueden realizar tanto en formato presencial como en remoto, adaptando su contenido a las particularidades del formato. Además, existen productos específicos que pueden ayudarte a su confección y ejecución como EasyRetro.io.

Por normal general, la estructura de una retrospectiva es bastante sencilla:

• Calentamiento: esta fase está pensada para que todo el mundo se sienta más cómodo y dispuesto a participar, aportando su opinión.
• Búsqueda de información: cada uno aporta su punto de vista sobre lo que ha ido bien, lo que no y posibles puntos de mejora.
• Filtrado: la fase anterior dará lugar a mucho feedback, posiblemente más del que podréis procesar en una sesión. En estos casos, es importante que prioricéis y os focalicéis en aquello que consideráis más urgente.
• Acciones a realizar: localizar puntos fuertes y débiles no es suficiente, deberéis ir más allá, planteando acciones concretas para aprovechar vuestras fortalezas y minimizar vuestras debilidades.

Habitualmente, las retrospectivas duran un periodo de tiempo entre 30-45 y 120 minutos, donde a través de una serie de dinámicas, juegos y actividades se progresa de una fase a otra. Precisamente, una de las principales barreras de entrada que nos solemos encontrar es seleccionar estas dinámicas que permitan fijar un ambiente adecuado para que el equipo esté relajado y participativo.

Si quieres empezar pero no sabes cómo, personalmente encuentro de gran utilidad esta página web que me permite confeccionar retrospectivas de una forma sencilla con gran variedad de dinámicas disponibles de forma totalmente gratuita.

Creo que es fundamental generar un clima donde cualquier persona se sienta cómoda a la hora de señalar puntos positivos y negativos como equipo y su repercusión en el día a día del mismo, intentando evitar la crítica personal si es posible. Igualmente importante es que las soluciones salgan del equipo como conjunto puesto que seremos todos nosotros los que tendremos que llevarlas a cabo.

Por último, uno de mis errores cuando empecé a facilitar esta clase de ceremonias y que creo que es muy común es abandonar las sesión sin tener claras las acciones a llevar a cabo. Debemos identificar y comprometernos con actividades concretas que sean realizables y medibles. Además, deberemos llevar un seguimiento de su cumplimiento.

En el próximo post, me gustaría compartir contigo cómo hemos empezado a afrontar durante los últimos meses (marcados por el contexto de pandemia que nos hace trabajar a todo el equipo en remoto) estas retrospectivas dentro de un proyecto que no sigue ninguna metodología Agile concreta con el objetivo de buscar la tan mencionada mejora continua.

Te espero allí. Un saludo,

Ricardo