Demo di Sistema e Inspect and Adapt

La Demo di Sistema avviene alla fine di ogni iterazione. A differenza delle demo dei singoli team che mostrano il lavoro di ciascun team in isolamento, la Demo di Sistema mostra software funzionante e integrato attraverso tutti i team dell'ART.

Perché l'integrazione a livello di sistema è importante:

Le demo dei singoli team possono sembrare ottime mentre il sistema complessivo è rotto. Il Team A ha completato la propria API. Il Team B ha completato la propria UI. Ma non hanno mai integrato—e quando lo fanno, nulla funziona. La Demo di Sistema forza questa integrazione a verificarsi ogni 2 settimane, non alla fine del PI quando è troppo tardi.

Condurre una Demo di Sistema efficace:

• Preparazione: L'ART integra tutto il lavoro dei team in un ambiente di staging prima della demo. Le pipeline CI/CD dovrebbero rendere questo automatico—se hai bisogno di uno "sprint di consolidamento" per integrare, il tuo CI è rotto.
• Pubblico: Stakeholder, business owner, management. Questa è la loro finestra sul progresso dello sviluppo. Rendila accessibile alle persone non tecniche.
• Formato: Mostra software funzionante, non slide. Dimostra scenari end-to-end che attraversano i confini dei team. Evidenzia cosa c'è di nuovo, cosa è cambiato e quali rischi rimangono.
• Durata: 1-2 ore, a seconda delle dimensioni dell'ART.
• Feedback: Sollecita attivamente il feedback. Cosa funziona? Cosa manca? Cosa deve cambiare? Questo feedback plasma le priorità dell'iterazione successiva.

La Demo di Sistema è il principale meccanismo di responsabilità dell'ART. Puoi nascondere i progressi nei report di stato. Non puoi nasconderli in una demo dal vivo di software funzionante.

Inspect and Adapt (I&A) è la retrospettiva a livello di PI. Avviene alla fine di ogni PI (durante l'iterazione IP) e coinvolge l'intero ART. Mentre le retrospettive dei team si concentrano sui miglioramenti a livello di team, l'I&A affronta problemi sistemici che attraversano i team.

L'evento I&A ha tre parti:

1. Demo di Sistema del PI (1-2 ore) — Una demo completa di tutto ciò che è stato consegnato durante il PI. Questa è la Demo di Sistema finale e definitiva che mostra l'intero incremento di valore. I Business Owner valutano il valore effettivo consegnato rispetto agli obiettivi del PI.

2. Misurazione Quantitativa (30 min) — Revisione dei dati oggettivi:

• Misura di Prevedibilità: Valore di business pianificato vs. effettivo (a ogni obiettivo del PI è stato assegnato un valore di business; quanto è stato consegnato?)
• Trend di velocity: I team stanno accelerando, stabilizzandosi o rallentando?
• Metriche di flusso: Lead time, throughput, trend del WIP
• Metriche di qualità: Trend dei difetti, difetti sfuggiti, copertura dei test

3. Workshop di Problem-Solving (1,5-2 ore) — La parte più preziosa. L'ART identifica i problemi principali e utilizza il problem-solving strutturato:

• Brainstorming dei problemi (tutti contribuiscono)
• Votazione sui problemi più impattanti da risolvere
• Analisi delle cause radice (5 Perché, diagramma a lisca di pesce)
• Definizione di storie di miglioramento con criteri di accettazione chiari
• Aggiunta delle storie di miglioramento al backlog del PI successivo

L'output dell'I&A sono elementi di miglioramento concreti che entrano nel backlog del programma. Questi non sono intenzioni vaghe—sono storie stimate con proprietari che competono per la capacità nel PI successivo.

La parte più difficile del miglioramento continuo non è identificare i problemi—è dare seguito. L'I&A produce storie di miglioramento, ma quelle storie devono essere effettivamente completate.

Strategie per far attecchire il miglioramento:

• Tratta le storie di miglioramento come storie di funzionalità: Vanno sulla board, hanno criteri di accettazione, vengono dimostrate. Non nasconderle in una lista separata di "debito tecnico" che nessuno guarda.
• Alloca capacità: Riserva il 10-20% della capacità di ogni team per il lavoro di miglioramento. Rendilo esplicito durante il PI Planning.
• Traccia le metriche di miglioramento: I lead time si stanno accorciando? La prevedibilità sta migliorando? La qualità è in tendenza positiva? Se le tue storie di miglioramento non stanno muovendo le metriche, stai risolvendo i problemi sbagliati.
• Retrospettiva delle retrospettive: Rivedi periodicamente se l'I&A sta effettivamente guidando il cambiamento. Gli stessi problemi emergono PI dopo PI? Se sì, l'analisi delle cause radice non è abbastanza profonda.
• Celebra le vittorie: Quando una storia di miglioramento risolve un punto dolente di lunga data, riconoscilo. Questo rafforza la cultura del miglioramento.

La misura di prevedibilità:

SAFe utilizza una formula specifica: somma del valore di business raggiunto ÷ somma del valore di business pianificato × 100%. Un ART sano ottiene costantemente un punteggio dell'80-100%. Sotto l'80% suggerisce problemi di pianificazione (impegni eccessivi, stima scarsa o troppe interruzioni non pianificate).

La prevedibilità non riguarda la perfezione—riguarda la costruzione della fiducia che consente al business di pianificare intorno alla consegna. Un ART che consegna in modo affidabile l'85% del valore impegnato è infinitamente più prezioso di uno che promette il 100% e consegna in modo imprevedibile.