Demo del Sistema e Inspeccionar y Adaptar

La Demo del Sistema ocurre al final de cada iteración. A diferencia de las demos individuales de equipo que muestran el trabajo de cada equipo de forma aislada, la Demo del Sistema muestra software integrado y funcional a través de todos los equipos en el ART.

Por qué importa la integración a nivel de sistema:

Las demos individuales de equipo pueden verse geniales mientras el sistema general está roto. El Equipo A completó su API. El Equipo B completó su UI. Pero nunca integraron—y cuando lo hacen, nada funciona. La Demo del Sistema fuerza que esta integración ocurra cada 2 semanas, no al final del PI cuando es demasiado tarde.

Ejecutar una Demo del Sistema efectiva:

• Preparación: El ART integra todo el trabajo de los equipos en un ambiente de staging antes de la demo. Los pipelines de CI/CD deberían hacer esto automático—si necesitas un "sprint de endurecimiento" para integrar, tu CI está roto.
• Audiencia: Stakeholders, propietarios de negocio, gerencia. Esta es su ventana al progreso de desarrollo. Hazla accesible para personas no técnicas.
• Formato: Muestra software funcional, no diapositivas. Demuestra escenarios de extremo a extremo que cruzan límites de equipos. Resalta qué es nuevo, qué cambió y qué riesgos permanecen.
• Duración: 1-2 horas, dependiendo del tamaño del ART.
• Retroalimentación: Solicita activamente retroalimentación. ¿Qué está funcionando? ¿Qué falta? ¿Qué necesita cambiar? Esta retroalimentación da forma a las prioridades de la siguiente iteración.

La Demo del Sistema es el mecanismo principal de responsabilidad del ART. Puedes ocultar el progreso en reportes de estado. No puedes ocultarlo en una demo en vivo de software funcional.

Inspeccionar y Adaptar (I&A) es la retrospectiva a nivel de PI. Ocurre al final de cada PI (durante la iteración IP) e involucra a todo el ART. Mientras las retrospectivas de equipo se enfocan en mejoras a nivel de equipo, I&A aborda problemas sistémicos que abarcan equipos.

El evento I&A tiene tres partes:

1. Demo del Sistema del PI (1-2 horas) — Una demo integral de todo lo entregado durante el PI. Esta es la Demo del Sistema final y definitiva que muestra el incremento completo de valor. Los Propietarios de Negocio evalúan el valor real entregado contra los objetivos del PI.

2. Medición Cuantitativa (30 min) — Revisar datos objetivos:

• Medida de Predictibilidad: Valor de negocio planeado vs. real (cada objetivo del PI fue asignado un valor de negocio; ¿cuánto se entregó?)
• Tendencias de velocidad: ¿Los equipos están acelerando, estabilizándose o desacelerándose?
• Métricas de flujo: Tiempo de entrega, rendimiento, tendencias de WIP
• Métricas de calidad: Tendencias de defectos, defectos escapados, cobertura de pruebas

3. Taller de Resolución de Problemas (1.5-2 horas) — La parte más valiosa. El ART identifica los principales problemas y usa resolución estructurada de problemas:

• Lluvia de ideas sobre problemas (todos contribuyen)
• Votar sobre los problemas más impactantes a resolver
• Análisis de causa raíz (5 Por Qués, diagrama de Ishikawa)
• Definir historias de mejora con criterios de aceptación claros
• Agregar historias de mejora al backlog del siguiente PI

El resultado de I&A son elementos de mejora concretos que van al backlog del programa. Estos no son intenciones vagas—son historias estimadas con responsables que compiten por capacidad en el siguiente PI.

La parte más difícil de la mejora continua no es identificar problemas—es dar seguimiento. I&A produce historias de mejora, pero esas historias necesitan realmente completarse.

Estrategias para hacer que la mejora perdure:

• Trata las historias de mejora como historias de funcionalidad: Van en el tablero, tienen criterios de aceptación, se demuestran. No las ocultes en una lista separada de "deuda técnica" que nadie mira.
• Asigna capacidad: Reserva 10-20% de la capacidad de cada equipo para trabajo de mejora. Haz esto explícito durante la Planificación del PI.
• Rastrea métricas de mejora: ¿Los tiempos de entrega se están acortando? ¿La predictibilidad está mejorando? ¿La calidad está tendiendo hacia arriba? Si tus historias de mejora no están moviendo las métricas, estás resolviendo los problemas equivocados.
• Retrospectiva de retrospectivas: Revisa periódicamente si I&A está realmente impulsando cambio. ¿Los mismos problemas están surgiendo PI tras PI? Si es así, el análisis de causa raíz no es lo suficientemente profundo.
• Celebra victorias: Cuando una historia de mejora resuelve un punto de dolor de larga data, reconócelo. Esto refuerza la cultura de mejora.

La medida de predictibilidad:

SAFe usa una fórmula específica: suma del valor de negocio logrado ÷ suma del valor de negocio planeado × 100%. Un ART saludable puntúa 80-100% consistentemente. Por debajo del 80% sugiere problemas de planificación (sobrecompromiso, estimación pobre o demasiadas interrupciones no planeadas).

La predictibilidad no se trata de perfección—se trata de construir la confianza que permite al negocio planear alrededor de la entrega. Un ART que entrega confiablemente 85% del valor comprometido es infinitamente más valioso que uno que promete 100% y entrega de manera impredecible.