Categoria: Scrum Masdev

Di Salvatore Versienti 

—

Ho parlato di Scrum MasDev in questo articolo. Mi sono chiesto: Si può essere contemporaneamente Scrum Master e Developer all’interno dello stesso Scrum Team? Se hai voglia, fammi sapere la tua opinione.

Oggi vorrei condividere con te delle riflessioni che nascono da queste due domande:

Quali sono le condizioni che permettono di sperimentare il ruolo di Scrum MasDev?
Quali sono le sfide che uno Scrum MasDev deve affrontare per raggiungere i suoi obiettivi?

Per la prima domanda, in breve, ti direi che servono libertà e responsabilità.
Per la seconda, stando alla mia piccola esperienza, ti direi:

– gestire il conflitto d’interessi tra i due ruoli
– gestire il tempo per portare avanti le attività da Scrum Master e da Developer
– facilitare gli eventi cercando di essere neutrale ma dovendo anche dare il proprio contributo tecnico lavorare con team remoti

Prima di esplorare le risposte a queste domande, vorrei dirti che credo che queste riflessioni possano valere anche per altri “ruoli estremi”, al di là del contesto lavorativo e della specifica area di competenza.

 

Libertà e responsabilità

La libertà e la responsabilità sono fondamentali per la crescita personale e professionale, in ogni ambito, non solo nello sviluppo del software.

Per esprimere pienamente se stessi credo che uno dei requisiti fondamentali sia la libertà, dalla quale dipende la responsabilità. Sono responsabile se sono libero. Sono libero di prendere decisioni, libero di sbagliare e libero di rimettermi in gioco. Quando l’ambiente di lavoro, il team, il progetto, è impostato in modo tale da permettere di essere liberi e responsabili, nei limiti delle proprie competenze, permette anche di mettersi in gioco e di provare a superare i propri limiti. Non c’è una destinazione o uno stato finale nel quale ci si può trovare per essere pienamente soddisfatti e poter dire di aver finito il cammino. Io vedo sempre davanti a me una strada da percorrere e la speranza che si potrà sempre migliorare la propria condizione presente per essere migliore di ieri.

Intravedo chiaramente un requisito indispensabile: la trasparenza. È assolutamente necessario essere trasparenti su quali siano le competenze e i doveri da adempiere in modo tale che l’esplorazione non finisca per calpestare altre persone e quindi creare conflitti. Per fare un esempio, se svolgo il ruolo di Scrum Master è chiaro che non posso prendere decisioni che spetterebbero al PO. Bisogna stabilire bene i limiti entro i quali è possibile essere liberi e responsabili.

In questo modo sento di poter esplorare il ruolo di Scrum MasDev e sono abbastanza sicuro che queste stesse condizioni possono valere anche per altri profili “estremi” e altre realtà diverse da quelle dello sviluppo del software.

 

Gestire il conflitto d’interessi

Essere Scrum MasDev richiede un equilibrio tra sviluppo e supporto al team, come un funambolo che gestisce un conflitto d’interessi.

Questa è senza ombra di dubbio la prima sfida da superare. Lo Scrum MasDev ricopre entrambi i ruoli. Come Dev potrebbe essere tentato di concentrarsi maggiormente sulle proprie attività di sviluppo piuttosto che sul supporto al team. Come Scrum Master potrebbe essere tentato di influenzare le decisioni del team in modo che siano più favorevoli alle proprie attività di sviluppo. Credo che sia naturale vivere questo conflitto e non ci ho ancora fatto l’abitudine. In estremo, potrebbe addirittura compromettere l’efficacia del team e influire negativamente sulla qualità e sulla velocità del lavoro. In qualche Sprint lo Scrum MasDev potrebbe essere attratto maggiormente da attività di sviluppo e potrebbe trascurare il team, in altri Sprint potrebbe essere attratto maggiormente dalla cura e il benessere del team e potrebbe trascurare lo sviluppo.

Io provo a restare in equilibrio come un funambolo. L’esperienza che sto facendo mi sta insegnando che non potrò mai giungere ad una configurazione di team tale da non avere più questo conflitto. Nel momento in cui scrivo questo articolo sto cercando di trovare il modo di minimizzare gli effetti negativi di questo conflitto d’interessi.

 

Organizzare il tempo

Essere Scrum MasDev richiede un bilanciamento tra sviluppo individuale, cura del team e gestione del tempo, come un giocoliere con più palline.

L’esperienza da Scrum MasDev mi mette davanti ad una nuova sfida ogni giorno. Dal punto di vista tecnico, come Scrum Master mi sento chiamato ad approfondire sempre meglio la mia conoscenza di Scrum e in generale di Agile, come Dev vivo la sfida di stare al passo con la tecnologia in continua evoluzione.

Organizzare il tempo per poter sviluppare senza mettere a rischio gli obiettivi dello sviluppo e allo stesso tempo curare il team come se fosse un giardino di fiori è una sfida che richiede un’ottima organizzazione del tempo. Non si può improvvisare. Bisogna innanzitutto individuare degli slot per lo sviluppo che siano abbastanza grandi per consentire il focus su un task e non troppo grandi per evitare di sparire dal team per troppo tempo. Dall’altra parte della medaglia c’è la necessità di avere sempre le orecchie e gli occhi sul team per individuare problemi e stare sempre in ascolto attivo. Se gli slot per lo sviluppo sono troppo lunghi c’è il rischio di perdere eventuali segnali d’aiuto da parte del team o di alcuni dei membri. Se ci sono troppi slot di sviluppo c’è il rischio di non poter guidare il team verso la sua massima efficacia. Non c’è un algoritmo da applicare per svolgere il ruolo di Scrum MasDev per superare questa sfida. Scrum ci aiuta a ridurre la complessità con i suoi eventi ricorrenti, sempre allo stesso luogo e sempre allo stesso posto.

Per parlare di questo problema di gestione del tempo ho in mente un giocoliere con tre palline. Una pallina rappresenta le attività di sviluppo, una pallina le attività da Scrum Master verso il team e un’altra pallina le attività da Scrum Master verso il PO. Ogni pallina non può rimanere per aria più tempo di quello che serve al giocoliere per evitare di farla cadere per terra. Quando una delle attività dello Scrum MasDev dura più a lungo del limite naturale consentito dal tipo di attività c’è il rischio di far cadere la pallina per terra, quindi causare problemi a tutto il team. Inoltre, potrebbe esserci un’altra pallina per le attività da Scrum Master nei confronti dell’organizzazione. Continuerò ad esercitare le mie abilità da giocoliere ma non so ancora fra quanto tempo riuscirò a non far cadere una o più palline per terra.

 

Riflessioni finali

Ti lascio con un pensiero che mi ha guidato durante la scrittura di questa prima parte. Sono fortemente convinto che esista sempre un buon motivo per sperare che il lavoro si evolverà a tal punto che non saremo più suoi schiavi ma che il lavoro sarà davvero uno strumento nelle nostre mani e ci permetterà di esprimere pienamente la nostra libertà, con la consapevolezza che grazie ad esso possiamo già costruire quel mondo migliore che tanti sperano. In fin dei conti, il lavoro riempie gran parte del nostro tempo, non è qualcosa di slegato dalla “vita privata”.

Ho condiviso con te queste mie riflessioni e sono sicuro che un tuo feedback possa arricchire il mio punto di vista e dare a entrambi un valore aggiunto da un confronto costruttivo. Se hai il desiderio di contribuire a questa riflessione, scrivimi a salvatore.versienti@gmail.com.

Se hai nutrito interesse per questo contenuto, resta sintonizzato su questo blog per la seconda parte dell’articolo.

 

Continuiamo ad esplorare!

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!