La Retrospectiva dello Sprint è l’evento che conclude ogni Sprint. E allo stesso tempo è uno degli incontri più difficili per il Team Scrum. Gli errori più comuni durante una Retrospectiva dello Sprint riguardano l’evitare conversazioni su questioni sensibili, così come la mancanza di impegni concreti che portino alla risoluzione di problemi già diagnosticati.
Errori comuni durante una Retrospectiva dello Sprint – indice:
- Introduzione
- Trasparenza insufficiente
- Focalizzarsi su problemi o successi una tantum
- Sovra-rappresentazione del Product Owner
- Problemi di auto-gestione
- Troppi impegni
- Errori comuni durante una Retrospectiva dello Sprint – Riepilogo
Introduzione
Gli errori durante una Retrospectiva dello Sprint sono purtroppo molto comuni. Questo perché è uno degli incontri più difficili da eseguire con successo poiché richiede molta maturità da parte del team. Ecco perché vale la pena dare un’occhiata ai problemi che si verificano più spesso in altri team in modo da poter individuare più facilmente i loro sintomi durante la conduzione della Retrospectiva dello Sprint nel tuo Team Scrum.
Trasparenza insufficiente
Secondo il Scrum Guide, ogni membro del Team Scrum è obbligato a essere onesto e audace nell’esprimere preoccupazioni e a esprimere la propria opinione durante la Retrospectiva dello Sprint. Tuttavia, nella pratica, l’impegno per la trasparenza è molto impegnativo. Per questo motivo, i membri del Team Scrum spesso cercano di eluderlo.
Un problema che è difficile da individuare e risolvere è evitare di discutere delle carenze osservate nel lavoro del Team Scrum. Questo può portare a problemi molto più gravi a lungo termine.
Il compito dello Scrum Master, quindi, è tenere d’occhio la situazione nel team e incoraggiare tutti i membri del team a essere proattivi fin dall’inizio della Retrospectiva dello Sprint.
Focalizzarsi su problemi o successi una tantum
Un altro problema che può sorgere durante la Retrospectiva dello Sprint è prestare insufficiente attenzione ai comportamenti ciclici e ripetitivi del team, e al loro impatto sull’efficacia del team.
È sempre bene congratularsi con i membri del Team Scrum se hanno raggiunto un successo eccezionale. Tuttavia, la Sprint Review non dovrebbe essere dedicata a celebrarlo. Lo stesso vale per i fallimenti. Se qualcosa è fallito a causa di motivi fortuiti o di un errore già diagnosticato, non vale la pena analizzare eccessivamente l’evento durante la Sprint Review.
Tuttavia, a volte il team dedica una grande parte della Retrospectiva dello Sprint a tali eventi. Tieni presente, però, che lo scopo della Retrospectiva dello Sprint è cercare modi per migliorare il lavoro quotidiano del team. Pertanto, l’incontro non dovrebbe ruotare attorno a successi o problemi una tantum che è altamente probabile che non si ripetano.
Sovra-rappresentazione del Product Owner
In molte organizzazioni, la posizione di Product Owner è equiparata a quella di Product Manager. Il Product Owner è quindi spesso considerato il supervisore del Team Scrum. Per questo motivo, succede che il Team di Sviluppo non voglia parlare dei problemi di lavoro di squadra in sua presenza.
Per questo motivo è così importante costruire fiducia reciproca tra il Team di Sviluppo e il Product Owner. Sfortunatamente, il processo di costruzione della fiducia è difficile e lungo. Ecco perché a volte è una buona idea per il Product Owner rinunciare alla partecipazione a tutta o parte della Retrospectiva dello Sprint per lasciare spazio al resto del team per discutere liberamente.
Problemi di auto-gestione
L’auto-gestione significa che i membri del Team Scrum prendono le proprie decisioni su chi tra di loro svolgerà determinati compiti, quando e come. Durante la Retrospectiva dello Sprint, il team discute delle persone, delle loro interazioni e delle pratiche del team. Decide quindi quali problemi devono essere risolti nel prossimo Sprint, come farlo insieme e chi si assumerà la responsabilità di intraprendere azioni.
Se sorgono problemi più gravi in un team auto-gestito, potrebbe esserci la tentazione nel Team Scrum di abdicare alla responsabilità.
Occasionalmente, i membri del team non vogliono partecipare alla discussione e cercano di spingere la responsabilità della gestione su qualcun altro. Per prevenire ciò, è estremamente importante discutere regolarmente anche dei piccoli problemi per prevenire la loro accumulazione.
Troppi impegni
Un Team Scrum attivo che opera seguendo i tre pilastri dell’empirismo: trasparenza, ispezione e adattamento, può incontrare il problema di fare troppi impegni contemporaneamente.
Se gli impegni assunti dal Team Scrum durante una Retrospectiva dello Sprint sono troppi, c’è un notevole rischio che:
- nessuno degli impegni venga implementato correttamente
- alcuni impegni non vengano implementati affatto
- le modifiche apportate non siano permanenti
Pertanto, una buona pratica è di intraprendere non più di quattro miglioramenti in ogni Sprint. Questo consente un miglioramento graduale ma efficace delle prestazioni del team.
Errori comuni durante una Retrospectiva dello Sprint – Riepilogo
Poiché la Retrospectiva dello Sprint è un evento impegnativo, problemi spesso sorgono durante la sua conduzione. Per affrontarli più facilmente, vale la pena notare quelli che si presentano più spesso. Gli errori comuni durante una Retrospectiva dello Sprint sono:
- trasparenza insufficiente – quando i membri del Team Scrum non riescono a trattare con onestà in situazioni di team più difficili
- focalizzarsi su problemi o successi una tantum – quando i membri del Team Scrum si concentrano sulla discussione di successi e fallimenti, invece di discutere dell’efficacia a lungo termine del lavoro del team
- sovra-rappresentazione del Product Owner – quando i membri del Team Scrum trattano il Product Owner con fiducia limitata come se fosse qualcuno al di fuori del team o un supervisore
- problemi di auto-gestione – quando i membri del Team Scrum cercano di spostare la responsabilità per i problemi e le decisioni.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Scrum Guide:
- Glossario dei termini, ruoli e nozioni di base
- Che cos'è Scrum?
- Valori Scrum
- Come implementare Scrum nella tua azienda?
- Team Scrum - cos'è e come funziona?
- Chi è un Product Owner?
- Gli errori più comuni del Product Owner
- Chi è lo Scrum Master?
- I più comuni errori del Scrum Master
- Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
- Team di sviluppo in Scrum
- I più comuni errori degli sviluppatori
- Artefatti Scrum
- Scaling Scrum
- Sprint Backlog
- Cos'è il Product Backlog?
- Cosa sono le User Stories?
- Creare la migliore User Story con INVEST
- I più comuni errori nelle User Story
- Criteri di accettazione della User Story
- Stima e Punti Storia in Scrum
- Planning Poker
- Gioco di Stima del Team
- Definizione di Incremento
- Eventi Scrum
- Che cos'è un grafico di burndown?
- Vantaggi e svantaggi del grafico di burndown
- Bacheche Kanban in Scrum e Scrumban
- Velocità nello Scrum - Velocità del Team di Sviluppo
- Daily Scrum Scrum giornaliero
- Pianificazione dello Sprint
- Revisione dello Sprint
- Che cos'è una Retrospettiva Sprint?
- Errori comuni durante una Retrospettiva di Sprint
- Nutrimento del Product Backlog
- Come creare e interpretare un grafico di burndown?