Iteraciones y Calidad Integrada

Las iteraciones de SAFe son cajas de tiempo de 2 semanas (ocasionalmente 1 o 3 semanas, pero 2 es el estándar). Cada iteración sigue un ciclo familiar:

Planificación de Iteración (medio día) — El equipo revisa los objetivos de la iteración, extrae historias del backlog del equipo, las descompone en tareas y se compromete con lo que entregará. En SAFe, los objetivos de iteración deben alinearse con los objetivos de PI establecidos durante la Planificación de PI.

Ejecución (la mayor parte de la iteración) — El equipo trabaja en las historias, realiza standups diarios e integra continuamente. Las historias avanzan por estados: definida, en progreso, terminada. El equipo rastrea el progreso contra sus objetivos de iteración.

Revisión de Iteración / Demo del Sistema (1-2 horas) — El equipo demuestra el trabajo completado. En SAFe, esto alimenta la Demo del Sistema a nivel de ART donde todos los equipos muestran su trabajo integrado a los interesados. La demo individual del equipo es preparación para la demo del sistema.

Retrospectiva de Iteración (1 hora) — El equipo reflexiona sobre qué salió bien, qué no, y qué mejorar. En SAFe, los conocimientos de la retrospectiva también pueden alimentar el evento de Inspeccionar y Adaptar a nivel de PI.

Qué es diferente del Scrum independiente: La iteración está sincronizada entre todos los equipos del ART. Todos comienzan y terminan el mismo día. Esta cadencia compartida crea puntos de integración naturales y hace que la coordinación entre equipos sea predecible.

Cada PI incluye una Iteración de Innovación y Planificación (IP) al final. Esto es único de SAFe y una de sus innovaciones más valiosas.

Qué sucede durante IP:

• Preparación de Planificación de PI: Gestión de Producto prepara la visión y el backlog para el próximo PI. Los Arquitectos del Sistema preparan la pista arquitectónica. Los equipos analizan las características próximas.
• Evento de Planificación de PI: El evento de planificación presencial de 2 días para el próximo PI (este es el propósito principal de la iteración IP).
• Tiempo de innovación: Los equipos usan el tiempo restante para hackathons, explorar nuevas tecnologías, pagar deuda técnica, capacitación o perseguir ideas que no encajan perfectamente en un backlog.
• Inspeccionar y Adaptar: La retrospectiva formal a nivel de PI donde todo el ART reflexiona sobre datos cuantitativos (medida de predictibilidad) y observaciones cualitativas.

Por qué importa IP:

Sin tiempo dedicado a la innovación, la deuda técnica se acumula, las habilidades se estancan y los equipos se convierten en fábricas de características. La iteración IP es una garantía estructural de que la mejora y la exploración suceden—no depende de "encontrar tiempo" que nunca se materializa.

La iteración IP también proporciona un amortiguador natural. Si los equipos encuentran complejidad inesperada durante el PI, la iteración IP absorbe el desbordamiento sin requerir extensiones de cronograma o recortes de alcance en medio de una iteración.

SAFe es inflexible sobre la calidad: no puedes ser ágil con código malo. La calidad integrada no es algo deseable—es un valor central y un prerrequisito para el flujo sostenible.

Prácticas de ingeniería de software:

• Desarrollo Guiado por Pruebas (TDD): Escribe pruebas antes del código. Esto produce mejores diseños y suites de pruebas completas. A escala, TDD es lo que hace viable la integración continua.
• Integración Continua (CI): Integra código varias veces al día. Construye y prueba automáticamente. En SAFe, CI se extiende más allá de equipos individuales—el sistema debe integrarse entre todos los equipos del ART.
• Programación en Parejas / Revisión de Código: Dos pares de ojos en cada cambio. Las parejas rotan para difundir conocimiento. Las revisiones de código detectan problemas y comparten contexto entre miembros del equipo.
• Propiedad Colectiva: Cualquier desarrollador puede modificar cualquier parte del código base. Sin silos de conocimiento. Esto requiere que CI y las pruebas sean seguras.
• Refactorización: Mejora continuamente la estructura del código sin cambiar el comportamiento. La deuda técnica se acumula más rápido a escala porque más personas están cambiando más código.

Prácticas arquitectónicas:

• Arquitectura Intencional: No dejes que la arquitectura emerja puramente de las decisiones del equipo. Los Arquitectos del Sistema guían preocupaciones transversales, aseguran que los equipos construyan sobre plataformas compartidas y mantengan la pista arquitectónica para características futuras.
• Pista Arquitectónica: Invierte por adelantado en infraestructura, frameworks y habilitadores técnicos que las características futuras necesitarán. Sin pista, cada característica comienza desde cero.

Por qué la calidad a escala importa más:

Con un equipo, la mala calidad significa entrega lenta. Con diez equipos, la mala calidad significa fallas de integración en cascada, señalar con el dedo y defectos a nivel de sistema que nadie posee. El costo de los problemas de calidad crece super-linealmente con el conteo de equipos.