Tu método ya tiene retrospectivas. Las llama informes de lecciones aprendidas.

¿Waterfall Tiene Retrospectivas?

Sí, bajo un nombre diferente. PRINCE2 nombra "aprender de la experiencia" como uno de sus siete principios¹. Mantiene un Registro de Lecciones, creado durante la fase de Inicio en una actividad llamada Capturar Lecciones Previas, y un Informe de Lecciones típicamente se incluye en cada Informe de Fin de Etapa². Si ejecutas PRINCE2, ya realizas una revisión estructurada al final de una etapa y escribes lo que aprendiste. Eso es una retrospectiva.

Probablemente te han dicho lo contrario. La idea de que los equipos tradicionales "no hacen retros" es una de las afirmaciones más repetidas y menos examinadas en el mercado de herramientas de entrega. No sobrevive el contacto con los manuales. Lo que les falta a los equipos tradicionales no es la práctica. Son las herramientas.

Piensa en dónde termina realmente un Informe de Lecciones. Alguien lo escribe en un límite de etapa, usualmente bajo presión de tiempo, usualmente después de que los detalles interesantes ya se desvanecieron. Se adjunta a un Informe de Fin de Etapa, se archiva en una unidad compartida, y lo lee aproximadamente nadie al inicio de la siguiente etapa. El aprendizaje se captura y luego queda varado.

Para ser justos, los equipos ágiles no son obviamente mejores en esto. Un tablero de retro lleno de notas adhesivas se fotografía y se abandona con la misma frecuencia. Ningún grupo ha resuelto el problema de hacer que la lección del mes pasado cambie el comportamiento del próximo mes. La diferencia es que uno de esos grupos ha pasado quince años construyendo software para ello, y al otro le han dicho que el software no es para ellos.

Sea cual sea tu método, PRINCE2, un proceso interno de puertas de etapa, o algo que tu organización ensambló durante dos décadas, la forma es la misma. Al final de una fase revisas lo que sucedió y lo escribes. La pregunta abierta nunca es si lo haces. Es si algo sucede con lo que escribiste.

¿A Qué Se Mapean las Ceremonias Ágiles en la Entrega Tradicional?

Cada ceremonia ágil tiene una contraparte tradicional, y la mayoría de las contrapartes llegaron primero. Las retrospectivas se mapean a revisiones de lecciones. Los standups se mapean a reportes de estado. Las demos se mapean a revisiones de puertas de etapa. La estimación se mapea a los números que ya están en tu estructura de desglose de trabajo. El vocabulario es diferente. El trabajo es el mismo, y ya lo estás haciendo.

La columna izquierda es un vocabulario que no elegiste y no necesitas. La columna del medio es trabajo que ya haces, en un cronograma que alguien más estableció, usualmente en una plantilla. Simyl Flow automatiza la columna del medio. La columna izquierda es solo lo que dicen los botones.

Puedes usar el producto durante un año sin decir nunca la palabra "sprint" en voz alta.

¿Simyl Flow Requiere Sprints de Dos Semanas?

No. Un sprint en Simyl Flow es un rango de fechas con nombre, con un inicio y un fin. No se impone ninguna duración en ninguna parte del producto. Una fase de seis semanas, un lanzamiento trimestral, o un hito cuya fecha de fin ya se retrasó dos veces se comportan de la misma manera, porque cada métrica se calcula a partir de marcas de tiempo en tus tickets y commits en lugar de la duración del contenedor.

Esto importa más de lo que suena. Si una herramienta asume dos semanas, esa suposición se filtra en todo lo que viene después: los gráficos, las comparaciones, los umbrales que deciden qué cuenta como lento. Las herramientas construidas de esa manera genuinamente no encajan en una organización basada en fases, y la respuesta razonable es la que ya tenías.

Aquí el contenedor es una etiqueta en un rango de fechas. Llámalo Fase 3. Llámalo Lanzamiento 4.2. Llámalo Endurecimiento Q3. El tiempo de ciclo sigue siendo el intervalo entre que un ticket comienza y termina. La tasa de bugs sigue siendo una proporción. Ninguno se vuelve sin sentido porque tu fase duró once semanas en lugar de dos.

¿Qué Puedes Medir Sin Cambiar Cómo Trabaja Tu Equipo?

Conecta tu rastreador de issues y tu repositorio de código, y seis métricas aparecen sin que nadie asista a una nueva reunión: Velocidad, Tiempo de Ciclo, PRs Fusionados, Commits, Tasa de Bugs y Trabajo No Planeado. Cada una se deriva de registros que tu equipo ya crea en el curso de hacer el trabajo. No se requiere ninguna sesión de estimación, ningún standup y ninguna retrospectiva para producir ninguna de ellas.

Este es el punto de entrada honesto, y es el que recomendaríamos incluso si estuvieras entusiasmado con las ceremonias. Nadie tiene que aprender vocabulario nuevo. Nadie tiene que ser convencido de una filosofía en una reunión del lunes. Los datos ya están en Jira y GitHub, ahí sentados, describiendo cómo se comporta realmente tu entrega.

Las ceremonias sí existen en el producto. Puedes activarlas cuando quieras, o nunca. Un equipo que conecta dos sistemas y no abre nada más aún obtiene una tendencia de tiempo de ciclo, que es más de lo que la mayoría de las organizaciones tradicionales tienen hoy.

Lo que tiende a sorprender a la gente es dónde aparece la espera. No en el desarrollo. En las transferencias entre fases, en la brecha entre "código completo" y "ambiente de prueba disponible", en la semana que una orden de cambio pasó esperando una firma.

¿Qué no te dice la velocidad?

La velocidad te dice cuánto trabajo se cerró en un período. No puede decirte si ese trabajo permaneció cerrado, cuánto tiempo esperó antes de que alguien lo tomara, o qué costó sacarlo por la puerta. Una fase puede alcanzar exactamente su objetivo de velocidad y aún así enviar defectos que consumen la fase siguiente. El número se ve igual de cualquier manera.

Esto no es un argumento contra la velocidad. Es un número genuinamente útil, y rastrearlo te pone por delante de las muchas organizaciones que no rastrean nada en absoluto. El problema no es que la velocidad esté mal. Es que la velocidad suele estar sola.

Imagina dos fases con velocidad idéntica. En la primera, el trabajo avanzó de manera constante, la revisión tomó un día y casi nada regresó. En la segunda, todo permaneció en revisión durante nueve días, se envió en una ráfaga en la última semana, y un tercio regresó como defectos en un mes. La velocidad registra esas dos fases como equivalentes. El Tiempo de Ciclo, la Tasa de Errores y el Trabajo No Planificado no lo hacen.

El Trabajo No Planificado suele ser el que impacta más fuerte en un taller basado en fases. Es el número que finalmente explica por qué el plan se retrasó cuando nadie en el equipo hizo nada mal. Planificaste para el trabajo que conocías. Llegó algo más. La mayoría de los procesos de planificación no tienen forma de mostrar eso, así que el retraso se atribuye a las estimaciones, o a las personas, y lo mismo sucede en la siguiente fase.

Puedes ver cómo encajan las seis dimensiones en la descripción general de efectividad.

No estamos ejecutando una estafa larga

No hay una fase dos donde te pidamos adoptar Scrum.

La medición funciona porque tus fases tienen fechas y tus tickets tienen marcas de tiempo. No funciona por el marco impreso en la pared. Si conectas tus sistemas, nunca ejecutas una retrospectiva en este producto y nunca estimas un solo elemento en él, aún te dice si la entrega se está volviendo más rápida o más lenta y dónde ocurre la espera.

Preferiríamos ser útiles para ti tal como ya trabajas que esperar a que te conviertas en alguien más primero.

No es un embudo de conversión. Es una herramienta de medición.

Preguntas frecuentes

¿Tenemos que adoptar agile para usar Simyl Flow?

No. El producto lee fechas de tu rastreador de issues y marcas de tiempo de tu repositorio. Ninguno depende de un marco. Los equipos que ejecutan fases, puertas de etapa o un proceso interno personalizado obtienen las mismas métricas que los equipos que ejecutan iteraciones de dos semanas, porque los registros subyacentes son los mismos en ambos casos.

¿Simyl Flow requiere sprints de dos semanas?

No. Un sprint es un rango de fechas con nombre con un inicio y un final, y no se impone ninguna duración. Una fase, un hito, un lanzamiento o un trimestre funcionan. Las métricas se calculan a partir de marcas de tiempo en tickets y commits, por lo que la longitud del contenedor no cambia cómo se calculan.

Ejecutamos PRINCE2. ¿Dónde encaja?

Tu Informe de Fin de Etapa es el lugar natural. PRINCE2 ya coloca una revisión de lecciones en ese límite, por lo que las funciones de retrospectiva tienen un lugar obvio donde vivir si alguna vez las quieres. No necesitas usarlas. Conecta tus herramientas y las métricas de entrega funcionan independientemente del proceso que las envuelva.

No ejecutamos retrospectivas. ¿Sigue siendo útil?

Sí. El Tiempo de Ciclo, la Tasa de Errores, el Trabajo No Planificado, los PRs Fusionados y los Commits se derivan todos de tus tickets existentes y del historial de código. No requieren ninguna reunión ni facilitación. Las retrospectivas agregan un lugar para actuar sobre lo que muestran los números, pero los números llegan sin importar si realizas una o no.

¿Cuál es la configuración mínima?

Un rastreador de issues o un repositorio de código. Conéctalo, elige un rango de fechas que coincida con cómo ya planificas, y las métricas se completan desde el historial. Nada cambia sobre cómo trabaja tu equipo esa semana, que es el punto.

Fuentes