Esta es una práctica que fue popularizada por Scrum, pero cuyo uso se ha extendido ampliamente más allá de este marco. Es una práctica que apunta a la mejora continua, aunque el solo hecho de hacer retrospectivas no trae mejoras por sí mismo. En concreto, la retrospectiva es una herramienta que nos permite detectar oportunidades de mejora. Luego, si realmente queremos mejorar, deberemos accionar sobre esas oportunidades.
En mi libro Construcción de Software: una mirada ágil, hay un capítulo completo dedicado a esta práctica, pero hoy, viéndolo a la distancia (más de 10 años después de su publicación) y considerando cómo he ido variando mi forma de trabajar, creo que dicho capítulo no refleja la manera en que me gusta que fluyan las retrospectivas.
La retrospectiva se realiza con una determinada cadencia: puede ser cada dos semanas, una vez por mes u otra. Pero esa cadencia debe estar definida. He escuchado equipos decir «hacemos retrospectiva cuando consideramos que lo necesitamos»; eso no es válido, pues convertiría a la retrospectiva en una práctica reactiva cuando, en realidad, es una práctica proactiva. En lo personal, suelo trabajar en iteraciones semanales, con lo cual, al inicio del proyecto, suelo hacer retrospectivas todas las semanas; pero, una vez que el equipo entra en ritmo, suelo cambiar a una cadencia de dos semanas (obviamente, esto no es una definición mía, sino una sugerencia: finalmente es el equipo quien decide).
El resultado de una retrospectiva es un conjunto de «accionables realizables», es decir, cuestiones que podamos trabajar de aquí a la próxima retrospectiva. En lo personal, suelo sugerir no más de tres accionables.
La retrospectiva es una sesión de trabajo con un facilitador designado, que se encarga de prepararla. Sí, la retrospectiva hay que prepararla; no es una actividad improvisada. Al mismo tiempo, se espera que el facilitador esté 100% dedicado a la facilitación: llevar la sesión, moderar las interacciones, cuidar los tiempos, etc. El facilitador no es un participante más; incluso si el rol es ocupado por un miembro del equipo, esa persona «resigna» su derecho a opinar. Es por ello que, en ocasiones, se busca que el rol del facilitador sea asumido por alguien externo al equipo, una persona «neutral».
En la retrospectiva participan exclusivamente los miembros del equipo, quienes están en el barro del día a día, aquellos con los que nos vemos diariamente. En ocasiones surge la duda de si debe participar el Product Owner, mi respuesta es: depende. Si el Product Owner está en el día a día, entonces sí. Pero si el Product Owner interactúa esporádicamente con el equipo, viene a la planning/review y no mucho más, entonces yo me inclino a que no, eventualmente buscaremos otro espacio para hablar con él las mejoras del proceso que lo incumban.
Usualmente, la retrospectiva comienza con una actividad «rompehielos», cuyo objetivo es desacoplarnos de lo que veníamos haciendo y entrar en la sesión con confianza y la mente despejada.
Luego, hacemos el repaso de los accionables surgidos en la iteración anterior (obviamente, en la primera retrospectiva no hay accionables previos): ¿los cumplimos?, ¿resultaron útiles?
Así llegamos al punto central de la retrospectiva, donde típicamente repasamos lo que hicimos bien y lo que no hicimos tan bien (por no decir «las cagadas»). Para esto existen distintas dinámicas (muchas de ellas documentadas en el libro/sitio Fun Retrospectives de Paulo Caroli). En general, todas las dinámicas incluyen un momento de brainstorming. Si estamos haciendo la retrospectiva de forma presencial, muchas veces el brainstorming implica el uso de post-its. Esto permite que cada persona pueda expresarse libremente en dos sentidos:
- Sin verse influenciado por lo que digan los demás.
- Manteniendo el anonimato (aunque, si realmente somos un equipo, nadie debería tener miedo de expresarse).
Si estamos en una sesión virtual, buscaremos utilizar alguna herramienta que nos permita emular una experiencia análoga. Algunos equipos utilizan herramientas colaborativas «genéricas», como Miro o Google Slides. En lo personal, prefiero utilizar herramientas específicas para retrospectivas, como ser EasyRetro o Retrium.
Luego pasaremos a una fase de convergencia, para lo cual analizaremos lo surgido del brainstorming, identificando cuestiones (post-its) repetitivas o recurrentes. Precisamente, si tenemos cuestiones que se repiten (varios post-its mencionando lo mismo), eso nos está indicando la relevancia de esa cuestión. Sin embargo, puede ocurrir que la cosecha sea más dispersa y no encontremos cuestiones repetidas. En ambos casos, deberemos priorizar sobre qué cuestiones trabajar, ya que, como mencioné previamente, la cantidad de accionables debería ser acotada.
Para esto, lo que suele hacerse es votar abiertamente sobre qué cuestiones trabajar. Una vez identificadas las cuestiones más prioritarias, pensaremos en conjunto las acciones a tomar. En todo este proceso es importante el rol del facilitador, guiando la dinámica, manteniendo el foco del equipo y cuidando los tiempos.
Una vez definidos los accionables, debemos registrarlos. En algunos casos, si usamos una herramienta digital, puede que ya queden allí; de lo contrario, yo suelo utilizar la wiki del proyecto.
Finalmente, hay ocasiones en las que se realiza un cierre de la retrospectiva, por ejemplo, pidiendo a los participantes que evalúen la sesión.
Blog de NicoPaez 