Checklist per Scrum Master
Un buon Scrum Master può occuparsi di due o tre team contemporaneamente. Se ci si accontenta di limitare il proprio ruolo all'organizzazione dei meeting, al rispetto delle tempistiche e alla risoluzione dei problemi del team, il ruolo di Scrum Master può funzionare anche part-time. Il team supererà sicuramente le aspettative che esistevano nella vostra organizzazione prima di Scrum e molto probabilmente non si verificheranno grandi catastrofi.
Se però potete immaginare che un team si diverta a realizzare cose che prima non si ritenevano possibili, allora dovreste anche avere la volontà di essere un grande Scrum Master.
Un grande Scrum Master può occuparsi solo di un team alla volta.
Soprattutto per la fase iniziale raccomandiamo quindi uno Scrum Master motivato e impegnato per un team di circa sette persone.
Se non avete ancora una panoramica completa di tutto il lavoro da svolgere, cercate di saperne di più sul Product Owner, sul team, sui metodi di sviluppo del team e sull'intera organizzazione. Anche se non esiste una ricetta universale, ho elencato qui alcune cose a cui uno Scrum Master dovrebbe prestare attenzione:
Checklist dello Scrum Master per il Product Owner
Potete aumentare l'efficacia del Product Owner aiutandolo a occuparsi del Product Backlog e del piano di rilascio. (Ricordate però che solo il Product Owner dovrebbe dare la priorità al Backlog.)
La prioritizzazione del Product Backlog corrisponde alle riflessioni e alle idee più recenti del Product Owner?
Tutti i requisiti e desideri di tutti gli Stakeholder sono stati inseriti nel Backlog? Ricorda che il Backlog può cambiare costantemente.
Il Product Backlog ha una dimensione gestibile? Per mantenere un numero di elementi gestibile, gli elementi dettagliati dovrebbero trovarsi in cima al Backlog e i temi più generali più in basso. È controproducente entrare troppo nel dettaglio per più che i soli elementi in cima, perché i requisiti cambieranno permanentemente con l'evoluzione del prodotto e il costante confronto con clienti/stakeholder.
Ci sono requisiti (specialmente quelli in cima al Backlog) che potrebbero essere scritti meglio come User Story indipendenti, negoziabili, di valore, stimabili, piccole e testabili (criteri INVEST)?
Hai informato il tuo Product Owner sul debito tecnico e su come evitarlo? Può essere utile aggiungere test automatizzati e refactoring alla Definition of Done di ogni elemento del Backlog.
Il Backlog come fonte di informazioni è ben visibile per tutti gli stakeholder?
Avete un tool automatizzato per gestire il Backlog? E se sì, vi porta effettivamente dei vantaggi? Tali strumenti comportano infatti il rischio che sia difficile trovare le informazioni cercate se lo Scrum Master non comunica attivamente queste informazioni.
Potete aiutare a comunicare le informazioni stampandole e distribuendole a tutti i coinvolti?
Potete aiutare a comunicare queste informazioni creando grafici e diagrammi grandi e ben visibili?
Avete aiutato il Product Owner a suddividere gli elementi del Backlog in rilasci appropriati? (Ad es. in lavori attuali (Front Burner), lavori imminenti (Back Burner) e cose che sono state inserite nel Backlog ma non ancora preparate ulteriormente (Fridge).)
Tutti gli stakeholder (incluso il team) sanno se il piano di rilascio – misurato sulla Velocity attuale (ad es. Story Point per Sprint) – corrisponde ancora alla realtà?
Il Product Owner ha aggiornato il piano di rilascio dopo l'ultimo Sprint Review Meeting? Pochi Product Owner che consegnano prodotti sufficientemente testati in tempo aggiornano il piano di rilascio in ogni Sprint. Spesso spostano alcuni lavori a rilasci futuri quando emergono lavori più importanti. Provate i Product/Release Burndown Chart secondo Mike Cohn, che potete presentare a tutti i coinvolti dopo che negli Sprint Review Meeting è stato confermato che gli elementi sono „done”. Da questi si possono riconoscere bene i cambiamenti precoci nell'ambito o nella tempistica.
Checklist dello Scrum Master per il team
1.) I membri del team sono la maggior parte del tempo in „Flow”? Alcune caratteristiche di questo stato sono: obiettivi chiari (aspettative e regole sono riconoscibili; gli obiettivi sono raggiungibili e corrispondono alle capacità delle singole persone); concentrazione e focus (focalizzazione su un punto specifico); incertezza ridotta (azioni e coscienza si fondono); il senso del tempo si perde (la percezione soggettiva del tempo cambia); feedback diretto e immediato (successi e insuccessi durante l'azione sono ben riconoscibili, quindi il comportamento può essere adattato se necessario); equilibrio tra capacità e sfida (non è né troppo difficile né troppo facile); un senso di controllo personale sulla situazione/azione (l'azione è intrinsecamente gratificante e quindi senza sforzo).
1.) I membri del team sembrano andare d'accordo tra loro? Fanno qualcosa insieme? Festeggiano i successi dei colleghi insieme?
2.) I membri del team si assicurano che tutti rispettino gli standard elevati? Si incoraggiano a vicenda a migliorare?
3.) Ci sono problemi o opportunità di cui il team non parla perché non si sente abbastanza a proprio agio? Potete consultare un professionista che vi aiuti a rendere più piacevoli le conversazioni scomode. (Oppure leggete di più sull'argomento nel libro Crucial Conversations: Tools for Talking When Stakes are High)
4.) Avete già provato diversi formati e luoghi per i vostri Sprint Review Meeting? Alcune idee si trovano nel libro Agile Retrospectives: Making Good Teams Great di Esther Derby e Diana Larsen.
5.) Il team ha rispettato i criteri di accettazione? Forse dovete verificare durante lo Sprint ancora una volta i criteri di accettazione degli elementi del Product Backlog per questo Sprint.
6.) Lo Sprint Backlog riflette effettivamente ciò su cui il team sta lavorando? Interruzioni e distrazioni che non contribuiscono al raggiungimento dello Sprint Goal sono impedimenti.
7.) Le stime per i task e la taskboard sono aggiornate?
8.) Gli artefatti per l'autogestione del team (taskboard, Sprint Burndown Chart ecc.) sono ben visibili, pratici e funzionali per tutto il team?
9.) Questi artefatti sono sufficientemente protetti dal micromanagement?
10.) I membri del team si offrono volontari per determinati compiti?
11.) Sono stati inseriti nel Backlog elementi per il rimborso del debito tecnico (per risolvere problemi che danneggiano la Velocity) o sono stati almeno discussi con il Product Owner?
12.) I membri del team lasciano i loro titoli di lavoro fuori dalla stanza del team?
13.) L' intero team si sente responsabile per test, documentazione utente ecc.?
Checklist per lo sviluppo del prodotto
1.) Il vostro sistema in sviluppo ha un pulsante „Push-to-test”, così che chiunque (nello stesso o in un altro team) possa facilmente scoprire se ha rotto qualcosa? Questo si ottiene normalmente con il framework xUnit (JUnit, NUnit ecc.).
2.) Avete un rapporto equilibrato tra test di sistema end-to-end automatizzati (test funzionali) e unit test automatizzati?
3.) Il team scrive sia "test funzionali" che unit test nel linguaggio del sistema che sta sviluppando (anziché linguaggi di scripting proprietari o strumenti di Capture & Playback che solo una piccola parte del team sa usare)? È possibile!
4.) Il vostro team ha già scoperto la zona grigia estremamente utile tra test di sistema e unit test?
5.) Un server di Continuous Integration lancia automaticamente un allarme entro un'ora (o pochi minuti) quando qualcuno causa un errore di regressione?
6.) Tutti i test confluiscono nel risultato del server di Continuous Integration?
7.) I membri del team hanno già scoperto i vantaggi del design evolutivo (Continuous Design) e del „refactoring spietato” come alternativa al Big Design Upfront (BDUF)? Il refactoring ha una definizione chiara: modifica della struttura interna di un sistema senza alterare il comportamento visibile dall'esterno. In caso di codice ridondante, logica complessa, convenzioni di denominazione scadenti, accoppiamento eccessivo tra oggetti ecc., il refactoring dovrebbe essere eseguito più volte all'ora. Una copertura di test automatizzata è molto adatta come rete di sicurezza per il refactoring. Lacune nella copertura dei test e refactoring rinviato sono malattie che vengono chiamate anche debito tecnico.
8.) La vostra Definition of Done per ogni Product Backlog Item funzionale include una copertura di test completamente automatizzata e il refactoring? È improbabile che possiate sviluppare un prodotto potenzialmente rilasciabile in ogni Sprint senza apprendere i metodi dell'eXtreme Programming (come descritto ad esempio da Kent Beck, Ron Jeffries ecc.).
9.) I membri del team lavorano per la maggior parte con il Pair Programming? Il Pair Programming può migliorare drasticamente la manutenibilità del codice e ridurre il numero di bug. Tuttavia, può portare ai propri limiti e a volte sembra richiedere un po' più di tempo (se mettiamo la quantità sopra la qualità). Invece di costringere i membri del team, date il buon esempio e proponete di lavorare in coppia in certi giorni della settimana. Alcuni membri del team preferiranno presto questo modo di lavorare.
Checklist dello Scrum Master per lo sviluppo organizzativo
1.) C'è un coordinamento sufficiente tra i singoli team? Uno Scrum of Scrums è l'unico modo per ottenerlo. Inoltre, potete inviare rappresentanti del vostro team ai Daily Standup Meeting di altri team.
2.) Il coordinamento all'interno del team viene effettivamente svolto – come raccomandato – da coloro che eseguono i lavori quotidianamente?
3.) I diversi Scrum Master si incontrano per lavorare sulla lista degli impedimenti organizzativi?
4.) Gli impedimenti vengono comunicati al responsabile dello sviluppo quando appropriato? Il costo può essere misurato in termini monetari o in termini di tempo perso per l'introduzione del prodotto, qualità persa o opportunità perse per il cliente?
5.) La vostra organizzazione è una delle poche le cui opportunità di carriera sono compatibili con gli obiettivi collettivi dei team? Non è così se ci sono incentivi che portano a programmare o lavorare sull'architettura a scapito di test, automazione dei test o documentazione utente.
6.) State contribuendo a creare un' organizzazione dell'apprendimento?
7.) La vostra organizzazione è conosciuta nella stampa specializzata o presso altre fonti indipendenti come luogo di lavoro popolare o leader di mercato?
La paura è tua amica
Non appena ti rendi conto di tutto ciò che puoi fare per fare la differenza, potresti avere paura. Ma questo è solo un segno che sei sulla strada giusta.
Questo testo proviene dal blog della Scrum Alliance ed è stato tradotto in italiano da noi.
