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!