Categoria: Scrum

Di Salvatore Versienti 

 

Si può essere contemporaneamente Scrum Master e Developer all’interno dello stesso Scrum Team?

Assegnare questi ruoli a due persone diverse credo che sia la soluzione migliore. È bene che lo Scrum Master non sia direttamente coinvolto nel processo di sviluppo. Di contro, nel momento storico in cui sto scrivendo questo articolo, sto sperimentando la possibilità di far coesistere questi due ruoli dentro di me e questa soluzione ibrida, per l’attuale configurazione del mio team, sembra funzionare. Non posso sapere per quanto tempo funzionerà ma posso condividere con voi la mia esperienza.

Aldilà delle opinioni e delle esperienze personali, la fusione dei due ruoli in una sola persona può essere causa di un conflitto d’interessi derivante dalla duplice responsabilità che questa figura avrebbe nei confronti del team come Scrum Master e come Developer. In qualità di Scrum Master sarebbe impegnato attivamente nella facilitazione del team e nel miglioramento continuo del processo Scrum per garantire il successo del team. In qualità di Developer sarebbe focalizzato sull’implementazione delle storie degli utenti e sullo sviluppo del prodotto.

Una domanda sorge spontanea: Come potrebbe facilitare un gruppo di professionisti se a sua volta avesse bisogno di un facilitatore nei momenti di difficoltà con i suoi compagni di squadra?

 

L’approccio empirico può guidarci

Lavorando nel mondo dei progetti complessi, come ci insegna Scrum, o meglio come ci insegna l’approccio empirico, tutto ciò che possiamo fare è sperimentare e prendere decisioni di conseguenza. In questo momento, mi sorgono due domande.

Potrebbe esserci qualche strada non ancora percorsa, qualche Scrum Team di un mondo sconosciuto, in cui lo Scrum Master possa svolgere anche il ruolo di Developer senza vivere il temuto conflitto d’interessi e doversi scontrare con le nefaste conseguenze del bisogno di essere supportato a sua volta da un facilitatore nei momenti di bisogno?

Potrebbe esprimersi liberamente con i suoi compagni Developers senza mettere a rischio la sua posizione da Scrum Master nel team e quindi perdere la sua posizione di “true leader” (per dirla alla Scrum Guide) nello Scrum Team?

Hai ragione, vorresti prendere il posto delle mie dita e scrivere altre mille domande perché nella tua mente ci sono troppi contrasti e questa situazione è alquanto bizzarra.

Non ci sono risposte assolute, così come non ci sono domande che possano coprire la quantità spropositata di dubbi che attanagliano il tuo pensiero in questo momento. Calmiamoci!

Se vogliamo essere ottimisti, non ho detto utopisti, potrebbe esserci uno scenario nel quale il doppio ruolo Scrum Master/Developer non solo può esistere ma può anche essere soddisfacente e produttivo per la crescita personale e dell’intero Scrum Team.

 

Una ricetta tra tante

Ognuno ha la propria ricetta di team perfetto, pertanto non mi aspetto che questo mio punto di vista sia l’unica verità. Potrebbe anche non funzionare, pertanto sono aperto al dialogo. Per fare una torta non si usano sempre gli stessi ingredienti perché tutto dipende dalla torta che si vuole realizzare. Se vuoi realizzare una torta che abbia il giusto equilibrio di gusto e colori, soddisfi il tuo palato e sia gradevole alla vista, puoi usare tanti ingredienti diversi. Ognuno avrà la sua ricetta. La stessa cosa per il team. Così come non esiste la torta perfetta non esiste neanche il team perfetto. Potresti rovinare la torta a causa di un ingrediente e un team a causa di un membro che non condivide il mindset del team.

La mia esperienza diretta, ancora viva e stimolante, mi spinge a parlare di uno scenario dove possa prendere forma un profilo disfunzionale che sembra poter esistere solo come assassino all’interno di un horror.

Ci sono alcune parole chiave sulle quali posso fondare questo ragionamento, quattro concetti che nella mia visione odierna di team mi permettono di articolare il mio pensiero: sicurezza psicologica, trasparenza, correzione gentile e mettersi in discussione. Gli ultimi tre sono richiami accentuati ai pilastri dell’empirismo: trasparenza, ispezione e adattamento.

 

Sicurezza psicologica

Non è mia intenzione fornire definizioni, probabilmente non le saprei neanche dare in maniera corretta. Ciò che si cela dietro questa coppia di parole apparentemente semplici è un programma di vita. Sentirsi liberi di esprimersi, senza reprimere i pensieri, senza paura che chi ascolta possa giudicarci, ha un valore ineffabile. Sprigiona un potere di comunicazione sul quale la Marvel potrebbe benissimamente realizzarci sopra un personaggio supereroe. Già me lo immagino: Scrum Masdev, il supereroe Scrum che conquista il team sperimentando vie sconosciute.

Chi si esprime liberamente, rispettando le differenze, può svolgere il proprio lavoro al meglio e raggiungere gli obiettivi.

 

Trasparenza

Prendi un po’ di fango con le mani e macchia la finestra della tua stanza. Ora mettiti alla finestra e dimmi quello che vedi per strada. Probabilmente scorgerai qualcosa aldilà della finestra ma certamente i tuoi occhi saranno infastiditi dal fango. Questo succede a quelle persone che non sono trasparenti perché macchiate dai tanti sotterfugi, dalle bugie e dal gioco sporco, come il fango. È difficile fidarsi di queste persone perché non si lasciano leggere come un libro aperto e per questo limitano la sicurezza psicologica.

La trasparenza in un team consente di guardarsi reciprocamente senza impedimenti, come quando si osserva la strada dalla finestra senza notare il vetro. Parlare con i colleghi del team dovrebbe avere questo effetto, dovremmo parlare con loro senza percepire la presenza di sporcizia, passatemi il termine, che possa impedirci di capire cosa c’è dietro le loro parole e le loro azioni.

 

Correzione gentile

Lo sappiamo, ci sono molti modi sbagliati di correggere. Soltanto uno è funziona ma è difficile da mettere in pratica: la correzione fraterna o gentile. Hai presente quando devi dire a qualcuno che sta sbagliando e senti tremare la punta dei piedi, avverti un senso di rossore e calore sul volto, inizi a diventare teso e instabile? Bene, quello è uno dei modi sbagliati per eccellenza per correggere qualcuno. Hai presente quando qualcuno compie davanti a te un errore e tu non gli dai neanche il tempo di finire l’errore che già sei pronto con la tua dotta correzione che sa di arroganza? Bene, anche questo è uno dei grandi classici errori che, vuoi sapere la verità!?, mi hanno visto vittima tante e tante volte ed è proprio per questo che sento una forte propensione a mettere in pratica la correzione gentile. Ho sentito dire molte volte che la gentilezza salverà il mondo. Ci credo! Nessuno vuole sbagliare ma sbagliare è umano. Ciò che tutti vogliamo è che nessuno ci giudichi. Ecco, dunque, che in sicurezza psicologica e gentilezza possiamo non solo correggere ma soprattutto lasciarci correggere da chi ci vuole bene, perché, ricordiamocelo, solo chi ama corregge senza offendere.

 

Mettersi in discussione

Immagina questo scenario. Un tuo compagno di squadra ti ha appena fatto notare con gentilezza che hai commesso un errore e lo ha fatto in maniera costruttiva e nel momento opportuno. Ha usato la giusta dose di amore e mitezza per esprimere questo messaggio e ti ha anche chiesto di parlarne se ne avessi avuto il bisogno. Hai avvertito una sensazione di disagio? Hai subito pensato che ciò che ti è stato detto non sia vero e che tu non sia in errore? Hai provato a giustificare il tuo errore con le solite scuse? Bene, hai commesso lo stesso errore che anche io ho commesso tante volte. In queste circostanze non siamo riusciti ad accettare la correzione gentile e di conseguenza non ci siamo messi in discussione. Se un compagno ci vuole bene e in sicurezza psicologica ci corregge gentilmente e in totale trasparenza noi dobbiamo essere pronti a rivedere la nostra posizione e a metterci in gioco per cambiare, in un processo di miglioramento continuo, per la nostra crescita personale e dell’intero team.

 

Ordiniamo le idee

I concetti che ho riportato sono figli dell’empirismo e sono quelli sui quali ho fondato l’ultimo team che sono stato chiamato a costruire. Nel momento in cui scrivo questo articolo, le persone che ne fanno parte sono ragazzi formidabili, che condividono pienamente il mindset Agile, che fondano la relazione con i compagni di squadra su questi concetti. Ho avuto l’onore di essere corretto in diverse occasioni e sono stato felice di questo perché nelle persone che mi hanno corretto non ho trovato malizia e cattiveria ma un bene sincero e una speranza nel futuro di continuare a migliorarci insieme. Ho avuto anch’io la possibilità di esercitare la virtù della correzione gentile e devo dire che ogni volta che la correzione gentile ha successo, è una soddisfazione genuina, che non si porta dietro una gioia finta e che dura poco ma dà un senso profondo di appagamento. Si sente davvero di aver fatto la cosa giusta e al momento opportuno.

Mentre scrivo questo articolo sono chiamato ad esercitare, vuoi per circostanze contingenti, vuoi per rispondere a un cambiamento in atto, il ruolo di Scrum Master e Full stack developer all’interno dello stesso Scrum Team. Questa combinazione finora ha funzionato e credo che il motivo sia strettamente legato alle motivazioni argomentate poco fa. Avere la possibilità di esprimerci senza paura, di essere trasparenti e accogliere la correzione per migliorarci continuamente, ci dà la possibilità di superare le difficoltà con più facilità. Durante ogni Sprint Retrospective, ci raccontiamo apertamente la nostra situazione, con la consapevolezza che tutti siamo orientati al cambiamento. Condividiamo una visione comune e ci consideriamo professionisti impegnati a fare del nostro meglio per raggiungere gli obiettivi.

 

Conclusione

Non posso fare pronostici, non so per quanto tempo questa combinazione funzionerà. Le variabili in gioco sono numerosissime. In un progetto complesso che richiede un approccio empirico e in un ambiente altrettanto complesso, abbiamo l’esigenza di esplorare la strada migliore per continuare a ottenere risultati positivi e tenere saldo il team. Continuiamo dunque ad adattarci.

Il contenuto di questo articolo è frutto di ciò che ho vissuto sulla mia pelle, non sono idee o opinioni su qualcosa che potrebbe essere nella mia mente ma sono estratti sintetici di una situazione reale che ha trovato la sua descrizione in questo articolo, nel modo migliore che in questo momento io sono riuscito ad elaborare.

Continuiamo ad esplorare!

Di Sabrina Elisabetta Laterza

——————-

Saper facilitare un team agile è essenziale per chi aspira a ruoli come Scrum Master, Agile Coach o Project Manager. Se sei nuovo come Scrum Master e ti trovi ad affrontare una situazione urgente che richiede la tua guida, ma non hai mai facilitato prima, come puoi prepararti?

Ciao sono Sabrina, Scrum Master in due Scrum Team di sviluppo software da circa un anno. Ho creato questa guida partendo dalle domande che mi sono posta preparando la mia prima facilitazione. Voglio condividerla con te per aiutarti a superare l’agitazione e il brivido iniziale.

Questo articolo è il risultato di ricerca e sforzi per raggiungere il mio primo obiettivo come Scrum Master: “non fare disastri e aiutare il team a raggiungere da sé il valore di cui ha bisogno.”

Ecco come ho creato la mia prima facilitazione Agile in 7 passi:

 

  1. Identifica e coinvolgi i partecipanti

Identifica chi parteciperà. Conoscere il numero di partecipanti e i loro ruoli aiuterà nella preparazione. Pianifica coinvolgimenti specifici per assicurarti che tutti si sentano ingaggiati e ascoltati. Chi parteciperà alla facilitazione: solo i membri del team o anche stakeholder e manager?

Le Domande da porsi ora sono: “Chi è coinvolto nel tema?”, “Ci sono ruoli specifici che dovrebbero partecipare attivamente?”, “Conosco già i partecipanti?”. “Cosa si aspettano dalla facilitazione?”.

Queste domande ti saranno utili, inoltre, perché potrai capire se, durante la facilitazione:

  • dovrai dedicare più tempo al team building e al warm-up nel caso di “nuovi volti”
  • o se dovrai cominciare con una “safety-check” per verificare che gli interlocutori si sentano a loro agio nell’esprimere idee, riflessioni e preoccupazioni (sicurezza psicologica), nel caso in cui partecipino persone con diversi ruoli e in presenza di conflitti.

 

  1. Definisci l’obiettivo

Alla base di qualsiasi facilitazione efficace c’è un obiettivo chiaro. Qui ti occorre sapere: “cosa vuole ottenere il tuo team da questa sessione?” Potrebbe essere un’azione specifica, una retrospettiva, ottenere una comprensione più profonda su un tema o risolvere un problema. Ad esempio, se stai iniziando un nuovo progetto, l’obiettivo potrebbe essere “Definire gli obiettivi chiave e le aspettative per il progetto”.

 

  1. Pianifica la struttura

Decidi se la tua facilitazione sarà online o in presenza. Scegli un formato che si adatti ai tuoi obiettivi, come la “Focused Conversation” o la Facilitazione Visiva, e pianifica i passaggi chiave di conseguenza.

Ad esempio, per analizzare un problema e far emergere le cause alla sua radice, nel caso della Focused Conversationpotresti utilizzare la tecnica dei 5 perché nel flusso della discussione, oppure potresti servirti di un elemento visivo come il “Fishbone Diagram” per la Facilitazione visiva.

Le domande chiave che ti possono aiutare a pianificare la struttura sono: “se dovrò facilitare in presenza avrò a disposizione lo spazio necessario?”, “qual è il livello di dimestichezza dei partecipanti con i tool per le facilitazioni online, come miro o mural, per le riunioni online?” E di conseguenza capirai se includere un on-boarding o meno alla lavagna virtuale.

Ora hai una quantità di informazioni utili per definire il tuo schema di facilitazione. A questo proposito, per farmi un’idea di come progettare i diversi momenti di una facilitazione ho trovato spunti davvero utilissimi in quest’articolo di Alessandro Ingrosso per AMI, pensato per Facilitatori che vogliono arrivare al livello Pro, e nel libro “Agile Retrospective: Making Good Teams Great” di Esther Derby, Diana Larsen, Ken Schwaber[1]:

 

  1. Prepara il materiale

Raccogli il necessario per facilitare. Crea board online, presentazioni o lavagne fisiche. Pensa a template già pronti o tecniche già “rodate” da utilizzare per cominciare e man mano che ti senti più confidente sperimenta e crea. Puoi trovare un’infinità di idee su Retromat. Assembla ora tutto ciò di cui avrai bisogno: dalla tecnologia agli strumenti visivi in presenza.

 

  1. Crea un’agenda dettagliata

Stabilisci il tempo e definisci l’agenda della sessione. Inviare via mail ai partecipanti un’anteprima dell’agenda per creare aspettative condivise è, da un lato, un atto di premura e gentilezza che fa la differenza e, dall’altro un grande risparmio di tempo che ti permetterà di saltare lunghe introduzioni. Pianifica il flusso della tua facilitazione in base all’obiettivo e ai tempi disponibili. Dettaglia ogni fase, inclusi i momenti di interazione e di pausa, questo ti permetterà di gestire al meglio il tuo tempo aiutando, così, i partecipanti ad ottenere il valore atteso entro il termine della riunione.

Un esempio di agenda potrebbe essere:

  • “Introduzione e chiarimento dell’obiettivo (con warm-up o safty-check) – 10 minuti”,
  • “Raccolta dati e attività di brainstorming – 20 minuti”,
  • “Discussione e raccolta di feedback – 15 minuti”.

 

  1. Aggiungi creatività e divertimento

Coinvolgere i partecipanti in un’esperienza ludica aiuta a mantenere alta l’energia e, inoltre, serve a creare un clima rilassato e di fiducia. Puoi sbizzarrirti introducendo un “icebreaker” per iniziare la sessione in modo leggero e positivo. Puoi servirti di tecniche e giochi, come quiz a tema o indovina la canzone.

Ogni volta che incontro nuovi team, per esempio, mi piace utilizzare una sorta di ruota della fortuna[2] con domande random divertenti per poterci conoscere e cominciare a creare un ambiente familiare e rilassato. I feedback sono molto positivi e l’effetto è che i partecipanti si aprono più volentieri.

Gamification, Storytelling e interattività sono le 3 chiavi fondamentali per organizzare facilitazioni memorabili. Permettono ai partecipanti di sviluppare il desiderio di scoprire, imparare, capire e migliorare senza sentirsi vincolati o annoiati.

Riguardo alle Retrospective vincenti, Riccardo Ciocci, in un precedente articolo e in un webinar di Agile Made in Italy, fornisce ispirazioni e consigli utili.

 

  1. L’ingrediente “Segreto” – il PDCA

Infine, proprio come Scrum insegna, segui il ciclo Plan, Do, Check, Act di W. E. Deming per migliorare continuamente le tue facilitazioni, ovvero:

Pianifica la facilitazione, mettila in pratica, valuta cosa ha funzionato e cosa puoi migliorare e, di volta in volta, adatta le facilitazioni per le future sessioni.

Questo processo continuo ti aiuterà a crescere costantemente e a migliorare velocemente come facilitatore.

 

Questa guida non è l’unica via da seguire per creare facilitazioni e non intende essere una “lista della spesa” esaustiva, ma si tratta della condivisione di alcune delle pratiche che ho sperimentato in prima persona per mettere a terra la mia prima facilitazione agile.

Per realizzarla ho consultato alcuni blog autorevoli di settore, ho fatto tante domande e chiesto pareri di diversi professionisti con una grande esperienza sulle spalle, partendo proprio dai colleghi di Agile Made in Italy. Ho partecipato, in prima persona come parte di un team in alcune sessioni di facilitazione messe a disposizione da colleghi internazionali su meetup ed ho preso un pizzico di coraggio proponendomi come facilitatore per alcune attività di Agile Made in Italy per poter imparare nel modo più efficace possibile: dall’esperienza, dai feedback e dagli “errori”.

Ora hai un kit d’emergenza per creare la tua prima facilitazione agile! Con questi passaggi fondamentali spero tu possa avere le idee un po’ più chiare, sentirti sicuro e carico per creare la tua prima facilitazione per team agile. Pianifica, testa, implementa… ma soprattutto: divertiti e fammi sapere com’è andata! [3]

 

 

[1] Puoi leggere qui un estratto da Google Books del libro “Agile Retrospective: Making Good Teams Great”.

[2]  Ho creato un esempio di ”gira la ruota a tema Halloween”, lo trovi qui.

[3] dammi pure i tuoi feedback qui.

Di Marco Passarella

———

In questo articolo parliamo della prima puntata di “Sfatiamo i miti di Scrum”, la serie di webinar di Agile Made in Italy nata per tutti gli agilisti che stanno utilizzando il framework Scrum, ma incontrano difficoltà ad applicarlo concretamente e si stanno chiedendo come migliorare il loro approccio alle metodologie Agile, e in particolare all’utilizzo del framework Scrum.

Nel corso del webinar ho avuto il piacere di conversare con tre membri di Agile Made in Italy che hanno condiviso le loro esperienze: Alessandro Ingrosso, Agile Coach e Trainer con esperienza decennale nella collaborazione con importanti aziende italiane di formazione e settore IT; Riccardo Ciocci, Scrum Master e consulente presso la società di consulenza BIP Spa, che ha introdotto i concetti di Agile e Scrum in diverse aule e ha scritto articoli su argomenti correlati; e Sabrina Laterza, ex filosofa e marketer digitale, che attualmente lavora come Scrum Master presso l’azienda Progetti e Soluzioni Spa.

Ci siamo chiesti subito a che punto siamo con l’Agile? Abbiamo menzionato la sedicesima edizione del report “State of Agile”, un rapporto indipendente che fornisce dati sullo stato e l’andamento dell’Agile a livello globale, grazie ai dati provenienti da interviste a oltre 3200 Agile coach o scrum master.

L’89% degli intervistati ha espresso l’importanza dei valori centrati sulle persone e della leadership per ottenere benefici dall’approccio Agile. Inoltre, sottolinea come l’utilizzo delle pratiche agili migliori la collaborazione, l’allineamento con gli obiettivi aziendali e l’ambiente di lavoro. Infine, si è menzionato che Scrum è la pratica più adottata a livello mondiale, utilizzato da 9 su 10 intervistati. Kanban è risultato essere la seconda pratica più diffusa. 

Abbiamo dato uno sguardo anche a ciò che non sta funzionando bene: cultura, leadership e coerenza sono le tre sfide fondamentali. È emerso che spesso la leadership non comprende appieno l’Agile o addirittura mette ostacoli alla sua adozione. Altre sfide includono la mancanza di priorità chiare, la mancanza di una comprensione adeguata da parte dei team riguardo a cosa significhi Agile e come intraprendere il percorso correttamente.

L’Agile non è qualcosa che le aziende colgono intuitivamente. I coach e i consulenti Agile, ma anche gli scrum master che stanno lavorando per espandere l’adozione di Agile, devono continuare a lavorare per assicurarsi che il management e i team di lavoro cross-funzionali capiscano cos’è l’Agile e come influirà sul loro lavoro, poiché la statistica annuale mostra la necessità di migliorare la comprensione dell’Agile da parte delle aziende. 

Dopo questa panoramica generale sullo stato dell’Agile, l’incontro è entrato nel vivo dei miti di Scrum. Il primo mito che abbiamo preso in considerazione è “Basta vedersi ogni giorno per fare Scrum”. Capita frequentemente di incontrare persone orgogliose perché hanno iniziato a vedersi ogni giorno e sono centrate sulle cerimonie e su quello che è scritto nella guida Scrum. Ma questo da solo non basta. Sarebbe un po’ come andare ogni giorno in palestra senza usare nessun attrezzo e aspettarsi di mettere su massa muscolare o dimagrire. Abbiamo sottolineato come sia importante approfondire il contesto e comprendere che Scrum non è una soluzione magica per garantire consegne perfette e puntuali. Scrum non può compensare problemi strutturali o di pianificazione all’interno di un progetto.

Sebbene gli eventi Scrum vengano eseguiti regolarmente, potrebbero mancare la sostanza e il valore che dovrebbero fornire. L’aspetto formale delle pratiche agili può essere fuorviante se la sostanza e il mindset dietro di esse non sono presenti. Abbiamo ascoltato un’esperienza personale in cui un progetto è stato avviato seguendo le pratiche Scrum, ma il prodotto e le sue funzionalità erano già prestabilite e non richiedevano ispezioni, adattamenti o feedback continui. Questo ha portato a una situazione in cui gli eventi Scrum venivano eseguiti solo perché era richiesto, senza fornire il valore atteso. L’applicazione di Scrum richiede un mindset centrato sulle persone, il soddisfacimento del cliente e il valore che si intende offrire. Due segnali importanti per valutare se un progetto sta andando verso una direzione Agile sono la necessità di sperimentare e l’importanza dei feedback. Se un progetto è completamente pianificato e non richiede sperimentazione o feedback, allora potrebbe non essere necessario applicare Scrum. È importante considerare la complessità del contesto e adattare il mindset di conseguenza. Gli eventi di Scrum sono solo una rappresentazione visibile di tale mindset e non possono garantire il successo di un progetto se la sostanza e il contenuto non sono presenti. Questo mito perciò ci ha fatto considerare l’importanza del mindset e della cura delle persone come base per l’applicazione efficace di Scrum. 

Il secondo mito di cui abbiamo discusso è “Scrum consente di consegnare tutto e in tempo”. Questo mito è spesso alimentato da una mentalità di pushing dei requisiti all’interno dello sprint, senza considerare la creazione di valore e l’importanza dei feedback.

Lo sprint goal non può essere l’obiettivo di completare tutte le cose prese in carico durante lo sprint, altrimenti diventa micro waterfall e tutto perde di senso. Lo sprint è un’opportunità per fare un tentativo di creare valore, sperimentare e apprendere. È importante comprendere che Scrum è incentrato sulla creazione di valore e non sull’output numerico di caratteristiche o ticket risolti.

Durante questa conversazione è arrivata una domanda proveniente da LinkedIn riguardante l’aggiunta di requisiti non concordati durante lo sprint. Si è evidenziato che la risposta dipende dalla definizione delle user story, dai criteri di accettazione e dalla comunicazione con il cliente. È importante coinvolgere il cliente o il business per chiarire se la richiesta aggiuntiva è effettivamente un’aggiunta o un requisito mancante. Questa è stata l’occasione per ribadire l’importanza di coinvolgere il cliente per comprendere le sue esigenze e valutare l’aggiunta di requisiti non previsti. Il confronto e la negoziazione sono essenziali per gestire queste situazioni in modo efficace.

Spesso si sente dire: “lo scrum Master deve essere uno sviluppatore”. Abbiamo perciò discusso dell’importanza di comprendere le competenze e il ruolo dello Scrum Master al di là delle capacità tecniche.

Il ruolo dello Scrum Master va al di là delle competenze di sviluppo software. Lo Scrum Master deve concentrarsi sulla comunicazione efficace con il team, sulla gestione dei conflitti, sulla creazione di un ambiente di sicurezza psicologica e sul supporto alla padronanza del team. È un ruolo che richiede una visione d’insieme, competenze di facilitazione e la capacità di far emergere soluzioni attraverso domande potenti.

Abbiamo condiviso un esempio personale di un’esperienza come Scrum Master senza conoscenze tecniche approfondite. Anche in questo caso il focus deve essere sulle persone del team e sulla creazione di fiducia, piuttosto che risolvere direttamente i problemi tecnici. Abbiamo ribadito che Scrum può essere adattato a diversi ambiti e che il vero sviluppo professionale come Scrum Master consiste nel focalizzarsi sulle persone e non solo sulla soluzione del problema.

Infine, abbiamo accennato alla domanda frequente su cosa faccia lo Scrum Master durante il resto del tempo, sottolineando che il ruolo dello Scrum Master va oltre le attività di planning, daily stand-up, review e retrospective, e che è importante non sottovalutare le competenze richieste per facilitare il team in modo efficace.

Nell’ultima parte del webinar abbiamo affrontato alcune domande dei partecipanti. Una di queste ha riguardato come dovrebbe comportarsi uno Scrum Master quando si trova a dover affrontare compromessi forzati che portano a un modello ibrido di Scrum ed esecuzione.

Abbiamo sottolineato che Scrum è un mindset e non una metodologia rigida, e che ciò che conta è il valore e l’agilità del team, piuttosto che aderire rigidamente a quanto scritto nelle guide. Ogni persona ha la propria idea di cosa significhi Agile, e il ruolo dello Scrum Master è quello di essere un agente di cambiamento, aiutando le persone a sviluppare la loro consapevolezza e conoscenza gradualmente.

Un modello ibrido può sicuramente emergere e se sta funzionando, se porta risultati e le persone sono motivate, potrebbe non essere necessario forzare un approccio diverso. Al contrario, si può costruire intorno a ciò che sta emergendo e che funziona, e sperimentare eventualmente in seguito.

Spesso le divergenze sull’agilità derivano dalle diverse interpretazioni individuali del concetto. È importante allineare le diverse visioni e interpretazioni all’interno dell’organizzazione per evitare conflitti e favorire una comprensione condivisa di cosa significa essere agili.

L’ultimo mito della serata ha riguardato l’idea di cross funzionalità nei team e dei miti ad essa associati. Si afferma spesso che tutti i membri del team devono saper fare tutto, ma in realtà spesso si richiede l’aiuto di team esterni per competenze specifiche. Ciò può creare un disequilibrio nel lavoro e generare frustrazione tra i membri del team. Abbiamo commentato che la cross funzionalità vera e propria si raggiunge quando il team ha un’ampia gamma di competenze e quando c’è un’effettiva collaborazione e scambio di conoscenze tra i membri. Tuttavia, ciò può essere ostacolato dalle politiche e dalla cultura organizzativa che valutano le performance individuali solo in base al proprio lavoro anziché alla condivisione delle conoscenze. La soluzione è promuovere la formazione e la condivisione delle competenze all’interno del team, anche a discapito della velocità di consegna. La velocità, infatti, non dovrebbe essere l’unico obiettivo da perseguire, ma piuttosto la qualità e la crescita complessiva del team.

Questo primo incontro è stato un grande successo, ha fatto emergere contenuti molto attuali e ha spinto numerosi partecipanti ad entrare nel vivo della discussione e a proporre spunti nuovi, incoraggiando noi di Agile Made in Italy proseguire con questi incontri per sfatare altri miti.

Se anche tu hai in mente delle convinzioni errate su Agile e Scrum che vorresti approfondire, proponi il tuo mito! Scrivimi all’indirizzo m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi momenti di incontro. 

A presto con altri miti di Scrum!

Sfatiamo altri miti di Scrum – #2

Sfatiamo nuovi e altri miti di Scrum – #3

 

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 i miti di Scrum – #1

Sfatiamo nuovi e altri miti di Scrum – #3

 

 

Di Marco Passarella

—-

 

Mercoledì 12 luglio è andata in onda un’altra puntata di “Sfatiamo i miti di Scrum”, la serie di webinar di Agile Made in Italy nata per coloro che stanno utilizzando il framework Scrum in azienda, ma incontrano difficoltà ad applicarlo concretamente e si stanno chiedendo come migliorare il loro approccio Agile. 

Abbiamo ascoltato l’esperienza sul campo dei membri di Agile Made in Italy: Vittorio Polizzi, Kanban Coaching Professional e Matteo Toto, CTO della startup Unguess e agilista di lunga data. Insieme a loro ho avuto modo di conversare su come superare alcuni degli ostacoli più comuni nell’applicazione di Scrum.

Il primo mito che abbiamo sfatato è “La velocity è la performance del team”. Partendo dal presupposto che la velocity è un indicatore interno al team, un numero empirico che ha senso soltanto all’interno dello sprint e ricavato semplicemente dalla somma degli story point, abbiamo concordato che non avrebbe senso prendere questa metrica come indicatore di performance del team. La velocity, infatti, può essere “sexy” quando si impenna, ma l’obiettivo deve essere la stabilità, segno che il team ha raggiunto un ritmo di lavoro sostenibile. Da qui l’importanza di valutare i trend: è l’andamento della velocity che ci deve interessare, e che può essere argomento di retrospective quando vediamo che la curva inizia ad avere dei picchi incontrollabili, sia in positivo che in negativo. 

Il secondo mito che è emerso dalla discussione è “In Scrum si rilascia solo a fine sprint”. La falsità di questo assunto è data dal fatto che Scrum nasce proprio per consentire rilasci di prodotto molto veloci. Per farlo però servono qualità, disciplina e coraggio. Rilasciare molto frequentemente consente di ottenere cicli di feedback più rapidi. Questo è molto vantaggioso, anche se, soprattutto all’inizio, questo può avere dei costi, soprattutto sul piano emotivo del team, che vive il momento di portare un incremento in produzione con l’ansia che qualcosa possa andare storto. Ma la verità suggerita dall’esperienza è che rilasciare frequentemente abbatte drasticamente il rischio. Un punto importante è legato alla competenza del team e alla propensione all’utilizzo delle tecniche di sviluppo più aggiornate. Se i developer utilizzano politiche di rilascio basate su automazione, continuous integration, continuous deployment, rilasci in produzione su subset di utenti, allora possono affrontare il delivery con maggiore tranquillità. Si è parlato anche di code review applicata al lavoro dei dev, non tanto come strumento di giudizio sull’operato del singolo, ma come salvaguardia del prodotto. In questo modo diventa un fattore di responsabilizzazione e di crescita per tutto il team. Queste pratiche vanno anche a far parte della Definition of Done, a conferma del fatto che la qualità del prodotto è sempre al primo posto. 

Infine, dall’ambito dello sviluppo, ci siamo spostati a quello del business, mettendoci dalla parte di un cliente con il mito “Se lavori Agile non so per cosa pago”. Il cliente può non essere disposto a pagare per un prodotto che ancora non sa quale direzione prenderà. La prima considerazione è che serve un allineamento culturale tra cliente e fornitore, che devono perdere questa connotazione e iniziare a sentirsi partner. Deve essere un rapporto in cui entrambi gli attori sono dalla stessa parte. Quando si crea questa alleanza, allora si comprende che è impossibile mettere nero su bianco tutto il dettaglio all’inizio. Si possono condividere gli obiettivi (outcome), ma poi per quanto riguarda le soluzioni tecniche (output) in Agile si può cambiare rotta anche di mese in mese. Un’esperienza emersa nella discussione ha di fatto evidenziato come una possibile soluzione sia quella di iniziare un rapporto di collaborazione riducendo al minimo il progetto. Se invece di concordare uno sviluppo di un anno o di sei mesi, si concorda di sviluppare un MVP (Minimum Viable Product), un mini prototipo funzionante, si ha la possibilità di vedere subito risultati concreti, di ottenere qualcosa di funzionante e di validare l’efficacia della metodologia di lavoro. In Italia c’è ancora molta diffidenza verso l’approccio Agile, ma molti segnali positivi stanno emergendo, e non solo nel privato, ma addirittura anche nella Pubblica Amministrazione. Abbiamo parlato infatti dell’esperienza di INPS, che ha rinnovato un servizio sviluppando in Agile e con un contratto del tipo “money for nothing, changes for free”: se nel tempo cambiano i requisiti, il cliente può chiedere di cambiare il prodotto, senza costi aggiuntivi (changes for free). Allo stesso modo, se lo sviluppatore raggiunge gli obiettivi prima del tempo, gli viene corrisposto l’intero compenso pattuito (money for nothing). La diffusione di questa mentalità è un ottimo segnale per il nostro Paese.

Come sempre in questi incontri, c’è stata una bella sinergia tra tutti i partecipanti, con interventi inattesi e di grande spessore. Noi di Agile Made in Italy continueremo a incontrarci regolarmente per sfatare altri miti, se anche tu hai in mente delle convinzioni errate su Agile e Scrum che vorresti approfondire, proponi il tuo mito! Scrivimi a m.passarella@agilemadeinitaly.com e capiremo insieme come inserirlo nei prossimi momenti di incontro. 

A presto con altri miti di Scrum!

 

Sfatiamo i miti di Scrum – #1

Sfatiamo altri miti di Scrum – #2