Di Marco Passarella
——–
Durante la prima edizione del webinar “Sfatiamo i miti di Scrum”, abbiamo ricevuto molte risposte positive. Questo ci ha spinto a ripetere l’esperienza, poiché abbiamo raccolto molte domande scottanti sull’argomento.
Continua perciò la nostra serie sulle convinzioni errate che circolano a proposito di Scrum, dove cerchiamo di aiutare gli agilisti che si stanno chiedendo come migliorare il loro approccio alle metodologie Agile.
Sabrina Laterza, una Scrum Master della nostra comunità di pratica Agile Made in Italy, ha condiviso un’interessante analogia: avete mai provato la sensazione di vedere una foto perfetta della Fontana di Trevi sui social media, ma poi sperimentare la realtà affollata e caotica quando si è lì di persona? Lo stesso vale per Scrum: può sembrare perfetto durante lo studio, ma applicarlo nella vita reale può essere un’esperienza molto diversa!
Dunque, per affrontare alcune di queste difficoltà, ho avuto il grande piacere di conversare con Anna di Girolamo, Agile Coach e formatrice, fermamente convinta che Agile non sia solo per l’IT e che governare la complessità sia innanzitutto un fatto di mindset, e con Orazio Sarno, informatico nerd con esperienza internazionale nei ruoli di Agile Coach, Scrum Master, Product Owner e Developer, che sta supportando la trasformazione digitale Agile e DevSecOps di clienti della PA in questa sfida epocale.
Mito #1 – La daily e la retro si possono anche non fare
Secondo la guida Scrum, sia la Daily Scrum che la Retrospective sono eventi essenziali e dovrebbero essere fatti, ma spesso si sente dire che questi eventi possono essere trascurati o addirittura evitati.
Nella sua esperienza come Agile Coach, Anna ha notato che spesso il primo evento a essere saltato è la Daily Scrum, seguito poi dalla Retrospective. Questo indica una disfunzione all’interno del team. Spesso, questo è il risultato di una mancanza di comprensione del mindset Agile e del valore degli eventi. Alcuni segnali di allarme includono la mancanza di tempo per dedicarsi a tali eventi e una focalizzazione eccessiva sull’output e sui task operativi a scapito della condivisione, dell’apprendimento e del miglioramento continuo.
È important che il team capisca il valore degli eventi e il loro significato. Lo Scrum Master svolge un ruolo cruciale nel trasmettere l’importanza degli eventi e nel creare un ambiente sicuro e motivante per la Retrospective, in cui il team può affrontare i problemi e migliorare continuamente.
La Retrospective dovrebbe essere un momento atteso e desiderato dal team, in cui si esprimono apertamente i problemi e si cerca di migliorare. Molto importante è anche variare le modalità delle retrospettive per mantenerle interessanti e coinvolgenti.
Questo primo mito ha scaldato gli animi dei partecipanti, che hanno condiviso alcuni commenti interessanti riguardanti la Daily Scrum e la Retrospective. Hanno sottolineato l’importanza di non trasformare la Daily Scrum in un momento inquisitorio, ma piuttosto di concentrarsi su quale problema sta avendo ciascun membro del team e come gli altri possono aiutarlo. Inoltre è stato aggiunto che piace molto sentire le persone condividere i problemi che stanno incontrando e come il team possa supportarle.
Un partecipante ha anche sollevato il problema della trasparenza durante le retrospettive. Alcune persone possono tendere a nascondersi e questo può rendere difficile ottenere una piena trasparenza. Questo è un problema comune e la trasparenza richiede una grande onestà intellettuale e un ambiente psicologicamente sicuro. Ci vuole tempo per costruire la fiducia reciproca all’interno del team, ma è un processo essenziale per ottenere una retrospettiva efficace.
Orazio ha suggerito alcune tecniche per favorire la partecipazione durante le retrospettive, come chiedere feedback anonimi scritti su post-it e introdurre le webcam accese in modo graduale per consentire a tutti di sentirsi più a proprio agio nell’esprimersi.
Anna ha sottolineato l’importanza della comunicazione non verbale, consigliando di lavorare come se le persone fossero nella stessa stanza, anche se in modalità remota, per aiutare a creare un ambiente di collaborazione e connessione più forte.
In conclusione, sia Anna che Orazio hanno evidenziato l’importanza di costruire un ambiente di fiducia e sicurezza psicologica per favorire la trasparenza e il coinvolgimento durante le retrospettive. La trasparenza e l’apertura sono fondamentali per affrontare i problemi e migliorare continuamente come team.
Mito #2 – in Scrum la qualità non conta
Un altro mito frequente è che in Scrum la qualità non conta. Invece, la qualità è un elemento fondamentale nello sviluppo Agile e Scrum. Non solo, è anche uno degli elementi invariabili tra la metodologia Waterfall e Agile. Anche se Agile è basato su pochi principi, la qualità rimane un pilastro essenziale.
Il developer, secondo la Scrum Guide, ha il ruolo principale di infondere qualità in tutto ciò che fa. La professionalità di uno sviluppatore è legata alla qualità del lavoro che produce. Una mancanza di qualità può influire sulla capacità di andare a dormire sereni, sapendo di aver consegnato qualcosa che non è adeguato.
La Scrum Guide stessa menziona la qualità in diversi punti e un artefatto che parla di qualità è la Definition of Done (Definizione di Fatto). Questa definizione specifica cosa deve essere fatto affinché un elemento di backlog sia considerato completato e consegnabile. È responsabilità del team garantire che la Definition of Done venga rispettata.
La qualità è un aspetto cruciale anche durante le retrospettive. Questi eventi consentono al team di riflettere sulle prestazioni passate, individuare punti di forza e debolezza e identificare miglioramenti per fornire un lavoro di qualità sempre maggiore.
Alcune tecniche per garantire la qualità sono l’uso di metriche per misurare e valutare il codice o la code review, che aiutano a migliorare la qualità del prodotto e a fornire valore al cliente.
Inoltre, è stato menzionato che a volte in azienda si può confondere l’agilità con la “quick and dirty”, cioè rilasciare rapidamente qualcosa senza prestare attenzione alla qualità. Questo è un grave malinteso, poiché l’agilità non significa affrettarsi, ma piuttosto consegnare qualcosa di valore al cliente con la massima qualità possibile.
In conclusione, la qualità è un elemento insostituibile nell’Agile e nello Scrum. Non si tratta solo di rispettare standard e procedure, ma di sviluppare una mentalità che valorizzi la qualità in ogni aspetto del lavoro. La Definition of Done è uno strumento importante per garantire la qualità del prodotto, ma è anche responsabilità di ogni membro del team, specialmente del Developer, contribuire alla qualità complessiva del lavoro consegnato.
Mito #3 – Lo scrum Master è il project manager
Non sono mai abbastanza le volte in cui ribadire con forza la distinzione tra il ruolo dello Scrum Master e quello del Project Manager. Sono due ruoli con competenze e responsabilità diverse.
Lo Scrum Master è il custode di Scrum, si occupa di far rispettare le regole del framework e di supportare il team nello sviluppo di un prodotto di qualità, incoraggiando la collaborazione, la fiducia e la trasparenza. La sua attenzione è incentrata sul processo e sul benessere del team.
D’altra parte, il Project Manager ha una visione più ampia del progetto, con un focus sul lato business, economico e organizzativo. Solitamente, utilizza approcci predittivi o adattivi per gestire il progetto e le risorse coinvolte.
La confusione tra i ruoli può verificarsi, soprattutto nelle organizzazioni che stanno adottando l’Agile per la prima volta. È importante educare le persone e far capire le differenze tra questi due ruoli. Uno Scrum Master non deve essere coinvolto nel controllo degli sviluppatori o nella produzione di Gantt, poiché queste attività non rientrano nei suoi compiti.
Il lavoro dello Scrum Master è fondamentale per creare un ambiente di lavoro in cui il team possa essere libero di concentrarsi sul raggiungimento degli obiettivi senza interferenze esterne. Mischiare i ruoli o chiedere allo Scrum Master di fare compiti di Project Manager può compromettere l’efficacia del team e la riuscita del progetto.
La Scrum Guide definisce chiaramente i ruoli all’interno di Scrum: Scrum Master, Product Owner e Development Team. Non c’è una figura del Project Manager tra questi ruoli, poiché Scrum è incentrato sulla self-organization e sulle responsabilità condivise all’interno del team.
In definitiva, educare l’organizzazione sulle differenze tra i ruoli e mantenere chiare le responsabilità di ciascun ruolo è essenziale per ottenere il massimo valore dall’adozione di Scrum.
Mito #4 – Scrum è semplice da adottare
L’adozione di Scrum può sembrare semplice inizialmente, a causa della sua struttura chiara e delle poche pagine presenti nella guida ufficiale. Tuttavia, la sua efficace implementazione richiede molto più di una semplice comprensione della teoria. La cultura e il mindset dell’organizzazione e dei suoi membri sono fattori cruciali per una corretta adozione di Scrum.
Cambiare la cultura e la mentalità di un’organizzazione è una delle sfide più grandi nell’adozione di qualsiasi approccio Agile. Senza una mentalità aperta al cambiamento e una passione per migliorarsi continuamente, qualsiasi framework, inclusi Scrum e SAFE, rischiano di non essere adottati in modo efficace.
Inoltre, adottare Scrum significa non solo implementare meccanicamente i ruoli, gli eventi e gli artefatti, ma abbracciare i principi e i valori alla base di questo framework. La cultura agile si basa sulla collaborazione, la fiducia, la trasparenza e la responsabilità. Solo con l’impegno e la dedizione di tutti i membri del team è possibile raggiungere i risultati desiderati.
Anche l’approccio adattivo e un impegno costante nel mantenere il focus sull’obiettivo finale sono fondamentali. Con Scrum, il team si avvicina gradualmente all’obiettivo, imparando e migliorando costantemente. Questo favorisce la motivazione, che cresce nel vedere progressi costanti e nel raggiungere risultati significativi ad ogni Sprint.
L’aspetto umano e la formazione del team sono essenziali per creare una cultura di collaborazione e fiducia all’interno del gruppo. La selezione delle persone per il team Scrum dovrebbe essere un processo oculato, dove si valutano non solo le competenze tecniche ma anche l’affinità mentale e la predisposizione al cambiamento. Un team Scrum dovrebbe avere una mescolanza di competenze diverse e una forte sinergia tra i membri per funzionare al meglio.
Inoltre, il processo di formazione del team è continuo. Gli Scrum Master devono lavorare costantemente per aiutare il team a migliorare le proprie capacità tecniche e sociali. L’approccio cross-funzionale è importante non solo per quanto riguarda le competenze tecniche ma anche per l’inclusione di diverse prospettive, sfumature e background culturali, che possono contribuire a una maggiore creatività e resilienza del team.
La costruzione di un team coeso richiede tempo e pazienza. Così come una squadra di calcio o una band musicale, il successo di un team Scrum non si ottiene improvvisamente, ma attraverso la pratica, il dialogo, la condivisione e il lavoro di squadra.
Proponi il tuo mito
Anche questo incontro è stato un grande successo perché ha portato alla luce contenuti molto pertinenti e ha spinto molti partecipanti ad attivare la webcam ed entrare nel vivo della discussione per fornire idee nuove; per questo motivo, noi membri di Agile Made in Italy siamo entusiasti di continuare a organizzare questi incontri per sfatare nuovi miti.
Se anche tu hai sentito dire qualcosa su Agile e Scrum che non ti sembra corretto e vorresti approfondire, proponi il tuo mito! Scrivimi all’indirizzo m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi incontri.
A presto con altri miti di Scrum!
Sfatiamo nuovi e altri miti di Scrum – #3