Agile: le persone al centro

di Giovanni Melis

Versione PDF “Pretty”

https://agileitalia.agileforitaly.com/index.html#1_2019

Gli esordi come sviluppatore

Quando nel 2010 da neolaureato iniziai un percorso professionale come sviluppatore web la mia visione del mondo del lavoro era abbastanza chiara: l’obiettivo nel breve periodo sarebbe stato convincere chi mi aveva assunto che la sua scommessa su di me non fosse un azzardo. Per riuscire in questo intento prima di tutto avrei dovuto dimostrare di saper fare qualcosa e quel qualcosa doveva essere sicuramente tecnico. Se è vero che un bravo ingegnere informatico risolve problemi (software), allora sarebbe stato necessario imparare bene un linguaggio di programmazione, riuscire a destreggiarsi con disinvoltura nel codice scritto da altri e magari inventare qualcosa di abbastanza innovativo per meritare una menzione.

Fu proprio nel tentativo di scalare la ripida salita da me stesso definita che incontrai le prime difficoltà. Era come se qualcosa non tornasse nel mio disegno, nel percorso che avevo io stesso stabilito in tappe molto serrate. All’inizio non ne capivo il motivo: scrivevo codice, rimanevo in ufficio oltre l’ orario di lavoro per tentare di dare uno slancio a una corsa faticosissima e i risultati
tardavano ad arrivare. O meglio: per l’ azienda ciò che producevo andava bene, ma nonostante lo sforzo non avanzavo alla velocità che volevo nel mio personale percorso.

Da buon venticinquenne istruito alla teoria e quasi per nulla alla pratica, non avevo considerato un paio di aspetti poi divenuti molto chiari. Nel tentativo di emergere mi ero talmente focalizzato su me stesso da non riconoscere l’importanza di crescere insieme agli altri. Tecnicamente maturavo,
le cosiddette «hard skills» tipiche per un developer miglioravano, ma non cambiavo marcia perché non avevo (ancora) capito qual era la mia vera attitudine. Sì, ero un buon coder, sì mi appassionavo di TDD, BDD e framework Javascript (eh ahimè anche di CSS), ma non era lì che davo
il meglio.

Il momento «eureka» non arrivò grazie all’autocritica a cui mi sottoponevo con ferocia, ma grazie all’intuizione di un collega più esperto, più anziano di me di dieci anni, che un giorno mi apostrofò: «Forse non te ne rendi conto, ma devi stare attento a quello che dici perché hai la capacità di influenzare le persone». Il feedback nel complesso non era lusinghiero: dovevo misurare le parole, perché qualcosa di negativo detto da me pesava molto più di quello che pensassi. Tuttavia, ebbe il merito di scompigliare il castello di considerazioni che mi ero costruito per giustificare le difficoltà a raggiungere i miei obiettivi personali.

Avevo capito una cosa: forse potevo fare la differenza non tanto applicandomi sulla sfera dell’innovazione tecnico-ingegneristica ma concentrandomi sull’aspetto più organizzativo e relazionale. Forse non ero l’ingegnere che pensavo di essere, quello con un solido background informatico, capace di trovare soluzioni robuste a problemi difficili. Forse non ero l’uomo delle cose, ma delle persone e per comprovarlo dovevo uscire dalla mia zona di comfort. Pur avendo dato dei segnali in quel senso a chi era in grado di recepirli, io stesso, caratterialmente introverso e a tratti scostante, faticavo a vedermi come trascinatore di una squadra di ingegneri.

Fu l’unione della nuova consapevolezza e l’illuminazione del mio responsabile a spingermi ad approfondire quelli che avrei poco dopo scoperto essere i precursori delle organizzazioni chiamate agili. Dal 2011 iniziai a studiare metodologie di sviluppo del software all’avanguardia per l’epoca, come Crystal Clear di Cockburn, o a leggere libri di gestione del personale e degli spazi di lavoro come Peopleware di De Marco e Lister. Avevo trovato un nuovo senso al mio percorso di crescita: aiutare a organizzare il lavoro in modo moderno.
Sebbene i miei primi anni da sviluppatore li spesi in quello che a posteriori definii un team degenere formato solo da due persone, non appena ebbi la possibilità di lavorare in una vera squadra composta da tre o quattro ingegneri riuscii ad apprezzare le dinamiche relazionali, l’atmosfera e il senso di appartenenza. Ebbi la fortuna di sperimentare ciò che spesso rimane solo sulla carta in tante realtà aziendali: i successi sono di team, così come lo sono i fallimenti. La consapevolezza di non essere da soli contro il problema tecnico del giorno garantiva un livello di serenità tale da poter trovare le occasioni per mettersi in discussione, per interrogarsi e capire come migliorare il lavoro di tutti i giorni.

L’ambiente protetto, i colleghi dell’epoca e la continua volontà di mettermi alla prova crearono le condizioni ideali per un silenzioso passaggio di ruolo. Nei mesi applicavo il framework agile forse più conosciuto, Scrum, e la scrum-mastership fu il pretesto con il quale iniziai a prendere la guida del team in cui ero inserito. Essere uno dei pochi che avesse approfondito i temi relativi al processo organizzativo aveva un vantaggio: dava al mio responsabile una giustificazione formale per potermi indicare come leader, pur essendo anagraficamente il più giovane membro del team. Nel reparto tecnico la gerarchia era realmente piatta, non c’erano ruoli al di là dei developer, dei PO e dei pochi scrum master. Ero uno di questi ultimi e ne portai l’etichetta quasi considerandola di passaggio, perché l’obiettivo vero, quello che poteva portare alla giusta considerazione da parte degli altri, era diventare un vero leader.

La strada per raggiungere la tappa successiva del mio percorso professionale si fece più ardua. Avevo studiato alcuni libri, avevo sviluppato alcune capacità di coordinamento ed ero riuscito a ricavarmi un titolo che, almeno formalmente, poteva darmi qualche possibilità in più di favorire la crescita della mia squadra. Ciononostante, non mi ero ancora scontrato col problema più grande: le aziende sono composte di persone e le persone sono l’entità in assoluto più difficile da trattare a livello professionale. Proprio la contraddizione fra la posizione che avevo e l’età anagrafica fu il successivo ostacolo da superare: cercare continuamente di mettere d’accordo ingegneri più esperti di me ricordando loro l’importanza della crescita del team mise alla prova pazienza e resistenza. Rifarsi alle cerimonie del framework funzionò almeno come modo di prender tempo: sapevo che avrei dovuto riaffrontare i problemi in retrospettiva, ma avevo modo di consultarmi in anticipo con gli altri scrum master o col mio responsabile per riuscire a capire come gestire le diverse situazioni. Crescere insieme e mostrare i cambiamenti fu cruciale: non dovetti impormi, solo mostrare che i problemi venivano affrontati in modo ragionevole. Essere coerente e integro aiutò, così come la crescita tecnica supportò quella che era ancora una servant leadership fino alla trasformazione in guida a tutto tondo.

La consapevolezza di un agilista

Essere firmatario del manifesto non avrebbe fatto di me un agilista se non avessi dovuto affrontare così presto nella mia carriera le sfide per organizzare meglio il lavoro di squadra. Oggi, dopo quasi un decennio da quando per la prima volta lessi di Agile, posso provare a dare un’interpretazione più autentica al primo valore individuato e codificato da Beck, Cockburn, Cunningham, Fowler, Martin, Sutherland e altri in quel lontano 2001: gli individui e le interazioni sono più importanti dei processi e degli strumenti. Senza voler entrare in discussioni filosofiche, i signori succitati che potrebbero stare nel pantheon ideale di qualunque informatico, pur essendo dei nerd inside (vedere per credere i video di Uncle Bob), si resero conto di quanto fondamentale fosse mettere al centro le persone. Non è un caso che gli anglosassoni chiamino organizations le aziende: gli individui sono la vera essenza, non i macchinari, non gli edifici, non le cose.

In questo ragionamento è utile pensare per sottrazioni: il processo può essere modificato, può essere trasformato, può essere addirittura non applicato se l’obiettivo e le condizioni correnti lo richiedessero; gli strumenti potrebbero essere inefficaci, deboli o inappropriati tanto da dover essere rimossi. Con un processo approssimativo e strumenti non adeguati ma una squadra coesa si può ancora arrivare a ottenere risultati decorosi. Provate invece a prendere delle persone, chiuderle nello stesso ufficio e chieder loro di non interagire o di farlo in modo formale: se vi andasse bene si accorderebbero pur morendo di burocrazia; se vi andasse male realizzerebbero il prodotto sbagliato.

Quali sono i veri obiettivi degli agilisti? Forse creare un ambiente in cui sia possibile sbagliare senza incorrere in reprimende? Porre le persone nelle migliori condizioni per essere creative? Incoraggiare le stesse persone a identificarsi in team che abbiano obiettivi chiari? Supportare le squadre nella realizzazione di prodotti frutto delle idee e degli sforzi di tutti? No, quelli non sono gli obiettivi ma i prerequisiti per riuscire a rispondere alle sfide di un mondo (non solo un mercato!) in continua evoluzione. A mio parere, lo scrum master di oggi ha uno scopo più alto di risolvere gli impedimenti, facilitare gli eventi, aiutare il PO a scrivere item del backlog che rispettino lo schema INVEST e contribuire al miglioramento della squadra. Lo scrum master, se legge bene la guida al framework, ha il compito di diffondere Scrum all’interno dell’azienda. Per estensione, dovrebbe essere colei o colui che per primo instilla, esprime, spiega, attua e rinforza i principi dell’agilità allo scopo di guidare le organizzazioni al cambio di mentalità necessario per riuscire a sopravvivere in una realtà sempre più competitiva e globale. Per arrivarci è necessario chiamare le cose col loro nome: l’agilità non è un metodo, non è un framework, non è una serie di ricette di facile applicazione. È un paradigma culturale in cui le persone sono al centro, con tutta la loro complessità.

Giovanni Melis

Giovanni Melis

Website

Computer Science Teacher, Agile Professional, Scrum Master, Team Leader, Software Engineer. I work with people

This author does not have any more posts.