IT 
EN 
JA 
ES 
Nessuno ha tempo per quello
Hai effettuato la tua terza chiamata MS Teams della giornata. Un'ora dopo riattacchi, chiedendoti quale fosse lo scopo. Non preoccuparti, pensi, forse sarà più utile la prossima settimana? Siamo stati tutti lì, eppure decidiamo di continuare a partecipare. Prima di approfondire gli eventi Scrum, ritengo utile condividere alcuni suggerimenti che Elon Musk ha detto ai suoi dipendenti Tesla:
Stop alle grandi riunioni. Elimina le riunioni frequenti. Abbandona una riunione se non stai contribuendo. Elimina il gergo. Comunicare direttamente, indipendentemente dalla gerarchia. Segui la logica, non le regole.
Per coloro che non sono a conoscenza dello stile di leadership carismatico di Musk, il suo approccio si basa sul dare potere a individui e team per portare a termine le cose. I suoi dipendenti possono aspettarsi che la loro direzione dia loro ciò di cui hanno bisogno e non si frapponga, ma soprattutto, il team deve scoprire ciò di cui hanno bisogno e renderlo trasparente. Tutti sono responsabili ed è qui che entra in gioco Scrum.
Gli Scrum Team sono efficaci quando si autogestiscono. Purtroppo, è un concetto comunemente frainteso; scambiandolo per significare che il team gestisce la propria intera esistenza senza il supporto della propria organizzazione - non è così. L'autogestione è quando un team decide chi fa cosa, quando e come e, cosa importante, gli eventi Scrum sono alla base di questo concetto. In ambienti complessi (dove più è sconosciuto che noto), avere le persone più vicine al problema è vitale. La capacità di ruotare rapidamente, supportata da un rapido time-to-market e da severi controlli di qualità è il fulcro di ciò che significa effettivamente Business Agility.
Ma - e c'è un grande ma, quando gli Scrum Team non hanno il potere di autogestire e controllare il proprio destino, il valore ne risentirà sempre. Il motivo è dovuto al sottostante ciclo di feedback empirico di Scrum che richiede trasparenza, ispezione e adattamento frequenti, ma è normale che i nostri utenti siano troppo occupati per aiutarci a ispezionare il nostro lavoro. Di conseguenza, gli eventi Scrum diventano meno incisivi, più formulati e alla fine arrivano a un punto in cui un team dirà "possiamo semplicemente mettere insieme questi due incontri?". Per uno Scrum Master, questa è una scintilla che sta per accendere un incendio: il tuo team è ora a un punto in cui non vede il valore di ogni evento Scrum, quindi vuole accorciarlo.
Per coloro che sono interessati al motivo per cui viene chiamato "evento" Scrum piuttosto che "riunione", è in parte dovuto alla psicologia (gli eventi sembrano più importanti e di impatto) ma anche perché ognuno ha un risultato e azioni chiari. Quando diventa una sensazione di "nessuno ha tempo per quello", allora stiamo perdendo un'opportunità per il nostro team di essere in grado di affrontare la volatilità e l'incertezza. Le cose cambiano e gli eventi ci aiutano a decidere formalmente sugli adattamenti che dobbiamo apportare per migliorare la nostra offerta di valore e aumentare il ritorno sull'investimento. Scrum fornisce cinque di questi eventi che fanno parte del framework, puoi nominarli?
Mischia quotidiana – Un evento timeboxed di 15 minuti per gli sviluppatori (lo Scrum Master e il prodotto possono partecipare ma in genere non partecipano) per consentire loro di ispezionare i progressi compiuti verso il proprio Sprint Backlog nelle 24 ore precedenti. Le loro discussioni si concentrano sullo Sprint Goal e possono comportare l'aggiunta o la rimozione di elementi dallo Sprint Backlog.
Pianificazione dello sprint – Un evento timeboxed di 8 ore per l'intero Scrum Team per discutere il Perché (Sprint Goal), Cosa (Sprint Backlog) e Come (il piano) per lo Sprint. Richiede molto tempo e, se fatto bene, attenua la necessità di riunioni aggiuntive.
Recensione Sprint – Un evento timeboxed di 4 ore per gli stakeholder (organizzazione e utenti) invitati dal Product Owner per ispezionare l'incremento prodotto dallo Scrum Team. Solo il lavoro che soddisfa la definizione di Fatto può essere ispezionato e presentato, ma questa non è semplicemente una dimostrazione, è una discussione di lavoro. Gli output e i risultati sono un Product Backlog riordinato e, si spera, una migliore comprensione di cosa concentrarsi nel prossimo Sprint.
Retrospettiva Sprint – Un evento programmato di 3 ore per lo Scrum Team per riflettere con onestà e trasparenza sul proprio processo. Considerano ciò di cui hanno bisogno per migliorare nel prossimo Sprint e possono aggiungere lavoro al loro Sprint Backlog per affrontare questi miglioramenti.
Lo Sprint – L'evento incapsulante che contiene tutti gli altri. Ogni Sprint è un mini-progetto e dovrebbe essere trattato indipendentemente dagli altri Sprint. Fornisce un breve sforzo focalizzato su un singolo Sprint Goal.
Tornando al punto di Elon sull'interruzione delle grandi riunioni, i timebox sembrano piuttosto grandi, giusto? Sono d'accordo, ma questi timebox sono massimi e non minimi; è il risultato che conta. L'autogestione riguarda fondamentalmente lo Scrum Team che facilita questi eventi e controlla l'ecosistema del proprio Prodotto. Forse è utile paragonare uno Scrum Team a un team di medici? Un'ostetrica ti mette al mondo, i dottori si prendono cura di te continuamente e quando le cose vanno male, ti rimetteranno insieme. Un team autogestito è interfunzionale per essere in grado di fare tutte queste cose (elaborazione dei requisiti, scrittura del codice, test, infrastruttura e rilascio) e si muove per ridurre eventuali dipendenze che hanno da altre persone.
Se ti trovi in una posizione in cui il valore dei tuoi eventi Scrum sta diminuendo, prova l'approccio BEAF; confine, esecuzione, azione, conclusione. Inizia affermando ciò che stai (come collettivo) cercando di ottenere, puoi limitare le tangenti e affermare il valore in presenza di tutti. Segui questo con un'esecuzione nitida, focalizzata esattamente su ciò che stai cercando di ottenere e nient'altro. Chiudi con le azioni assegnate e il loro scopo. Il quarto punto è ovvio ma così spesso dimenticato: se finisci prima, chiudi l'evento! Non riempire il calendario. Mostra rispetto ai partecipanti raggiungendo il risultato e finendo presto, o almeno in tempo.
Un ultimo punto da notare sugli eventi Scrum, le riunioni e l'agilità in generale sono le "metriche". Devi assolutamente e inequivocabilmente comprendere l'impatto del lavoro che svolgi (una buona risorsa da consultare è la Guida alla gestione basata sulle prove) e questo viene spesso dimenticato. Potresti dimostrare in modo quantificabile ogni Sprint che sei andato avanti? Quando discuti con la leadership, potresti mostrare loro i soldi che hai risparmiato attraverso un'iniziativa? Sebbene tu possa trovarti in una situazione unica in quanto sei sia il cliente che il fornitore, non è irragionevole aspettarsi che queste metriche vengano raccolte come strumento per aiutarci a ispezionare noi stessi. Qualsiasi team autogestito dovrebbe capirlo.
In sintesi, assicurati che le tue riunioni e gli eventi Scrum siano mirati per tutti. Se non lo sono, hai un problema, perché quando sorge la volatilità, e accade sempre, ti troverai in una posizione peggiore rispetto a una squadra che esercita regolarmente un ciclo di feedback empirico. Se non sei sicuro che i tuoi eventi stiano colpendo nel segno, considera semplicemente "Ho offerto o ottenuto qualche vantaggio dall'essere qui?" – se la tua risposta è no, sollevala nella prossima Sprint Retrospective e lavora con il team per risolverla.
Nelle parole dell'omonima GIF:
