#IAD22 Brescia – Italian Agile Days di nuovo in presenza!

In questo mio articolo vi fornirò i resoconti del keynote e di alcune tra le tante sessioni proposte durante la conferenza di sabato 15 ottobre.

Keynote “Myth busting in Agile Scaling”

IAD22 non poteva iniziare meglio con il keynote curato da Nigel Thurlow, attualmente CEO al The Flow Consortium e precedentemente Chief of Agile presso Toyota. Proprio in Toyota Nigel ha definito il modello “Scrum the Toyota Way” e ha partecipato alla definizione del “Flow System™“, un approccio olistico basato su FLOW per fornire valore al cliente, costruito sulle fondamenta del Toyota Production System.

Durante il suo intervento Nigel ha parlato dell’importanza delle metriche Lean: Takt Time, Process Time, Cycle Time, Lead Time e Customer Lead Time, fondamentali in un percorso d’innovazione. Queste metriche sono uno degli aspetti che caratterizzano la cultura del Lean Thinking in cui il tema centrale è “andare direttamente al punto”, ovvero avere la consapevolezza su come stiano davvero le cose. Cosa vuol dire concretamente? Anziché perdersi in considerazioni astratte chiusi in un ufficio è molto meglio recarsi sul posto per vedere cosa succede realmente. Nigel si riferisce a ciò che i giapponesi chiamano Gemba, ossia “the real place“, il luogo dove il valore viene creato. In merito al valore, Nigel ha spiegato quale dovrebbe essere il “real value stream”, il vero flusso di valore. Sempre dalla lingua giapponese, ha citato l’espressione Genchi Genbutsu:

Actual (Gen) Place (Chi) Actual (Gen) Things (Butsu)

“Actual Place, Actual Things” quindi, che potremmo tradurre così: Andare sulla scena reale (genchi) e confermare gli eventi o le cose reali (gembutsu).

Degno personalmente di nota è stato il racconto finale di Nigel, da una sua esperienza passata in un’azienda produttrice di cibo dove si recò per fare consulenza strategica di processo. Dopo aver trascorso diversi giorni a osservare il lavoro degli operai alle macchine (sistemare pezzi di pannocchie su un rullo), non aveva alcuna idea su come poter migliorare tale attività. Nigel decise quindi di cimentarsi, per un giorno intero, in quello specifico lavoro. Fu per lui un giorno difficilissimo, estenuante fisicamente, dal quale però scaturiscono una serie d’idee quali per esempio decidere di aumentare la pausa, essendo gli operai molto stanchi e concentrati nel loro compito, e di rallentare la velocità del nastro trasportatore. Scelte che portarono a un aumento della produttività.
In chiusura del suo keynote, Nigel ha regalato un bellissimo aneddoto raccontandoci l’incontro con un’operaia che lo ringraziò per quei momenti insieme lavorando davanti al rullo perché questa persona si sentì, per la prima volta, ascoltata e considerata. È stato emozionante per tutti, Nigel compreso, il quale a stento è riuscito a trattenere la commozione.

Durante il keynote è stata realizzata da Birgit Jansen una visual board utilizzando modelli e strumenti proposti da bikablo ®. Quella che vedete nella foto seguente è lo stato della board al termine dell’intervento di Nigel.

Diamo una chance alle codebase legacy?

Nicola Mincuzzi, sviluppatore per eDreams ODIGEO, ha raccontato la sua esperienza sul tema con la codebase legacy. I termini codebase legacy, o codice legacy, significano per la maggior parte degli sviluppatori “codice difficile da cambiare o di ostica comprensione”.
Michael Feathers, autore del libro “Working Effectively with Legacy Code“, dà una definizione di codebase legacy cara a Nicola.

“To me, legacy code is simply code without tests.”

Un altro importante concetto presente nel libro è quello della death spiral, ovvero una serie di compromessi opportunistici che si accumulano silenziosamente nel tempo con effetti negativi. Nel caso di un team che lavora a un prodotto, l’inizio di una death spiral può non essere evidente perché in genere si lavora a pieno ritmo su importanti funzionalità. Quindi, quando la richiesta di nuove funzionalità è elevata, come può capitare nel contesto in cui viviamo e nel quale operiamo, un team prende delle “scorciatoie”. I miglioramenti architetturali e di processo (ovvero il debito tecnico) vengono messi in pausa per arrivare prima sul mercato. Nicola, dalla sua esperienza, ci dice…”Immaginate di essere sotto stress, si sviluppa il codice dei test in fretta, e quindi anche il software, la qualità peggiora, la frustrazione cresce e si continua così…”

Come uscire da questa situazione?

Inizialmente Nicola con il team hanno pensato d’introdurre i test automatici con l’idea che potessero soddisfare i loro bisogni: fare affidamento sul feedback, poter estendere il comportamento del software in sicurezza e migliorare la complessità del software.
Come affrontare il mostro (ovvero il codice dell’applicazione, all’epoca il classico monolite software)?
Il gruppo ha lavorato in modalità “edit and pray“. Come funziona? Dopo aver pianificato le modifiche da apportare ed essere sicuri di aver compreso il codice, si effettuano le modifiche, si provano in un ambiente locale (un pc dedicato per esempio), e se tutto fila liscio si rilascia in produzione, attendendo i feedback del cliente. Citando il libro di Rick Page “Hope Is Not a Strategy“, questo processo non poteva funzionare, inoltre si aveva ancora un problema con i feedback.
Nuovo cambio di rotta quindi, si è passati al modello “cover and modify“. Con questo approccio Nicola con il team hanno introdotto i test end-to-end, i testi d’integrazione, e un team di Quality Assurance dedicato alla scrittura ed esecuzione dei test. Il feedback c’era, ma permanevano alcuni dubbi: i test non davano sufficienti informazioni sulla qualità del codice, inoltre non venivano eseguiti durante la fase d’implementazione dal team degli sviluppatori. Oltretutto risultava complesso determinare dove fosse l’errore. Bisognava ottenere feedback più immediati. Come fare?
Introduzione degli Unit Test, o test unitari. Nicola e il team hanno cambiato ancora approccio: individuare il “change point”, rompere le eventuali dipendenze, scrivere gli unit test, farli fallire, implementare le modifiche, eseguire gli unit test e farli passare. In tre parole, Test-Driven Development, o TDD.

Riprendendo una citazione di Kent Beck

“Test-Driven Development is a way of managing fear during programming.“

Nicola ci ha ricordato l’importanza della Piramide del Test in cui non i primi test da considerare sono quelli unitari, seguiti da quelli d’integrazione e infine i test end-to-end.

I corpi in affitto: come rimuovere le aberrazioni del “body rental” – the agile way.

Alessandro Giardina, Agile Delivery Manager per Intré nonché membro storico di Italian Agile Movement, ha portato a questo IAD22 un tema ben noto nel mondo del lavoro: il body rental.
Per entrare nella discussione, Alessandro ha fatto un excursus sulla terminologia e ha chiesto alla platea di descrivere, magari con una parola, il significato di body rental. La seguente immagine riassume i pensieri dei presenti sull’argomento.

Ovviamente esistono non solo i contro del body rental, ma anche i pro. La seguente tabella mostra i risultati di un sondaggio svolto da Alessandro coinvolgendo sviluppatori, venditori e acquirenti di corpi.

Secondo Alessandro, gran parte delle aziende non sono in grado di capire la complessità e l'”artigianalità” dello sviluppo software, e spesso una conseguenza è che il reparto IT venga visto come un costo e che, come tale, deve essere minimizzato. La qualità non viene presa in considerazione, non viene compresa. Ma l’IT non è un costo! È una parte fondamentale, spesso prevalente, dei loro prodotti e servizi.

Come poterne uscire, al fine di tenere i pro e superare i contro?

Alessandro ha parlato di noi portando all’attenzione il modello Intré, una Learning Organization che pone al centro l’apprendimento e la crescita professionale del team. A tal proposito vi invito a leggere l’articolo di approfondimento, oppure potete vedere e ascoltare Alessandro parlare dell’argomento durante un webinar #StopCoding organizzato da 20tab S.r.l..

Lighting talk pomeridiani

La paura della luce e dei mostri che essa attira

Stefano Muro, dalla sua esperienza di Agile coach, ha raccontato una storia, a sfondo fantasy, usandola come metafora per regalarci qualche consiglio utile sul processo di realizzazione di un prodotto. In questa storia i protagonisti siamo noi, dei viaggiatori in missione verso una miniera alla ricerca di pietre di valore. Il management (che Stefano identifica nelle figure dei veggenti) ci fornisce tutti i mezzi necessari per la missione. Per sapere dove andare è necessario avere una luce (ovvero il feedback sulle attività che facciamo) che ci illumini la strada così da orientarci e sapere se stiamo seguendo la direzione giusta. A volte però preferiamo camminare al buio per la paura che la luce attragga delle creature mostruose che sono a caccia. Stefano si riferisce alle nostre esitazioni.
Quali sono questi mostri?
La succuba della luce, che appare quando rischiamo d’innamorarci della luce, di diventarne appunto schiavi. Dashboard, post-it colorati…tanti, troppi strumenti che tendiamo a usare e dei quali ci innamoriamo appunto, e che quindi continuiamo a utilizzare senza curarci della loro effettiva utilità.
Il troll, il mangia uomini. Pensiamo a un progetto di lunga durata, fatto di milestone da raggiungere. Ci impegniamo e lavoriamo, fino a quando il budget finisce, e con esso le persone dedicate al progetto.
Il dissennatore, colui che crea persone senz’anima. Stefano si riferisce a tutti i componenti di un team, di un progetto, che semplicemente fanno ciò che viene detto loro, senza mai interrogarsi sul perché e su come migliorare.
Il cenobita, ovvero la creatura che accompagna all'”Inferno”. Stefano si riferisce ai casi in cui ha notato che un progetto fallimentare ha portato con sé nel “baratro” persone realmente di valore.
Che consigli potremmo mettere in pratica per evitare questi mostri?
In un progetto, sarebbe opportuno dotarsi di metriche (e quindi di feedback) che:

• siano chiare e condivise a tutti;
• dicano cosa è effettivamente accaduto;
• siano frutto di un’ispezione collettiva.

E i veggenti? Devono supportare le decisioni, e non semplicemente fornire gli strumenti.

Agile Coach vs. Scrum Master. Un percorso fatto di one-to-one

Danilo Trapanese ha spiegato portato la sua esperienza in merito alla sua attività di coaching Agile.
Siamo tutti in grado di fare sessioni one-to-one? Dipende. Per Danilo il primo e fondamentale ingrediente è il coraggio. Coraggio di buttarsi, andare oltre le proprie paure e insicurezze. Va bene studiare, prepararsi, magari redigere una roadmap degli incontri (proprio come fece Danilo per la sua prima sessione di coaching). Funzionò? No, Danilo si rese conto che mancava qualcosa, semplicemente non domandava alla persona quali fossero le sue esigenze. “Sei sicuro di voler fare un percorso di coaching?” “Cosa ti aspetti?” “Sai che cos’è un percorso one-to-one?“. Queste semplici domande hanno aiutato Danilo, e lo aiutano tutt’oggi, a settare un percorso di coaching più efficace possibile, perché è un viaggio che si fa in due, insieme all’altra persona, che è opportuno conoscere e coinvolgere fin da subito, anzi prima che tale percorso inizi.
Che temi sarebbe meglio affrontare in un percorso one-to-one?

• Comprendere i bisogni di un team Agile.
• Mantenere il team focalizzato sulla missione e sul processo.
• Facilitazione di eventi previsti dal framework utilizzato.
• …

Quali risultati si possono raggiungere? Per Danilo non esistono limiti, e dipende molto dal proprio carattere e dalla persona con il quale si dovrà lavorare.

Agile, il Super Mushroom che ti fa giocare a un nuovo livello

Francesco Fregni e Michela Rapaccioli, rispettivamente Project Delivery Manager e Project Manager presso Credem Banca, hanno portato che cosa vuol dire introdurre il mondo Agile nel Core Team dell’Antiriciclaggio.
Le banche sono organizzazioni complesse e la conduzione di progetti pervasivi e massimizzanti come quelli richiesti dalla normativa Antiriciclaggio è un susseguirsi d’infiniti livelli da superare. Francesco e Michela lavoravano con regole “waterfall” a superare i nuovi livelli che ogni anno gli enti regolatori aggiungevano al gioco che li ha spinti, a un certo punto, a sperimentare l’Agile. Avvalendosi della consulenza di un Agile Coach, dapprima la teoria Agile è apparsa come la promessa di un pusher assuefatto agli allucinogeni. La sfida non era solo sul piano metodologico ma anche su quello pratico, organizzativo e relazionale.
Francesco e Michela, insieme con tutte le persone coinvolte nel progetto, hanno deciso di dare il primo morso al fungo dell’agilità e i risultati sono arrivati! Ne riporto alcuni.

• Team dedicato sul progetto. Ogni persona è allocata al 50% al progetto.
• Alcune delle imponenti barriere comunicative tra le divisioni in azienda sono state abbattute.
• Si svolge formazione in contemporanea sia per il team, sia per il coaching.
• Esiste un linguaggio comune a tutte le entità coinvolte nel progetto.

Dal carbone al software: i sistemi socio-tecnici

Ferdinando Santacroce, Agile Technical Coach e Team Coach per Agile Reloaded, ha parlato delle origini di una teoria molto interessante, quella dei sistemi socio-tecnici. È doveroso tornare indietro nel tempo, esattamente nel 1951 quando Eric Trist e Ken Bamforth pubblicarono il loro studio intitolato “SOME SOCIAL AND PSYCHOLOGICAL CONSEQUENCES OF THE LOGWALL METHOD OF COAL GETTING” a seguito di un loro viaggio in Gran Bretagna, durante il quale notarono delle difficoltà da parte dei responsabili della modernizzazione produttiva delle miniere di carbone. La ricerca paragonava due tipi differenti di organizzazione lavorativa. In particolare, i ricercatori del Tavistock Institute confrontarono il metodo tradizionale di lavoro, cosiddetto “shortwall”, e il nuovo metodo “longwall“, tecnologicamente avanzato, che avrebbe dovuto portare a un aumento della produzione giornaliera.

Metodo tradizionale

Gli operai venivano divisi in piccole squadre che si occupavano di tutte le fasi di produzione: preparazione, estrazione e trasporto. C’era carbone pronto per la consegna ogni otto ore perché i minatori lavoravano a coppie alle quali si aggiungevano al massimo una o due persone (i “trammers”, ragazzi deputati al trasporto), sino a un massimo di otto. C’era controllo totale del ciclo di estrazione, la leadership e la supervisione erano interne al gruppo, inoltre erano i minatori stessi a negoziare il compenso per il carbone estratto direttamente con il gestore della miniera. Ciò rendeva i lavoratori orgogliosi della propria arte, ogni coppia aveva tutte le competenze necessarie e la scelta dei membri era reciproca: le coppie e i gruppi si formavano su base autonoma. In molti casi c’era rapporto di parentela (fratelli, padre-figlio), e spesso le coppie rimanevano stabili per anni. Non era raro per un minatore prendersi cura della famiglia del compare nel caso fosse rimasto gravemente ferito o ucciso. Il lavoro in piccoli gruppi consentiva alle persone di coltivare rapporti personali, di sostenersi a vicenda in condizioni avverse. La flessibilità di questi piccoli gruppi aveva dei vantaggi: nel muoversi da un filone all’altro, nell’affrontare condizioni avverse (per esempio una pietra più dura da scavare, imprevisti vari) e nel settare gli obiettivi di estrazione tenendo conto della situazione, dell’età e della salute dei suoi membri.

Metodo longwall

Questo metodo, che aveva preso piede a seguito della “meccanicizzazione” delle tecniche di estrazione, permetteva – a parità di condizioni tecniche – di riprodurre nelle miniere i modelli di coordinamento e di direzione in uso nell’organizzazione industriale del lavoro alla catena di montaggio. Ogni minatore eseguiva un unico compito, in un’unica postazione in parete lunga, senza alcuna opportunità di rotazione nel lavoro. Il longwall permetteva fronti di estrazione lunghi fino a 200 yard (circa 180 metri). La conformazione della miniera (e la volontà dei minatori) non permettevano filoni così lunghi.
La tecnologia era stata innestata nel processo. La maggiore efficacia della macchina e l’automazione nell’estrazione aveva aumentato i volumi, nonostante ci fossero nuovi costi (in termini di tempo) da pagare per l’allestimento. L’approccio era rimasto pressoché uguale al precedente, quando la raccolta del carbone era fatta “a mano”. Ma…

• Il longwall rompeva l’efficacia dei piccoli gruppi.
• L’autonomia era sparita, la responsabilità dell’intero ciclo era stata spezzata.
• Erano nati numerosi nuovi ruoli, con mansioni distinte, spesso sbilanciate.
• Le condizioni avverse, sempre in agguato in miniera, avevano impatti devastanti su alcuni, lievi su altri.
• I lavoratori erano distanti l’uno dall’altro, senza occasione di socializzazione.
• Era cambiata la tecnologia, ma non era stato fatto niente a livello sociale per consentire il necessario adeguamento.
• L’interdipendenza dei task dava adito a frequenti situazioni di frustrazione.
• Era sempre più difficile distinguere il “cattivo lavoro” dalle “cattive condizioni”.
• C’era paura, incertezza.
• I manager erano messi a risolvere problemi che non potevano vedere e i minatori si lamentavano parimenti.
• Era impossibile costruire rapporti duraturi in gruppi così grandi e con così poche occasioni di cooperare.

Ricapitolando, passando dal metodo shortwall a quello longwall andarono perduti:

• cross functional team;
• visione end-to-end;
• autonomia;
• fiducia reciproca.

E si erano “guadagnati“:

• dipendenze;
• controllo serrato;
• iper-specializzazione;
• paura, frustrazione.

Tornando nel 2022…ciò che venne redatto nel 1951 non ci suona terribilmente attuale nelle dinamiche lavorative quotidiane? Continuiamo a ripetere gli stessi errori, nonostante negli anni sono state proposte diverse valide soluzioni. Ferdinando ne ricorda qualcuna.

• Taiichi Ohno, tra i pionieri del modello Lean.
• Le pratiche dell’Extreme Programming.
• Context Map Cheat Sheet.
• …

Le pratiche tecniche e le dinamiche sociali sono interdipendenti e ugualmente importanti! La tecnica sì influenza la società, ma è vero ed è da tenere in enorme considerazione anche il contrario. Il segreto è riassumibile nel seguente concetto: Joint Optimization.

In conclusione, Ferdinando ci ha condiviso i suoi take-away dallo studio sui sistemi socio-tecnici.

• Come organizzazione, non posso cambiare un sistema ignorando l’altro.
• Come manager, devo comprendere le questioni tecniche, creando le condizioni perché possano fluire rapidamente.
• Come sviluppatore, posso lavorare sulla tecnica per promuovere l’organizzazione. Posso lavorare sulle skill, senza però ignorare le capacità relazionali: essere bravi con le macchine non basta.
• Come agente di cambiamento: mantenere l’umiltà, perseguire l’eccellenza attraverso la conoscenza (Gemba insegna).

Conclusioni

Che posso dire di questi IAD22? Per me è stata un’edizione speciale, per due motivi.

• Gli Italian Agile Days del 14 e 15 ottobre 2022 hanno rappresentato un “anno zero”: è stato davvero entusiasmante incontrare nuovamente di persona colleghi, ex colleghi e amici dopo tanto tempo.
• Avere contribuito alla realizzazione dell’evento, nel gruppo Comunicazione dell’Italian Agile Movement (IAM), è stata personalmente una bellissima esperienza. Ho potuto apprezzare ancora di più l’impegno e la passione che spinge il gruppo di volontari IAM a organizzare, anno dopo anno, un’edizione di IAD che sia migliore di quella precedente.

Un enorme grazie va a Intré, che annualmente rinnova il proprio impegno nella sponsorizzazione dell’evento, a tutti gli altri sponsor, agli speaker, all’Università di Brescia – Facoltà d’Ingegneria -, al CSMT – Centro Servizi Multisettoriale e Tecnologico, e a tutte le persone coinvolte nell’organizzazione. Menzione speciale per i ragazzi dell’istituto d’istruzione superiore “Andrea Mantegna” i quali si sono impegnati per farci gustare delle ottime pause caffè, la merenda e il lunch box comprensivo di un primo, un secondo, un dolce, succo di arancia e acqua.

Arrivederci alla XX esima edizione, arrivederci a #IAD23!