La Retrospectiva remota

En mi anterior post, te hablaba de la retrospectiva como herramienta eficaz en la búsqueda de la mejora continúa de un equipo y ya te comentaba mi intención de ahondar hoy en el tema a través de mi experiencia práctica sobre cómo estoy llevando ahora a mismo acabo dicha ceremonia de forma totalmente remota ya que debido a la pandemia de COVID-19, todo el equipo estamos trabajando desde casa.

Además, otra peculiaridad del proyecto en el que nos encontramos es que, si bien es cierto que existen una serie de prácticas propias del mundo Agile, estas son muy básicas. Principalmente se reconoce la entrega continua como punto fundamental de la estrategia de realización del proyecto. También se definen historias de usuario, un backlog y se prioriza pero tenemos un gran espacio de mejora a la hora de aplicar prácticas y metodologías dentro del equipo de desarrollo.

Entre ellas, no se estaba realizando ninguna clase de tarea de introspección al acabar los "sprints" y mucho menos se reservaba un tiempo específico para esta tarea.

En la retrospectiva típica (si es que eso existe), en un periodo de una o dos horas, todo el equipo se reúne y sigue las fases que definíamos en el anterior post. Sin embargo, en las últimas semanas he tenido la oportunidad de probar un formato ligeramente diferente... debido al contexto concreto de mi equipo.

Y es que, a pesar de estas circunstancias, no queríamos dejar pasar la posibilidad de sacar aprendizajes periódicamente y, aprovechando que el proyecto mantiene un ciclo de entregas de dos semanas, quería instaurar algún tipo de práctica retrospectiva con esta periodicidad, donde pudiésemos obtener feedback y aprender de él.

Así, e inspirado por experiencias similares que había leído (como esta), decimos instaurar como experimento una mini-retrospectiva, cada 2 semanas, de media hora de duración, pero que sólo cubra los dos últimos pasos que describía en la estructura típica de una retrospectiva, es decir, filtrado y acciones a realizar.

La obtención de información que alimente estas dos fases, la hacemos en un documento compartido, los dos últimos días del sprint y cada uno cuando puede. Hemos transformado un evento principalmente síncrono, en uno asíncrono o al menos parcialmente asíncrono.

La estructura del documento es muy sencilla y os dejo por aquí un ejemplo.

## 18/12/20

🎉 ¿Qué ha ido genial?

🤔 ¿Qué no estamos haciendo genial y podríamos mejorar?

🆕 Posibles acciones y experimentos (especialmente que "ataquen" a los puntos 1
y 2)

Como ves, rellenarlo es rápido y directo. Esto es de forma intencionada puesto que no pretendemos convertir esto en una actividad burocrática, todo lo contrario; queremos que rellenarlo sea una excusa para una reflexión personal que sirva de gasolina para una posterior reflexión grupal. Queremos que la mayoría del tiempo lo podamos dedicar a pensar, no a escribir.

El documento, está dividido en 3 partes diferencias.

Verás que se habla de "genial". No es una coincidencia, buscamos detectar aquello realmente bueno, aquello que podamos localizar como una de nuestras principales destrezas. Seguro que hacemos otro montón de cosas bien, regular o mal, pero usamos la palabra genial para enfatizar nuestra voluntad de mejora de todo aquello que consideramos que no hemos "perfeccionado". Evitamos la palabra "perfección" porque creemos que muchas veces lo perfecto puede ser enemigo de lo bueno. Queremos alcanzar cierto grado de calidad y eficacia en lo que hacemos, para dar lo mejor de nosotros mismos, pero no queremos tampoco perder el foco y obsesionarnos con la perfección absoluta.

Principalmente diferenciamos dos categorías: lo "genial" y lo "no genial y que podemos mejorar". Aquí también intentamos delimitar nuestro radio de atención, centrándonos en aquello que creemos que podemos mejorar. Es decir, nos focalizamos en detectar nuestros puntos de mejora.

En ambas categorías, intentamos pensar en causas sobre efectos. Entregar trabajo sin errores, es sin duda un resultado genial, pero nos interesa mucho más saber por qué estamos entregando sin errores. Tal vez sea porque hacemos tests de calidad o porque hemos implementado nuevas técnicas y metodologías. Lo mismo ocurre con nuestros ámbitos de mejora.

Por último, tenemos un apartado de acciones y experimentos o bien para perpetuar aquello que hacemos "genial" o bien para mejorar aspectos que no hacemos tan bien y podríamos hacer mucho mejor. "Acciones" y "Experimentos", aunque podríamos emplear una palabra como sinónimo de la otra ya que cualquier experimento es práctica y lleva una acción asociada y al revés, todas las acciones que proponemos, las planteamos como posibles soluciones a un problema que hemos detectado pero conscientes de que pueden ir bien o mal. Explicitamos ambos términos para recordarnos a nosotros mismos estas características en nuestras propuestas.

Conclusiones

Hasta ahora (llevamos 2 retrospectivas - 1 mes en el momento en el que escribo esto), creo que los resultados que estamos obteniendo son muy satisfactorios. Hemos implementado un ciclo de feedback, que el equipo valora positivamente y que nos ha permitido mejorar ostensiblemente problemas que habíamos detectado o incluso mitigar riesgos que veíamos si mirábamos a lo lejos.

No es una particularidad de esta clase de retrospectivas, pero creo que un equipo, con las herramientas y confianza adecuada, son un motor de mejora continua increíble. Nadie mejor que ellos, conoce los problemas con los que conviven día tras día y, a menudo, plantean alternativas y soluciones muy concretas y precisas. Creo que las retrospectivas simplemente formalizan y aprovechan esta gasolina y la convierte en energía.

Sin embargo, no siempre es fácil encontrarle un hueco a esta práctica si tu proyecto no es Agile. Para ello, he encontrado muy positivo el uso de esta variante de retrospectiva, que minimiza el tiempo conjunto, anticipando las etapas de prospección.

Llevarlo a cabo es de lo más sencillo: crear un documento de texto y compartirlo con todo el equipo.

Por lo tanto, te lo recomendaría si estas en un contexto similar al nuestro como experimento para ver si funciona en tu equipo. Si lo haces, por favor, contacta conmigo y cuéntame tu experiencia.

Un saludo,

Ricardo