Revisione dello Sprint e Retrospettiva del Prodotto

Una Revisione dello Sprint efficace serve a due scopi distinti: dimostrare il lavoro completato e raccogliere feedback. Errori comuni che compromettono entrambi gli scopi: (1) Mostrare diapositive su ciò che è stato realizzato invece di dimostrare il prodotto reale — le diapositive sono presentazioni di vendita; le revisioni richiedono dimostrazioni di prodotto dal vivo. Se non può essere mostrato dal vivo, spiega il motivo e mostra l'artefatto più vicino disponibile. (2) Saltare le domande degli stakeholder per rispettare una tempistica stretta — i risultati più preziosi di una revisione sono le domande e le reazioni degli stakeholder che non hanno partecipato allo sprint quotidiano. Prevedi tempo per la discussione. (3) Revisionare solo il lavoro "fatto" e saltare gli elementi non completati — questo crea l'impressione fuorviante che l'ambito sia stato pienamente raggiunto e rimuove le opportunità di apprendimento da completamenti parziali. (4) Invitare un pubblico troppo ampio — una Revisione dello Sprint con 40 persone diventa una performance piuttosto che una sessione di feedback. Limita il pubblico ai membri del team, alla leadership di prodotto, agli stakeholder chiave e ai rappresentanti a contatto con i clienti (uno o due CSM o responsabili di Support Ops). Product Ops progetta il formato della revisione, prepara l'ordine del giorno e assicura che le dimostrazioni mostrino il valore per l'utente finale piuttosto che i dettagli di implementazione tecnica.

La retrospettiva è lo strumento di miglioramento a più alto impatto del team — una retrospettiva di 60 minuti ben facilitata produce miglioramenti specifici e attuabili che si accumulano nel tempo. Struttura di facilitazione: (1) Dati — inizia con i fatti: cosa abbiamo rilasciato? Quali erano le nostre metriche di velocità e qualità? Quali sono stati i momenti salienti e gli eventi negativi dello sprint? (2) Sentimenti — "cosa ha reso questo sprint energizzante o frustrante?" — permetti al team di esprimere la realtà emotiva dello sprint, non solo le metriche. La sicurezza psicologica richiede che "frustrante" sia accolto tanto quanto "energizzante." (3) Approfondimenti — quali schemi rivelano i dati + i sentimenti? Quali problemi sistemici emergono ripetutamente? (4) Azioni — converti gli approfondimenti in elementi d'azione specifici e di proprietà. "Dovremmo comunicare meglio" non è un elemento d'azione. "Sarah aggiungerà un riepilogo asincrono di 5 minuti ogni mercoledì per ridurre il disallineamento, a partire dal prossimo sprint" è un elemento d'azione. (5) Accordi — chiudi rivedendo gli elementi d'azione della retrospettiva precedente: sono stati completati? Qual è stato il risultato? Questa responsabilità trasforma la retrospettiva da una sessione di sfogo a un vero motore di miglioramento.

I dati delle retrospettive dello sprint sono più ricchi quando aggregati tra i team nel tempo — i modelli visibili tra più squad rivelano problemi di processo sistemici che nessuna retrospettiva di un singolo team può diagnosticare. Product Ops mantiene un database dei temi delle retrospettive: dopo ogni ciclo di sprint, i temi comuni di tutte le retrospettive delle squad vengono etichettati e inseriti in un registro condiviso. Nel corso di 4-6 sprint, emergono schemi: "tre squad segnalano indipendentemente che i passaggi di QA alla fine degli sprint creano pressione di lavoro nel fine settimana." Questo è un problema di processo sistemico che gli elementi d'azione di un singolo team non possono risolvere — richiede un cambiamento di processo inter-team facilitato da Product Ops. Product Ops aggrega questi schemi in un "Process Health Report" trimestrale presentato alla leadership di ingegneria e prodotto: i 5 principali punti dolenti ricorrenti del processo tra tutti i team, con la soluzione sistemica proposta per ciascuno. Questo distingue un Product Ops efficiente e ad alto impatto dal semplice riempimento di checklist retrospettive.