#IAD23 – Venti di IAD a Milano

In questo articolo vi riassumerò alcune sessioni che abbiamo seguito nell’arco della giornata.

Buona lettura.

Suggerimenti per “leader” che guidano e supportano team agili

Questo talk è stato curato da Caterina Palmiotto, Agile coach in Agile Reloaded e Manuele Piastra, Team e Organisational Coach. 

Chi è un leader? Sono leader tutti coloro che riescano a influenzare gli altri con o senza una posizione formale di autorità. I comportamenti dei leader possono avere un impatto negativo e gli speaker hanno descritto fatti di cronaca che hanno portato alla morte di numerose persone, prevenibili con stili di leadership diversi:

1. Il disastro aereo di Tenerife in cui hanno perso la vita 583 persone: il copilota di uno dei due aerei coinvolti aveva perplessità sulla manovra ma non è riuscito a mettere in discussione la decisione del pilota.
2. L’incidente della Nasa del 1986, in cui un ingegnere aveva sollevato timori ma non era stato ascoltato, e quello del 2003, in cui un ingegnere aveva poi ammesso di aver avuto dubbi ma non era riuscito a parlare.

Un disastro dovuto a una leadership problematica è il “Dieselgate“, scandalo emerso nel 2015. La Volkswagen ha ammesso di aver manipolato i test sulle emissioni dei veicoli diesel. L’eccessiva pressione sui risultati finanziari ha incentivato pratiche scorrette, addirittura illegali, per raggiungere gli obiettivi, provocando un importante danno di immagine e di business. 

I leader hanno la possibilità di scegliere consapevolmente i comportamenti da adottare, supportando una cultura di psychological safety e di continuous improvement che porta benefici a tutti gli aspetti aziendali: dall’aumento della produttività, alla riduzione di incidenti fino all’aumento dei salari. Per dimostrarlo, Caterina e Manuele hanno descritto situazioni da loro vissute e le scelte prese dai leader inizialmente. Suggerendo comportamenti alternativi ai leader, e mettendoli in pratica, si è assistito a un miglioramento del contesto lavorativo e dei risultati ottenuti. I comportamenti alternativi utilizzati dai leader possono supportare i team nel creare l’ambiente che li rende più efficaci.

IT e Sostenibilità, un nuovo approccio alla complessità

Francesco Fullone, Business and Sustainability designer nonché presidente del GrUSP, ha continuato il discorso sul tema “Sostenibilità e Software” iniziato a IAD22 con il talk “Green principles, cosa sono e come impattano“.

A che punto siamo oggi? Francesco ha riportato una considerazione, presa dalla home page del sito “Sustainable Web Manifesto“, sulle emissioni di CO2 (personalmente abbastanza allarmante):

“If the Internet was a country, it would be the 4th largest polluter”

Tale frase, tradotta in italiano, dice: “Se Internet fosse una nazione, sarebbe la quarta più inquinante“.

La sostenibilità non è da intendersi solamente a livello ambientale, è infatti qualcosa di molto più complesso da gestire. Nel mondo del software e dell’IT potremmo anzi dovremmo attivarci su quelli che Francesco definisce i tre pilastri della sostenibilità:

• Persone: con azioni a favore dell’accessibilità, usabilità e inclusione che sicuramente impatterebbero il business sugli stakeholder.
• Pianeta: tutte le azioni che avrebbero un impatto nell’ambiente: e-waste, o electronic waste, e tutto ciò che concerne il consumo energetico (in azienda e non solo).
• Profitto: le azioni da intraprendere per gestire e magari evitare il debito tecnico, i problemi legati alla sicurezza informatica (cybersecurity), la resilienza dell’infrastruttura.

Ambiente

Parlando di impatto ambientale, Francesco ha ricordato alcuni dati (ovviamente non esatti) che dovrebbero far suonare più di un campanello d’allarme.

• Il 3,3% dei gas GHG (“Greenhouse Gas” o più comunemente gas a effetto serra, compresa la CO2) sono emessi dalla filiera dell’IT, ed è un dato in aumento (si stima che si arriverà al 5% nel 2025).
• L’invio di una e-mail produce 17 grammi di CO2, a oggi inviamo circa 275 miliardi di e-mail al giorno.
• Tornando all’e-waste, in Europa si contato 700 milioni di telefoni cellulari inutilizzati, praticamente due per ogni cittadino europeo, e solamente il 5% viene riciclato. Tenete conto che per ogni dispositivo elettronico sono fondamentali le cosiddette terre rare, ovvero elementi chimici che si trovano in alcune miniere, e a oggi la Cina è il Paese che ne possiede di più… c’è e ci sarà sempre più richiesta, e ciò inevitabilmente si tradurrà in maggiori attività di scavo ed estrazione.
• L’avvento dell’Intelligenza Artificiale ha anch’esso un impatto negativo. L’utilizzo di Google Bard è più inquinante di una ricerca classica eseguita nel sito google.com.

Ci sono altri aspetti della sostenibilità che vanno presi in considerazione: sociale e di governance.

Sostenibilità a livello sociale

Ogni volta che sentiamo o utilizziamo il termine stakeholder in un progetto, dobbiamo sapere che stiamo parlando di persone. La sostenibilità in questo senso implica un uso responsabile delle risorse per il benessere a lungo termine. Francesco ci ha parlato delle pratiche D.E.I. (Diversity, Equity, Inclusion) ovvero Diversità, Equità e Inclusione. Insieme, promuovono una società armoniosa e resiliente che rispetta i limiti del pianeta, valorizza le diverse prospettive e garantisce un accesso equo alle risorse e alle opportunità per tutti.

Sostenibilità a livello di governance

Sostenibilità e governance sono strettamente collegate, in quanto le pratiche di governance efficaci svolgono un ruolo fondamentale nel perseguire gli obiettivi di sostenibilità. Una governance trasparente e responsabile assicura un processo decisionale responsabile, quadri normativi e pratiche aziendali che danno priorità a considerazioni ambientali e sociali. Integrando la sostenibilità nelle strutture di governance, le organizzazioni e le società possono impegnarsi collettivamente per un futuro equo e resiliente.
Tornando al nostro mondo dell’IT, governance per Francesco è soprattutto “continuous risk assessment“, ovvero una valutazione continua dei rischi tecnici:

• Cybersecurity risk: rischi legati al “B.Y.O.D.” (Bring Your Own Device, e tutto ciò che ne consegue quando utilizzi un tuo dispositivo), al “GDPR”, la gestione dei dati, e un cenno al Cyber Resilience Act, un documento che dovrebbe contenere delle linee guida per dispostivi e software in Europa.
• Knowledge risk: il valore viene generato dalle persone e dalle loro competenze. In questa casistica rientrano i rischi legati al know-how dell’individuo (“Cosa succede all’azienda ogni volta che la persona va via e porta con sé conoscenza?“). Stesso discorso per la mancanza di documentazione, tanto tra le righe di codice quanto nel prodotto.
• Obsolescence risk: i rischi legati al mantenimento sia hardware che software. Per esempio, se nel progetto si usano librerie di terze parti, bisogna controllare che siano mantenute o non più supportate.

L’arte di mettere in fila tante cose. Un approccio realistico al portafoglio strategico

Stefano Leli, Agile coach, nel suo talk ha raccontato l’approccio “Agile Portfolio Management” di Agile Reloaded.

Tutti hanno più idee che risorse. Quello che è importante è trovare l’approccio realistico e sostenibile che permette di dire “Siamo riusciti a fare quello che volevamo”. Per mettere in fila le tante attività, una pratica adottata in tutte le aziende medie o grandi è il “Project Portfolio Management“: coordina lo svolgimento di più iniziative nello stesso orizzonte temporale, che coinvolgono diverse aree aziendali, e ha lo scopo di definire obiettivi. Le iniziative raccolte nel portfolio di progetto sono ripartite sull’intero anno, ma allocare l’intero budget inizio anno e senza possibilità di modifica è complesso e comporta limiti.

La variante Agile del “Project Portfolio Management” nasce come soluzione a questi problemi. Il manifesto Agile recita:

“Gli individui e le interazioni più che i processi e gli strumenti”.

L'”Agile Portfolio Management” (APM) è un approccio alla gestione strategica aziendale basato sulla comunicazione e la condivisione tra gli individui, che ha l’obiettivo di selezionare e fare (solo) le cose che servono. I passaggi chiave del modello APM di Agile Reloaded descritti da Stefano sono i seguenti:

1. La condivisione e il censimento delle iniziative utilizzando la Lean Canvas.
2. La prioritizzazione collaborativa delle iniziative con la matrice impatto/effort, stabilendo i driver che ne facilitano la valutazione.
3. La pianificazione delle iniziative.

Tutti gli step comportano l’abilitazione di conversazioni coinvolgendo tutti i livelli aziendali. L’APM funziona su base trimestrale, non annuale. Questo permette di fermarsi, valutare come stanno andando le iniziative e decidere se portarle avanti o spostare il budget su altre, di modificare quindi il piano strategico aziendale in corso d’opera, salvaguardare la capacity e ridurre gli sprechi.

Pratiche per costruire una learning organization

Fabio Ghislandi nel suo talk ha raccontato che cosa vuol dire fare davvero continuous learning portando il modello di learning organization di Intré. 

Il “Manifesto per lo Sviluppo Agile di Software” recita questi passaggi chiave: 

• “La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità” – 9° principio
• “Fondiamo i progetti su individui motivati” – 5° principio
• “Persone e loro interazioni più che principi e strumenti” – 1° valore

Leggendo questi principi e valori delle domande sorgono, come per esempio “Che pratiche metto in atto per aumentare la capacità tecnica fino a sfiorare l’eccellenza?” o “Come motivo le persone?“. Forse però c’è proprio un filo rosso che unisce i tre elementi interazione tra persone, motivazione ed eccellenza tecnica. Questo filo rosso si chiama learning organization o, meglio, continuous learning.

Ma perché dobbiamo costruire un’organizzazione dell’apprendimento? Oltre a quello che il 5° e 9° principio e il 1° valore suggeriscono, un altro spunto di riflessione importante a cui rispondere è: 

“Cosa succede se imparano e se ne vanno?” “Sì, ma cosa succede se non imparano e restano?”

Fabio lavora da dieci anni per attuare e diffondere pratiche di continuous learning, sia in numerose organizzazioni come coach di Agile Reloaded sia in Intré come imprenditore, rischiando sulla sua pelle e per un lungo periodo di tempo. A IAD ha spiegato il modello Intré, che si può definire tale perché 5 aziende si sono esplicitamente ispirate alle attività di apprendimento della nostra software house.
Il payoff di Intré è Learn / Code / Deploy Value, con Learn che occupa la prima posizione, e non solo per caso. Le pratiche di apprendimento che Intré attua sono ben 10:  

1. Gilde
2. Camp
3. Community
4. Skill matrix
5. Certificazioni
6. Academy
7. CoP IWannaBeASpeaker
8. Obiettivi di apprendimento
9. Formazione in aula
10. Corsi di lingua 

In un prossimo articolo del blog Intré, dedicato esclusivamente al talk di Fabio, verrà approfondita ogni singola pratica.
Fabio ha lasciato spunti più o meno impegnativi che si possono attuare nei propri contesti lavorativi, con un disclaimer:

prima di attuare qualsiasi pratica è importante assicurarsi che ci sia la cultura delle persone e che Intré ci ha impiegato otto anni per arrivare a come è ora. 

Come funziona il cervello di un programmatore quando impara e affronta nuovi problemi?

Pietro Roversi, Software Engineer presso Evoluzione Telematica, ci ha accompagnato in un breve viaggio alla scoperta del cervello di ogni programmatore quando scrive e legge codice, dei processi di apprendimento che si scatenano quando si impara un nuovo linguaggio di programmazione e come cercare di applicarli nel lavoro di tutti i giorni.

Non è un problema essere confusi, lo è esserlo per più tempo del dovuto. Il codice scritto è spesso confusionario, ma non tutto il codice lo è allo stesso modo. Pietro ha preso come esempio uno stesso problema (conversione di un numero in binario) risolto in tre diversi linguaggi di programmazione:

1. APL: il codice è fatto di pochi numeri e lettere, è breve ma totalmente incomprensibile. C’è mancanza di conoscenza, non ci sono abbastanza fatti rilevanti nella Long Term Memory (LTM), che Pietro paragona all’hard disk del nostro cervello.
2. Java: il codice è decisamente più comprensibile, ma mancano informazioni. Le informazioni di cui abbiamo bisogno dovrebbero essere salvate nella Short Term Memory (STM) ma, dovendo cercare in più parti, potremmo scordare qualcosa che abbiamo assimilato in passato. Questo tipo di memoria potremmo paragonarla alla RAM del nostro cervello.
3. BASIC: il codice è fatto di tante istruzioni, siamo confusi per mancanza di “potenza di processo”. In casi come questo, quando dobbiamo elaborare molte informazioni, l’onere ricade sulla Working Memory (WM), il processore del nostro cervello.

Perché è difficile capire il codice complesso? A causa del carico cognitivo che si genera durante la lettura:

• Intrinseco: creato dalla complessità intrinseca di un singolo pezzo di codice.
• Estraneo: aggiunto accidentalmente al codice o a causa di lacune del programmatore.
• Pertinente: dovuto alla difficoltà di memorizzare il pensiero in LTM a causa dell’elevato carico cognitivo.

Per ridurre il carico cognitivo Pietro ci ha consigliato alcune tecniche quali: refactoring del codice, sostituzione dei costrutti non familiari e aggiunta dei sinonimi di codice al proprio mazzo di flashcard.

Leggere un testo è così diverso dal leggere il codice? Secondo uno studio, un programmatore spende il 60% a leggere codice, ma non viene allenato a farlo. Altri dati forniti da Pietro: nel primo 30% del tempo speso guardando codice, i programmatori guardano circa il 70% delle righe.
Quali strategie della comprensione del testo potremmo applicare al codice? L’attivazione della conoscenza pregressa, il monitoraggio, determinare l’importanza delle parti, inferire, visualizzare, porre domande, riepilogare.

Pietro ha poi proseguito il suo intervento parlandoci di “bad code”, o code smell, ovvero codice contenente antipattern, codice duplicato, nomi strani… codice che è confusionario sia per gli altri che arriveranno dopo di noi sia per noi stessi. Il code smell costa, tanto in termini di carico cognitivo quanto in tempo impiegato per il refactoring. Ci sono diversi modi per ridurlo o meglio ancora evitarlo, ad esempio scegliere i nomi corretti all’interno del nostro codice.

Concludendo, riporto una citazione dello stesso Pietro:

Fare lo sviluppatore è una vocazione, il carico cognitivo su tutti i livelli è altissimo… o siamo folli o siamo appassionati!

Per approfondimenti, potete consultare le slide dell’intervento a questo link.

Conclusioni

Che dire di questa edizione di Italian Agile Days? Il Politecnico di Milano ha fatto da splendida cornice a IAD23 e devo ammettere che questa conferenza si conferma l’appuntamento più atteso da tutti gli agilisti e in generale dalle persone incuriosite dal mondo del’Agilità. Passano gli anni e IAD migliora (come il buon vino)… ricordo ancora molto bene la mia prima volta a un evento tenuto a Vimercate nel 2017 (al tempo si organizzavano i Mini Italian Agile Days).

A Milano ho rivisto con piacere alcune di quelle persone, altre purtroppo no. Colgo l’occasione per salutare Alessandro Bonometti, meglio noto come Bauno, che purtroppo non è più tra noi. Ricorderò per sempre quella volta che ti conobbi a Vimercate Bauno, proprio a quel Mini IAD, dopo averti ascoltato parlare di DDD con il tuo talk “Fighting the leviatan”… illuminante.

Prima di salutarvi, vorrei ringraziare a tutti i volontari che si sono prodigati per l’ottima riuscita dell’evento, tutti gli sponsor e i colleghi presenti al banchetto Intré sabato 18 novembre.

IAD23 è stato il miglior IAD di sempre? Non lo so, sicuramente è stato avvincente e ispirazionale, vedremo cosa ci porterà IAD24. Nel frattempo vi saluto, con la speranza di poterci rivedere ai prossimi appuntamenti targati Italian Agile Movement.