Metodologia Agile: intervista a Roberto Lo Giacco (RCI Bank)

Per capire un po’ in cosa consiste la metodologia Agile, abbiamo intervistato Roberto Lo GiaccoTechnology Innovation Specialist presso RCI Bank and Services Italia. 

Roberto è una persona attenta e curiosa, pronta a condividere e mettersi in discussione. Esploriamo insieme a lui i principi di questa metodologia che, partita in ambito informatico, è ora adattata e utilizzata un po’ in tutti i campi.

Raccontaci un po’ di te: chi sei, cosa ti appassiona, che lavori svolgi

Mi ritengo una persona curiosa e, in quanto tale, tendo ad appassionarmi a tutto ciò che ritengo nuovo ed interessante.

Da qualche anno mi sono appassionato all’elettronica ed alla programmazione di microcontrollori, come il famoso Arduino, ma non solo.

Sono da sempre uno strenuo sostenitore della filosofia Open Source: condividere le proprie esperienze, in contrapposizione al tenerle riservate.

Questo mi ha condotto a contribuire a numerosi progetti open source, alcuni anche abbastanza famosi nel settore informatico, e questo mi ha consentito di ottenere delle opportunità di lavoro ed un riconoscimento che non avrei mai potuto ottenere altrimenti.

Sul fronte lavorativo mi ritengo un architetto software con la propensione al cambiamento, che in qualche modo si riflette sul mio titolo qui in azienda (RCI) che è Technology Innovation Specialist: probabilmente gli oltre venti anni trascorsi programmando in Java e studiando soluzioni software avranno inciso un pochino.

Sotto il profilo professionale sono un forte sostenitore dei concetti di “Prodotto adeguato alle necessità” e di “Manutenzione sostenibile del software“.

Cosa vuol dire lavorare AGILE e in cosa consiste la metodologia Agile?

Consentimi di fare una precisazione: non ha molto senso parlare di “lavorare agile” o di “metodologia agile” perché in realtà dovremmo parlare del “Manifesto Agile” e dei “Principi del Manifesto Agile“, conseguentemente di “Metodologie che realizzano i principi del manifesto agile“, ma comprendo anche la semplificazione verbale, anche se porta a confusione.

Diciamo che ciò che normalmente viene percepito rispetto alle metodologie agili è fondamentalmente errato e conseguenza di una “campagna di marketing” poco lungimirante. Troppo spesso “Agile” viene percepito come “essere flessibili, fare di più in meno tempo e ad un prezzo inferiore” e non deve stupirci come questo conduca ad una adozione di tali metodologie seguita, poco dopo, da un allontanamento.

In realtà, lavorare in maniera agile significa lavorare secondo i 4 semplici principi enunciati all’interno del manifesto agile:

  • persone e relazioni sono più importanti di strumenti e processi
  • un prodotto funzionante è preferibile ad una documentazione completa ed esaustiva
  • la collaborazione con l’utilizzatore è più rilevante dell’aderire al contratto di progetto
  • adeguarsi al cambiamento è più importante che aderire al piano prestabilito
  • Sono quattro concetti semplici che possono anche risultare banali ed ovvi, ma che tali non sono.

Esistono  due principali approcci, o framework, che aiutano ad aderire a questi principi pur mantenendo la consistenza e strutturazione necessarie all’interno di un processo di lavoro aziendale: Scrum e Kanban.

Mi ritengo un decente conoscitore ed un forte sostenitore del primo, mentre sono un principiante alle prime armi del secondo, che sto ancora cercando di approfondire.

Tu lavori agile? E il tuo gruppo?

Comincio col dire che trovo difficile pensare di lavorare secondo una metodologia aderente al manifesto agile al di fuori di un gruppo. Nella mia posizione precedente come Senior Digital Specialist , cioè nei passati cinque anni, ho fatto parte di un team Scrum che ho l’orgoglio di aver contribuito a formare e che ritengo abbia anche ottenuto degli ottimi risultati. Da qualche mese mi è stato chiesto di svolgere una mansione differente: portare almeno una parte di quell’esperienza all’interno di altri gruppi di lavoro. Si tratta di una sfida che , in tutta onestà, non potevo rifiutare.

Metodologia Agile To do list
Foto di Gerd Altmann da Pixabay

Cosa vuol dire essere Scrum Master?

Lo Scrum Master è uno di quei ruoli controversi che spesso vengono fraintesi. Molti considerano lo Scrum Master una specie di Project Manager, qualcuno che guida e controlla il team di sviluppo, ma questo non potrebbe essere più falso. Facciamo un passo indietro: stiamo parlando di una metodologia di lavoro (Scrum) che realizza i principi dettati nel manifesto agile e che si basa, sostanzialmente sul concetto di un gruppo di lavoro autonomo ed auto-organizzante. In due parole, un project manager, qualcuno cioè che detta i tempi e tiene traccia degli avanzamenti, è un ruolo inesistente in un team scrum: queste attività sono demandate a tutti i membri del team che sono liberi di organizzarsi come meglio ritengono opportuno per raggiungere il risultato desiderato.

Il vero ruolo dello Scrum Master è quello di aiutare il team ad operare all’interno delle strutture e delle regole dettate dalla metodologia Scrum, risolvendo, là dove necessario, i contrasti e le frizioni verso il mondo esterno e garantendo al team di sviluppo la necessaria indipendenza. Si tratta di un ruolo che richiede la capacità di dire “No” e di individuare soluzioni pratiche a problemi pratici. Faccio alcuni esempi:

  • assicurarsi che il team faccia la riunione quotidiana sempre alla stessa ora e che tutti partecipino e restino all’interno dei tempi prestabiliti
  • assicurarsi che tutti i membri del team abbiano la possibilità di esprimere la propria opinione, livellando le inevitabili propensioni caratteriali
  • proporre al team modi per dirimere dubbi, del tipo “quanto cuba questa attività?”
  • assicurarsi che solo una persona, il Product Owner, possa dare indicazioni al team di sviluppo sul prodotto da realizzare, evitando che i membri vengano “tirati per la giacchetta”
  • prenotare sale ed avere gli strumenti necessari alle attività quotidiane
  • suggerire strade alternative per risolvere empasse
  • promuovere all’interno dell’azienda i successi ed i fallimenti del team in modo da coinvolgere il resto delle persone e tenerle informate

Si tratta di un ruolo di mentore che deve essere svolto tentando di non influenzare troppo il team con le proprie convinzioni piuttosto che il ruolo di direttore d’orchestra: le decisioni devono essere tutte prese dai membri del team con il massimo livello di accordo possibile, mai imposte.

Quali sono le competenze più importanti che lo Scrum Master dovrebbe avere? Quali le doti personali?

Lo Scrum Master deve necessariamente avere una conoscenza profonda del framework Scrum e tale profondità non è certo raggiungibile con un corso di formazione. Non fraintendermi, la formazione è utile, ma bisogna aver vissuto all’interno di un team Scrum per comprenderne le difficoltà ed i meccanismi. Solo dopo aver compreso appieno e condiviso profondamente i principi del manifesto agile credo si sia maturata la competenza per svolgere il ruolo di Scrum Master.

Dal punto di vista caratteriale è fondamentale riuscire a fare un passo indietro e lasciare che le tue esperienze e conoscenze non influenzino il team: bisogna essere capaci di lasciare che un team convinto di una certa scelta che tu non condividi segua il proprio corso. Per me si è trattato di fare un enorme bagno di umiltà perché, lo ammetto, sono presuntuoso.

La figura dello Scrum Master io la interpreto come una via di mezzo fra il bidello di scuola, che viene a ricordarti che il laboratorio è prenotato, e quella del nonno, che ti consiglia ma non ti giudica. E’ un ruolo difficile da interpretare, ma cruciale.

Pensando alla metodologia Agile, di quali strumenti non potresti fare più a meno?

Ad essere sincero credo che l’unico strumento che ritengo indispensabile per l’implementazione di una metodologia conforme all’agile manifesto sono carta e penna a cui aggiungerei una lavagna. Vedi, non si tratta di quali strumenti informatici utilizzi, proprio secondo i principi del manifesto. Certo, ci sono alcuni strumenti informatici che ben si adattano alla metodologia Scrum, ad esempio JIRA ha una buona estensione per Scrum, ma ci sono strumenti gratuiti che la implementano altrettanto bene (Trello, per menzionarne uno).

Se mi consenti, direi che ci sono delle classi di strumenti a cui non riuscirei più a prescindere, indipendentemente da quale sia il prodotto specifico: un sistema per il tracciamento degli sprint e dei task, uno per l’esecuzione automatica delle build e dei deploy (continuous integration), uno per il tracciamento del debito tecnologico, un wiki (inteso come web collaborativo) dove raccogliere la documentazione e, senza alcuna ombra di dubbio,  un sistema per la condivisione del codice all’altezza delle necessità del team (source version control).

Quali sono le tre più grandi soddisfazioni legate al tuo ruolo di Scrum Master?

Sicuramente una di queste è vedere il team Spark, che ho avviato verso questa metodologia, proseguire felicemente il proprio percorso in maniera autonoma. Inizialmente è stato difficile trasferire alcuni concetti come farsi carico dei bug o imporsi l’obiettivo di consegnare solo codice esente da difettosità, ma quando gli ingranaggi hanno iniziato a muoversi correttamente ed il team ha iniziato a ricevere riscontri credo che nel team si sia consolidata la cognizione che lavorare bene è possibile e restituisce soddisfazioni ed orgoglio nel proprio lavoro.

Credo che questa sorpassi di gran lunga tutte le altre, quindi preferisco non annebbiarla con altre situazioni.

 

Metodologia agile lavoro di gruppo
Foto di Ron Lach da Pexels

Mi racconti un aneddoto/una storia associato alla metodologia agile?

Di aneddoti negativi, in cui agile è stato male interpretato, purtroppo ne ho fin troppi, ma voglio focalizzarmi su uno positivo perché credo sia molto più rappresentativo.

L’occasione di cui vi voglio parlare si è verificata durante una delle riunioni che il team pratica nell’implementare Scrum denominata Sprint Planning: 

In questa riunione il team di sviluppo, lo scrum master ed il product owner si riuniscono per stabilire cosa verrà realizzato durante la prossima iterazione di sviluppo, detto Sprint. 

Il product owner inizia elencando le User Stories che vorrebbe facessero parte del prossimo rilascio e, fra queste, ve ne è una che lui ha chiamato “Registrazione Utente”. Il team di sviluppo decide immediatamente di iniziare a stimare le attività e, in brevissimo tempo, stabilisce che la storia vale 5 story points. 

Il team sta per passare alla storia successiva quando lo Scrum Master chiede: 

“Non credete di essere stati troppo sbrigativi durante questa stima?”. 

Il team, incredulo, ribadisce che si tratta di un semplice form di registrazione nel quale i dati verranno scritti su una tabella del database etc… Solo a quel punto il product owner risponde:

Veramente i dati devono essere scritti sul sistema di gestione utenti pre-esistente e solo dopo che è stata verificata la compatibilità con l’archivio dei prodotti venduti. Inoltre la procedura di registrazione non può completarsi se non dopo aver fatto il controllo incrociato con l’archivio degli utenti indesiderati e previa conferma dell’indirizzo email”. 

Il team ha impiegato altri 60 minuti ed un lungo dibattito per determinare che la User Story doveva essere divisa in due parti e che il suo valore complessivo era in realtà di 20 story points. 

In quel team io svolgevo il ruolo di sviluppatore, quindi avevo contribuito alla valutazione errata ed ho imparato due cose importanti: 

  • comunicare con il product owner è l’unico modo per sapere cosa realmente serve affinché il software risolva il problema reale 
  • non dare per scontato di sapere cosa si cela dietro una breve frase solo perché l’hai sentita ripetere troppe volte.

Secondo te, nel 2030 quali caratteristiche avranno le metodologie che utilizzeremo nelle aziende?   

Se lo sapessi diventerei sicuramente ricco e famoso, ma se te lo dicessi dovrei ucciderti per evitare la concorrenza 😃.

Sono convinto che la strada sia quella di lavorare di meno per realizzare di più, dove i progetti saranno di integrazione anziché di realizzazione, ma in un contesto dove la parte umana viene esaltata anziché individuata come una limitazione.

Allenatrice di obiettivi. E' convinta che la vita sia una questione di scelte e che la creatività ci salverà.

Cosa stai cercando?