Categoria: Senza categoria

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 Riccardo Ciocci

 

Cosa si intende per servant leadership?

“Una filosofia di leadership in cui l’obiettivo del leader è servire. Diversamente dalla leadership tradizionale in cui l’obiettivo principale del leader è la prosperità della propria azienda o organizzazione. Un leader servente condivide il potere, mette al primo posto le esigenze dei dipendenti e aiuta le persone a svilupparsi e ad ottenere prestazioni il più elevate possibile”.
Questa è la definizione di servant leadership data dalla pagina inglese di Wikipedia.
Appena si legge questa definizione il primo pensiero è “che bello sarebbe avere come capo una persona del genere”, il che rende la figura del servant leader simile a quella dello Yeti: tutti ne parlano, alcuni dicono di averlo visto, ma per la scienza non ci sono prove della sua esistenza.
E quindi la prima domanda che ci si pone è: il servant leader esiste?

 

Servant leader: un bisogno primordiale

Per rispondere a queste domande ci viene in aiuto un testo di Simon Sinek, scrittore, noto motivatore e consulente di marketing inglese: Leader at Least (Ultimo viene il leader) del 2014.
Il tema da cui partire è che il servant leader non è una scoperta, ma una riscoperta.
Sinek espone in maniera analitica quali sostanze producono piacere nella specie umana. Esse sono quattro, nell’ordine: endorfina, dopamina, serotonina e ossitocina.
Le prime due sostanze sono in comune con moltissimi altri esseri viventi e sono prodotte dai risultati che vengono raggiunti individualmente. Esse riguardano unicamente noi stessi e ci danno la forza di raggiungere degli obiettivi che ci prefiggiamo.
Le ultime due invece sono uniche della razza umana, si sono sviluppate insieme alla neocorteccia all’epoca degli homo sapiens e ci danno il piacere nello stare con gli altri. Ci danno la sensazione di essere gratificati dai complimenti dell’altro, e ci danno la soddisfazione di aver aiutato una persona cara.
Citando testualmente:
“L’ossitocina però non ha il solo scopo di farci sentire felici. È anche vitale per il nostro istinto di sopravvivenza. […] È grazie all’ossitocina se riusciamo a fidarci di un altro nel momento in cui costruiamo il nostro business, facciamo qualcosa di difficile, dobbiamo uscire da un momento di crisi. È grazie all’ossitocina se siamo sensibili ai rapporti umani e ci piace stare con quelli che amiamo. L’ossitocina fa di noi degli animali sociali.”
Queste parole ci danno la giusta dimensione di quanto lavorare in team con persone con cui abbiamo un rapporto di fiducia sia un bisogno insito nel genere umano. Spesso, infatti, chi lavora a contatto con il pubblico, una volta finito di lavorare preferisce passare del tempo in solitudine. Al contrario chi svolge un lavoro che manca di relazioni con altri, queste vengono ricercate fuori dall’ambiente lavorativo. È una questione di equilibrio tra le quattro sostanze.

 

Agile, Scrum e Servant leadership

Ci sono diverse realtà che cercano di seguire la rotta della leadership servente e Sinek ne illustra diverse che nel corso degli anni si sono distinte per questo nel panorama americano, ma possiamo fare un ulteriore passo avanti: l’apertura all’errore, la collaborazione, la condivisione delle conoscenze sono concetti molto familiari per tutte quelle aziende che stanno applicando l’Agile Manifesto e il Framework Scrum.
All’interno dello Scrum Team possiamo infatti rilevare la presenza dello Scrum Master, ovvero di un leader a servizio del team, che supporta la squadra senza acquisirne il comando lavorando sulla fiducia (del team e dell’organizzazione in generale), sulla gestione dei conflitti, sulla comunicazione, oltre che sulla diffusione della cultura Agile e del framework Scrum.
Non per questo dobbiamo essere indotti a pensare che un servant leader sia possibile solo attraverso i framework Agile.
Come detto tante aziende sono riuscite a creare un clima di fiducia reciproca anche senza l’utilizzo di Scrum.
Ma di sicuro ora possiamo dare una risposta alla nostra primissima domanda:
Sì, il servant leader esiste.

 

Creare il cerchio della sicurezza

Nel privato come nel lavoro c’è bisogno di instaurare dei rapporti autentici, relazionali e professionali; non si tratta di amicizia ma di ciò che Sinek definisce “cerchio della sicurezza”.
In un gruppo di gazzelle quando la prima gazzella avverte il pericolo di un leone che sta per attaccare e inizia a correre, tutto il branco inizia a scappare insieme a lei. Nessuna gazzella mette in dubbio il perché la prima ha iniziato a correre, ognuna sa che c’è un pericolo e si fida del comportamento della compagna.
In un “cerchio della sicurezza” le cose accadono allo stesso modo. Ogni elemento nel cerchio tutela se stesso e ogni altro membro del team, con la certezza che anche gli altri faranno altrettanto.
L’obiettivo è allargare il cerchio della sicurezza affinché non riguardi solo il team di lavoro ma possa includere l’organizzazione nella sua interezza.
Come fa il servant leader a lavorare al cerchio della sicurezza?

Mantenere il contatto con la realtà. Tenere unite le persone.
Per quanto possano essere utili e funzionali i contatti che manteniamo con chat o mail, niente può sostituire l’incontro faccia a faccia (sesto principio dell’Agile Manifesto).

Gestibilità. Obbedire al numero 150[1].
Ricordare che una persona non può mantenere dei rapporti basati solidi, basati sulla fiducia con più di centocinquanta persone. Il lavoro da remoto non aumenta questo numero[2].
Il top management se vuole che i dipendenti si sentano all’interno di cerchi della sicurezza nel proprio posto di lavoro, deve far in modo che il personale massimo in una sede non superi questo numero.

Incontrare le persone che si devono aiutare.
Incontrare personalmente i dipendenti o i membri del team contribuisce ad alimentare la motivazione.

Dare tempo e non solo soldi.
Un vero leader viene riconosciuto come tale quando è disposto a dedicare alla propria squadra l’unica risorsa che non può essere rigenerata: il tempo.
La riconoscenza e il senso di appartenenza di un membro rispetto al resto del team, sarà tanto maggiore quanto più tempo si sarà speso in tal senso.

Pazienza. La regola dei sette giorni e dei sette anni.
Quanto tempo ci vuole per creare il rapporto di fiducia tale da creare il “cerchio della sicurezza”?
Io non lo so, ma Sinek scrive che ci vogliono più di sette giorni, ma meno di sette anni.

La cultura aziendale gioca un ruolo determinante anche in termini di competitività e in un mondo sempre più complesso caratterizzato da veloci cambiamenti, chi di noi non vorrebbe un cerchio della sicurezza in cui lavorare?
Spazio quindi alle relazioni umane sane, solide e ben orientate: il leader che smette di guidare e si pone al servizio ha la grande opportunità di contribuire a costruire una nuova cultura organizzativa.

 

 

[1] Sinek riporta alla base la legge di Dunbar che riporta l’impossibilità dell’uomo di mantere più di 150 relazioni stabili. Citando testualmente: “Robin Dunbar, antropologo inglese e professore al Dipartimento di Psicologia sperimentale di Oxford […] ha dimostrato che una persona non è in grado di gestire più di centocinquanta relazioni dirette alla volta con I propri simili. ‘In altri termini’, come piace dire a lui, ‘si tratta del numero di persone con cui non vi sentireste imbarazzati a sedervi a bere qualcosa senza essere stati invitati se vi capitasse di incontrarle in un bar.”

 

[2] L’autore riporta le conclusioni di un esperimento fatto dal giornalista Rick Lax su wired.com nel marzo del 2012 raccontato in un articolo dal titolo: “Dunbar’s Number KIcked My Ass in Facebook Friends Experiment.”

Sinek scrive: “Molti hanno creduto che, con l’arrivo di Internet, il numero di Dunbar sarebbe diventato obsoleto. Che saremmo stati in grado di comunicare simultaneamente con tante persone e avremmo potuto gestire in modo efficace un numero superiori di relazioni. Ma I fatti dimostrano che non è così. La partita la vince di nuovo l’antropologia. Possiamo avere anche 800 amici su Facebook, ma è improbabile che li conosciamo tutti personalmente, così come è improbabile che tutti e ottocento ci conoscano personalmente. Se vi sedeste e provaste a contattarli uno per uno, come ha fatto Rick Lax, un giornalista di wired.com, vi accorgereste subito che il numero di Dunbar è sempre valido. Lax si è stupito nel constatare quanto fossero pochi, tra I suoi oltre duemila ‘amici’, quelli che effettivamente conosceva e che conoscevano lui.”