Retrospectiva Asíncrona
Una Retrospectiva Asíncrona es una retrospectiva que se realiza por escrito a lo largo de varios días o semanas en lugar de en una reunión: los integrantes del equipo añaden sus observaciones a un issue o documento compartido cuando les viene bien, y una persona moderadora guía la discusión escrita hasta llegar a acciones. El ejemplo mejor documentado es GitLab, cuyo manual recomienda recoger el feedback de la retrospectiva de forma asíncrona en un issue y añadir una videollamada en vivo solo cuando una iteración ha sido difícil. El formato es adecuado para equipos repartidos en distintas zonas horarias y deja un registro escrito y enlazable.
Guion de facilitación
- 1
Persona moderadora: abrir el issue o documento a partir de la plantilla al inicio de la iteración, añadir contexto y enlaces, fijar una fecha límite y anunciarlo en el chat.
10 min - 2
Cada participante: añadir comentarios bajo las preguntas durante la iteración, a medida que ocurren las cosas. Esto se reparte a lo largo de días o semanas.
15 min - 3
Persona moderadora: leer todas las aportaciones, hacer preguntas aclaratorias y agrupar los comentarios relacionados. Enviar un recordatorio a quienes no han aportado.
15 min - 4
Todos: responder en los hilos para identificar patrones y causas.
10 min - 5
Todos: proponer acciones y votarlas. La persona moderadora asigna responsables y fechas.
10 min - 6
Videollamada en vivo opcional para tratar lo que necesite conversación, ofrecida en dos horarios si hace falta.
20 min - 7
Persona moderadora: dar las gracias a quienes aportaron, escribir el resumen y publicar las notas.
10 min
Consejos
Abrir el issue al inicio de la iteración; cuando esta termina, la gente ya ha olvidado los detalles.
La persona moderadora tiene que estar activa por escrito: hacer preguntas de seguimiento, conectar comentarios relacionados y mencionar a quienes no han aportado.
Si quiere participar en el contenido, debería decir que comenta como participante o ceder la moderación a un colega.
La crítica escrita se lee más dura que la crítica hablada, así que conviene pasar un hilo a una llamada en cuanto se vuelva tenso.
Errores comunes
Abrir el issue solo cuando la iteración ha terminado. Los comentarios llegan tarde y son escasos porque la gente ya ha pasado al siguiente trabajo
No tener una persona moderadora activa. Los hilos se quedan en el nivel de los hechos y las quejas y nunca llegan a las causas ni a las decisiones
Dejar por escrito un desacuerdo acalorado, donde se intensifica y queda registrado. Pasarlo pronto a una llamada
Acciones sin responsable ni fecha. Cada retrospectiva escrita repite entonces la anterior y la participación cae
Tomar el silencio por acuerdo. Por escrito es fácil saltarse el issue por completo, así que a las voces que faltan hay que preguntarles directamente
Variaciones
Los equipos sin gestor de incidencias pueden usar un documento compartido o una pizarra digital con una sección por pregunta. Una versión híbrida recoge las aportaciones de forma asíncrona y usa una llamada de 30 minutos solo para generar hallazgos y decidir acciones. GitLab también describe la opción de no grabar la llamada en vivo y de celebrarla sin los jefes directos presentes, cuando eso ayuda a que la gente hable con libertad. La agenda de introducción, recogida de datos, generación de hallazgos, decisión sobre qué hacer y cierre sigue el modelo de fases del libro 'Agile Retrospectives' de Esther Derby y Diana Larsen.
Casos de uso
Cuándo usarlo
Los integrantes del equipo trabajan en zonas horarias con poco o ningún solapamiento
Las retrospectivas en vivo están dominadas por unas pocas voces y otras personas aportan con más facilidad por escrito
Se quiere un registro en el que los comentarios enlacen directamente a los tickets y cambios a los que se refieren
El equipo ya trabaja principalmente por escrito y está acostumbrado a discutir en hilos de comentarios
Las iteraciones son lo bastante largas como para que la gente olvide los primeros acontecimientos antes de una reunión de cierre
Cuándo no usarlo
La iteración fue mal o hay conflicto en el equipo. Hacer una retrospectiva en vivo, porque el tono y la emoción no se transmiten bien en hilos escritos
El equipo es nuevo y la confianza es baja. Hacer primero retrospectivas en vivo, por ejemplo Mad Sad Glad, y pasar a la escritura más adelante
El equipo comparte ubicación y puede reunirse con facilidad. Una retrospectiva de sprint habitual es más rápida y genera más conexión
Nadie tiene tiempo para moderar por escrito. Sin una persona moderadora, el issue se llena de comentarios y no llega a conclusiones
Los integrantes del equipo no se sienten cómodos escribiendo en el idioma de trabajo del equipo, lo que los silencia más de lo que lo haría una reunión
Métodos relacionados
Preguntas frecuentes
¿Qué es una Retrospectiva Asíncrona?▾
Una Retrospectiva Asíncrona es una retrospectiva que tiene lugar por escrito durante un periodo de días o semanas en lugar de en una única reunión. Los integrantes del equipo añaden qué salió bien, qué salió mal y qué se podría mejorar a un issue o documento compartido cuando les conviene. Una persona moderadora guía la discusión hasta llegar a acciones y a un resumen publicado.
¿Cómo hace GitLab sus retrospectivas de forma asíncrona?▾
El manual de GitLab recomienda usar un issue, basado en una plantilla de retrospectiva, para recoger el feedback de forma asíncrona, de modo que cada persona pueda pensar y escribir a su ritmo. Una publicación de 2019 del engineering manager Sean McGivern describe pipelines programados que crean el issue automáticamente el primer día de cada mes y más tarde añaden la lista de elementos entregados y retrasados. Después, el engineering manager publica las notas relevantes.
¿Una retrospectiva asíncrona sigue necesitando a alguien que facilite?▾
Sí. La pauta de GitLab es que toda retrospectiva tenga una persona moderadora imparcial, normalmente quien dirige el equipo, que guíe la conversación siguiendo una agenda clara. Por escrito, esto significa hacer preguntas de seguimiento, enlazar comentarios relacionados y empujar los hilos de las observaciones a las decisiones. Sin ese rol, el formato produce una lista de comentarios sueltos.
¿Cuándo conviene añadir una llamada en vivo?▾
Conviene añadir una llamada después de una iteración especialmente dura o cuando es probable que los ánimos estén caldeados. GitLab sugiere programarla dos veces para equipos repartidos por varias regiones, de modo que cada grupo tenga un horario razonable. Una llamada corta también puede usarse de forma rutinaria para el paso de decisión mientras la recogida sigue siendo asíncrona.
¿Cuánto tiempo le lleva a cada persona?▾
El formato se extiende a lo largo de toda la iteración, pero el tiempo activo por persona es pequeño, normalmente de 15 a 30 minutos en total entre escribir y responder. La persona moderadora necesita más, aproximadamente una hora a lo largo del periodo. Una llamada en vivo opcional añade de 30 a 60 minutos.
Planifica tu próximo taller con IA
Workshop Weaver te ayuda a combinar métodos como Retrospectiva Asíncrona en una agenda completa y cronometrada en minutos.
Probar gratisMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from GitLab Handbook, 'Group Retrospectives'.