Venti anni dopo…

Nei giorni di venerdì 8 e sabato 9 novembre, si è tenuta IAD24, la confererenza italiana dedicata all’agilità, giunta alla sua 21ª edizione [1]. Gli Italian Agile Days partirono infatti come singola giornata nel 2004 [2], organizzati dall’Italian Agile Movement,l’associazione no-profit di volontari nata nel 2001 per sostenere la diffusione dei principi e delle pratiche Agile.

La due giorni ha avuto luogo a Firenze presso il Centro Didattico Morgagni dell’Università degli Studi, una location che si è dimostrata molto adatta all’evento favorendo sia le presentazioni nelle aule/auditorium, che le attività di confronto e discussione negli spazi aperti.

Qualche considerazione su formula e svolgimento

La formula ha previsto un primo giorno dedicato alla unconference [3]: il programma dei lavori è stato deciso al mattino con alcuni partecipanti che hanno proposto temi di discussione intorno ai quali si è raccolto l’interesse dei presenti nelle varie sessioni.

Tra i temi che sono emersi più chiaramente, ci sono stati quelli legati ai modelli di leadership e alla loro applicazione all’interno delle organizzazioni e quello inerente all’utilizzo dell’Intelligenza Artificiale nei processi conoscitivi e decisionali delle aziende. Tema che, come vedremo, è tornato anche negli speech più strutturati del giorno dopo.

Il sabato, al contrario, si è svolto con un programma da conferenza classica, con un gran numero di presentazioni già programmate, distribuite su 6 aule/auditorium per 4 fasce orarie al mattino e 4 al pomeriggio: sicuramente un programma ricco ma che, proprio per questo, poteva apparire un po’ dispersivo, con il rischio concreto di dover scegliere fra più presentazioni ugualmente interessanti che si svolgevano in concomitanza.

Al contempo, si poteva star sicuri di trovare ad ogni fascia oraria almeno un intervento a cui partecipare. Anche se inizialmente i tempi sono sembrati apparentemente dilatati, in realtà con il passare delle ore gli interventi si sono dipanati in modo fitto e impegnativo: non nascondiamo che, a fine evento, chi scrive ha sperimentato una sensazione di positiva stanchezza, con la netta impressione di aver passato parecchie ore ad assistere a interventi impegnativi e, in alcuni casi, davvero avvincenti.

Resta sempre, in queste situazioni, il dubbio di essersi persi qualcosa. Ma va detto che sul sito di Italian Agile Days verranno pubblicati nelle prossime settimane i video di tutte le presentazioni, il che consentirà di vedere gli interventi a cui si sarebbe voluto assistere, o di rivedere quelli a cui si è partecipato e che sono risultati particolarmente significativi.

Inutile ricordare che, comunque, il valore di eventi come IAD24 sta non solo nell’ascoltare quanto proposto dagli speaker di turno, ma anche nell’incontro con tanti professionisti del settore e nello scambio informale di idee ed esperienze.

Gli interventi

Chiusa la doverosa introduzione, passiamo a raccontare alcuni degli speech ai quali abbiamo assistito. Pur nella grande varietà di temi affrontati, alcune tendenze sono emerse globalmente. La prima è che lo IAD ha oramai raggiunto un livello di “maturità” dovuto certamente al fatto che si sono superate le venti edizioni, l’agilità è ormai una realtà culturale e professionale e ha perso sia quella connotazione “carbonara” dei primissimi anni, sia quel clima di aspettativa per l’ultima novità o tendenza che ha contraddistinto il decennio passato. Al contrario, molti interventi sono stati all’insegna delle considerazioni retrospettive e delle conseguenti ponderazioni sul senso di quello che si fa concretamente oggi con i principi e le pratiche agili nell’ambito delle più svariate produzioni.

La seconda tendenza ben chiara è che, ormai già da svariati anni, il pubblico di questo evento non è più quello degli early adopters provenienti dal mondo dello sviluppo software, ma ingloba anche figure professionali con caratteri più manageriali che magari hanno conosciuto l’Agile solo in tempi relativamente recenti, e all’interno delle loro aziende. Questo non significa che siano stati assenti interventi e relatori dal profilo spiccatamente tech, ma solo che questo è diventato uno dei vari aspetti del panorama Agile contemporaneo.

Marco di Barba & Ferdinando Santacroce – Il miglior modo di introdurre l’agilità è non parlarne affatto

Un intervento con un approccio — per dirla con parole che piaceranno ai relatori — molto “pane e salame”, ossia semplice ma concreto. Il talk si è incentrato sul racconto di un processo sperimentato nel corso di un anno di lavoro improntato a introdurre l’agilità all’interno di un’azienda.

Il punto di partenza è stato, paradossalmente, di parlare il meno possibile di Agile, partendo dalla considerazione che questa parola assume significati diversi nei diversi contesti, proprio per le conoscenze e le aspettative diversificate di chi la usa.

Il primo passo, quindi, è stato quello di spostare l’attenzione dall’Agile in quanto insieme di principi e pratiche, a quello che concretamente si può fare in azienda con la sua introduzione, per esempio per quel che riguarda la gestione del rischio: arrivare a conclusione nei tempi previsti, non spendere troppi soldi, non spenderli male, non creare prodotti inutili o difettosi.

In tutto questo assume un’importanza cruciale la definizione di un linguaggio comune da usare tra tecnici e business.

I relatori hanno raccontato di come abbiano identificato diversi passi in questo percorso:

• step 0: identificare un Team Facilitator;
• step 1: chiarire ruoli e responsabilità usando una matrice RACI (Responsible, Accountable, Consulted, Informed);
• step 2: avviare un processo di delega usando una delegation board;
• step 3: implementare un metodo di lavoro in cui si capisca e si faccia capire in quale fase si è e in cui si adottano gli “strumenti” di lavoro più adatti.

Un aspetto importante su cui gli speaker hanno insistito è che non bisogna concepire queste “fasi” come modello “a cascata”, strettamente sequenziali.

Ma quali sono stati i risultati? Anzitutto c’è stata una riduzione dei colli di bottiglia e un miglioramento netto dello scambio di informazioni fra le diverse parti coinvolte nelle attività.

Non sono mancate anche delle “criticità” paradossalmente legate proprio agli aspetti positivi del processo in cui il sistema dei team è diventato fondamentale e, con esso, anche una coseguenza maturità dei componenti dei gruppi di lavoro, che devono essere in grado di assumersi autonomamente delle responsabilità. In tal senso, i relatori facevano rilevare come certi processi di adozione dell’Agilità non siano necessariamente destinati ad avere successo se non si danno determinate condizioni: ci vuole tempo, occorre una reale disponibilità a cambiare ma, al tempo stesso, non si può agire in modo distruttivo sulla preesistente cultura aziendale.

Con una bella metafora, la conclusione è stata che non basta scrivere gli ingredienti e la ricetta per ottenere un piatto straordinario, altrimenti tutti quanti saremmo chef stellati. Occorre invece trovare la via più adatta al contesto, con la consapevolezza che si parte da un punto per arrivare a un altro: con ulteriore metafora gastronomica, molto efficace, gli speaker hanno ricordato che non è possibile riottenere l’uva di partenza a partire dalla grappa distillata…

Andrea Provaglio – Unpacking the Manifesto

Al di là delle pratiche, delle diverse metodologie, dei framework e delle diverse tendenze a cui abbiamo assistito in questi due decenni, se c’è un elemento fondante di ciò che chiamiamo “Agile”, questo è proprio il Manifesto [4]. Letto, studiato, riproposto, citato a memoria e così via, questo documento è ben presente a tutti coloro che si occupino, a vario titolo, di “agilità”, a partire dalla sua creazione avvenuta nel febbraio 2001 durante un lungo fine settimana in una località sciistica sulle montagne dello Utah.

Andrea Provaglio propone una riflessione di taglio storiografico — non saprei trovare termine più appropriato — per cercare di definire al meglio le fasi cronologicamente più vicine alla creazione dell’Agile Manifesto, andando a intervistare alcuni dei protagonisti presenti al momento della stesura e anche altre eminenti personalità del mondo Agile che, pur non essendo presenti in quei giorni a sciare in Utah, hanno fin da subito abbracciato e praticato i valori e i principi esposti nel Manifesto, dando un contributo riconosciuto allo sviluppo del movimento agile nelle sue prime fasi.

Provaglio decide di far parlare questi protagonisti, proiettando dei video in cui essi sono intervistati e forniscono la loro visione della questione. Ne emerge un quadro che, per qualcuno potrebbe risultare “deludente”, nel senso che vengono demistificate certe assunzioni a proposito del Manifesto, divenute ormai classiche dopo anni di riproposizione, anche acritica, del documento stesso.

La prima impressione che emerge è che, nella stesura del Manifesto, non c’era alcuna intenzione di creare un “testo sacro” immutabile e definitivo, cui tutti avrebbero dovuto conformarsi, quanto piuttosto il desiderio di fissare in maniera rapida e chiara, una serie di considerazioni condivise fra vari professionisti — certamente di spicco — che nel decennio precedente avevano faticosamente cercato delle vie sensate per superare tutta una serie di problemi evidenziatisi nella cosiddetta ingegneria del software: esponenti di eXtreme Programming, Scrum e Adaptive Software Development cercarono di buttare giù alcuni valori condivisi e dei principi che, nella loro esperienza, erano emersi come linee guida valide. Non c’era, a guardar bene, alcun intento di redigere un documento definitivo, una verità rivelata e immutabile da propugnare al mondo intero.

Come tutti i fenomeni culturali, anche le idee del Manifesto Agile erano figlie del loro tempo e, fa notare Provaglio, è abbastanza ingenuo pensare che dal 2001 ad oggi non sia cambiato nulla, specie in un panorama produttivo che invece ha subito enormi mutamenti.

In tal senso, le interpretazioni di alcuni dei firmatari del documento, o di personaggi importanti della primissima fase del movimento Agile, diventano quindi molto interessanti sia per capire il Manifesto collocato nella sua temperie culturale, sia per rivederlo e aggiornarlo alla realtà contemporanea. E vediamo quindi di capire cosa dicono nei video proiettati alcuni di questi esponenti della prima ora dell’agilità.

James Grenning, uno dei firmatari del Manifesto Agile, fa notare, ironicamente, che quando non c’erano le piattaforme per le videochiamate di gruppo, era necessario ritrovarsi da qualche parte per poter discutere insieme. Un aspetto su cui pone molto l’accento è che il gruppo di autori del Manifesto Agile non si aspettava che poi esso sarebbe diventato così importante, al punto di rappresentare il punto di riferimento per un movimento. Altro aspetto interessante delle sue dichiarazioni riguarda il Planning Poker, la tecnica usata per definire il “peso” delle User Stories quando si decide di prenderle in carico nella fase iniziale di uno Sprint Scrum. Grenning è l’inventore di questa tecnica e, nonostante questo, smise di usarla pochissimi anni dopo. Ma un aspetto molto importante che fa notare è che se un team “pesa” una storia per 1 o 2 punti, vuol dire che capisce il dominio, che sa come gestirlo; se la pesa per 3 punti, ha qualche difficoltà, ma probabilmente ancora riesce a vederla nei suoi contorni. Ma quando si inizia a passare a punteggi superiori (5, 8 o 13 pt, per esempio), si tratta di stime fatte alla cieca: i pesi elevati rappresentano non tanto la complessità della storia, quanto piuttosto il fatto che di essa non si capisce granché e non si riesce a dare un contorno abbastanza definito. Da questo deriva una considerazione generale: nell’Agilità, più che le tecniche o i framework contano il livello di preparazione tecnico e “umano” delle persone coinvolte nel processo. Gruppi di lavoro di alto livello, con buone capacità di comunicazione e alta preparazione tecnica, troveranno la strada per fare le cose bene, al di là della specifica tecnica o metodologia.

Andy Hunt, altro firmatario del Manifesto Agile, pone l’accento sui temi dell’apprendimento e della comunicazione, speficicando che questi concetti vanno oltre la semplice “interazione” fra individui. Questo lo porta a dire che a essere Agile non sono Scrum e Jira, perché non basta adottare questi “strumenti” per dirsi agili. L’agilità è rappresentata dallo studio, dal feedback e dalla consapevolezza. In maniera sensata, poi, fa una critica al capitalismo estrattivo che, afferma, non favorisce affatto la consapevolezza e pertanto non si sposa bene con l’agilità.

Il concetto di comunicazione viene ribadito da Arie van Bennekum, unico europeo presente alla stesura del Manifesto, le cui brevi dichiarazioni videoregistrate puntano molto a ribadire l’importanza di un linguaggio comune e della necessità di capirsi fra personale tecnico e dell’area business, come chiave per la riuscita di un progetto.

Nelle videointerviste proiettate durante lo speech e commentate da Andrea Provaglio, appaiono anche personaggi che non erano presenti alla redazione dell’Agile Manifesto, ma che possono a pieno titolo essere considerati come agilisti della prima ora.

Tra questi, molto particolare è il contributo del canadese JB Rainsberger, che parte a un concetto ben conosciuto a chi abbia studiato musica in modo classico; gli études, gli “studi”. Per un musicista che studi, ad esempio, il pianoforte, esistono numerodi études, spesso ad opera di grandi autori classici, che sono delle composizioni musicali scritte con l’intento di far imparare allo studente determinati aspetti della tecnica pianistica. Sono sicuramente musica, ma il loro scopo non è tanto espressivo, quanto ben centrato sull’apprendimento. JB Rainsberger afferma che dovremmo guardare a certe metodologie, a certi framework usati in Agile, proprio come a degli “studi” di ambito musicale: servono anzitutto ad apprendere, facendo interiorizzare certi concetti, e consentendo di gestire, per esempio, gli aspetti economici del progetto. Ma non dobbiamo pensare che con gli études si esaurisca il panorama musicale; al contrario, la vera musica sta in altre composizioni…

Marcin Floryan, attualmente in Spotify, si concentra sul concetto di organizzazione come sistema che evolve. Ironicamente, fa notare, il nome di tribe, reso tanto celebre dal cosiddetto modello Spotify, non esiste più proprio in Spotify: tutto cambia, e anche l’organizzazione delle aziende, ovviamente. La conclusione è che qualunque organizzazione è solo una ottimizzazione temporanea di un problema, destinata a mutare con l’evoluzione della situazione.

L’ultimo intervento video proposto è quello del britannico Kevlin Henney, conosciuto per i tanti libri su linguaggi di programmazione e sviluppo del software, che si sofferma sulla prima frase del Manifesto: “We are uncovering better ways of developing software…”. Ecco, c’è per l’appunto scritto “stiamo scoprendo” e non “abbiamo scoperto”. Fin dal principio, il Manifesto ha un approccio non definitivo.

Il relatore conclude il suo intervento enucleando cinque “principi” che emergono da queste e da altre videointerviste:

1. L’agilità ha una definizione che evolve
2. L’eccellenza tecnica è obbligatoria
3. L’adattabilità è apprendimento continuo e comunicazione
4. L’agilità è olistica
5. L’organizzazione stessa è frutto dell’agilità

Che dire? Un intervento molto bello, con tanto materiale per pensare, ma sopratutto per rivedere il modo in cui il Manifesto Agile viene declinato nelle operazioni più concrete in azienda e sui progetti.

Stefano Milanesi – Estendi il tuo Kanban downstream, evita l’”effetto Master Chef” e rendi il tuo prodotto migliore

Stefano Milanesi è formatore Scrum e trainer Kanban e nel suo intervento si è concentrato su alcuni aspetti di Kanban, cercando di ampliare l’attenzione dal solo processo al prodotto sviluppato e ad alcune metriche che si possono introdurre proprio con tale ottica.

La prima parte della presentazione è stata una panoramica sugli aspetti fondamentali di Kanban: il concetto di flusso, gli ingorghi che possono interromperne lo scorrimento, la fluidità del flusso come valore potenziale.

Il workflow in Kanban è un continuum dall’inizio alla fine, dove la fine è il momento in cui quel determinato item è concluso e rispetta gli standard di qualità richiesti. Un po’ come accade in Master Chef quando si ordina ai cuochi “Su le mani” e gli chef giudicano la qualità del piatto preparato. Ma in Kanban ci sono tutta una serie di accorgimenti che servono proprio a rendere il flusso quanto più spedito possibile e a far sì che il “piatto” sia preparato in tempi accettabili e con la qualità richiesta, ad esempio il limite WIP (Work In Progress) imposto al numero massimo di attività che si possono svolgere contemporaneamente, lo swarming su item problematici nella corsia per le “emergenze”, le Service Level Expectation e il controllo dell’invecchiamento di un determinato item che resta in sospeso (Working Item Age), e così via. Possiamo misurare il throughput come quantità di item che vengono conclusi in una determinata unità di tempo.

Tutte queste misurazioni ci fanno capire abbastanza chiaramente se il flusso sta scorrendo oppure no.

E però, qui sta il nucleo dell’intervento, tutto questo significa comunque rimanere concentrati sul processo, il che è buono, ma non basta.

Con una metafora piuttosto azzeccata, il relatore sposta il focus sul prodotto. “Pensate”, ci dice “a un’operazione come la depilazione. OK, dobbiamo rimuovere i peli superflui, e questo è un’esigenza chiara. Ma come lo facciamo? Con un rasoio o con una striscia depilatoria? Le cose cambiano tra creare l’uno o l’altro prodotto?”.

In tal senso, vengono proposte una serie di “metriche” inusuali, che però sono molto importanti per valutare se il prodotto che è stato creato risponde realmente alle esigenze e anche per capire in che direzione spingere gli eventuali ulteriori sviluppi dello stesso.

Tra queste metriche viene data molta importanza alla misurazione del valore non realizzato: misurare la soddisfazione del cliente, capire l’utilizzo delle diverse feature all’interno del prodotto, individuare la potenziale quota di mercato non affrontabile. Tutto questo aiuta a capire come spingere il prodotto in direzione futura.

Un’altra categoria di metriche, poi, riguarda non più il prodotto in sé, ma chi lo sviluppa: innovation rate, context switching (molto impattante sulla fluidità del flusso), tempo impiegato nella correzione degli errori, time to market (frequenza di rilascio, lead time, etc.). E a queste va aggiunto il tempo dedicato all’apprendimento, nel quale rientra anche il cruciale tema del feedback.

Tutto questo, nella visione dello speaker, deve portare a una presa di coscienza dei diversi fattori che entrano nel processo e la loro misurazione deve condurre verso una gestione di progetto basata sui fatti: un Evidence Based Management.

Giulio Roggero – Agile, Team Topologies and Platform Engineering from the trenches

Giulio Roggero di Mia Platform [5] propone un talk in inglese, fatto che lì per lì mi sembra quasi fuori luogo. Mi accorgerò però alla fine dell’intervento che sono presenti in aula alcuni partecipanti non italiani, che hanno apprezzato molto questa scelta. Nel corso della presentazione, il relatore riuscirà a garantire una continua interazione con il pubblico proponendo dei quiz a cui si può partecipare inquadrando un codice QR e rispondendo alle domande, pertintenti all’intervento: un modo semplice e divertente per mantenere alta l’attenzione e fissare alcuni concetti basilari.

Alla fine, questa presentazione risulterà molto lineare e fornirà un quadro ovviamente non approfondito ma molto chiaro sulla Platform Engineering in un’ottica che non è affatto solo “ingegneristica”.

Come primo passo, vengono passate in rassegna alcune problematiche tipiche delle aziende che devono scalare verso l’alto le loro attività: finché si lavora in un numero ristretto di team che possono facilmente comunicare tra loro, tutta l’Agilità funziona — o almeno dovrebbe funzionare — senza troppi problemi.

Ma il mercato attuale, e le conseguenti risposte organizzative delle aziende, si portano dietro numerosi problemi quando si deve scalare. Si pensi solo, ad esempio, alle innumerevoli tecnologie che fanno parte della Cloud Native Foundation. Si pensi alle problematiche legate alle differenze tra gli standard tecnologici o relativi alla sicurezza che i diversi team portano nel “calderone” al momento in cui si effettua lo scaling. Tutto questo può portare a conflitti e, anche quando non si arrivi a tanto, gli “attriti” che ne derivano sono comunque un impedimento alla fluidità dei processi.

In questo senso, una piattaforma può rappresentare la soluzione a questi problemi.

La Platform Engineering consente di gestire e monitorare da un unico posto l’intero ciclo di vita di software cloud‑native. Grazie alle funzionalità di una Platform Foundation, vengono messi a disposizione tutti gli strumenti essenziali necessari per la gestione dell’intero ciclo di sviluppo del software, comprendendo ogni fase: diventa possibile costruire nuove applicazioni digitali e package business capabilities (PBC), accelerando i tempi di rilascio. La piattaforma si adatta allo stack tecnologico, alla cultura aziendale, alle persone che ci lavorano.

Ma, e qui sta un tema fondamentale dell’intervento, le piattaforme non sono solo tecnologia: per il loro funzionamento conta molto l’aspetto umano. Se da un lato la piattaforma consente agli sviluppatori di migliorare il modo in cui svolgono il loro lavoro, dall’altro occorre che il modo in cui essi lavorano in team sia quanto di più funzionale e seamless è possibile ottenere. E a questo scopo aiuta sicuramente un modello operativo come Team Topologies, che ottimizza le modalità e i tempi per la comunicazione, riduce il carico cognitivo per le persone che lavorano, riduce gli attriti tra team nel momento dello upscaling.

Chiaramente, anche usando una piattaforma e un modello organizzativo come quello proposto da Team Topologies, i problemi possono sorgere: è comunque sempre necessario che tutti gli elementi, tecnologici e umani, funzionino al meglio, senza trascurare nessun elemento. E c’è sempre da tener presente il difficile equilibrio da mantenere tra innovazione della piattaforma e sua stabilità.

Ma, in un panorama complesso e sempre più veloce come quello in cui viviamo, l’abbinamento di principi e pratice Agile, di una piattaforma tecnologica ben funzionante e di un modello organizzativo come Team Topologies può dare i suoi frutti.

Massimo Azzolini – Design Thinking e Agile: esperienze a confronto

In quest’intevento, Massimo Azzolini di GialloCobalto delinea i principi e le pratiche del Design Thinking, ponendo l’accento sulle similarità e le differenze con approcci più strettamente definiti come agili.

Il Design Thinking è un sistema per fare Service design, cioè per progettare servizi. Il Design Thinking si concentra più sullo spazio dei problemi che su quello delle soluzioni: in quest’ottica, dopo che le varie parti coinvolte si sono allineate, si scelgono le metodologie tra le tante che esistono.

Quando si affronta lo sviluppo del prodotto, ci si pongono svariate domande:

• Chi ci chiede di fare qualcosa?
• Per chi stiamo facendo il lavoro? A risolvere questo quesito ci aiutano metodologia come l’uso di Personas e dei Customer Journeys.
• Cosa è il valore veramente e per chi lo stiamo creando?

Uno dei principi fondamentali del Design Thinking è quello di mettere sempre in connessione i vari “mondi” coinvolti nello sviluppo del prodotto: il designer, l’esperto di dominio e il tecnico lavorano a stretto contatto con scambio di competenze e anche di prospettiva e approccio. Ne nasce un continuous learning, un apprendimento continuo che dovrebbe essere il compito del team innovazione quando presente in azienda.

Il mercato cambia continuamente: occorre un rapido adattamento, in cui gli obiettivi e le necessità di tutti devono sempre essere allineati. E, al tempo stesso, non bisogna dimenticare l’importanza delle misurazioni e delle metriche.

Marco Zamprogno – Che cos’è l’Agile senza l’eccellenza tecnica?

Un talk stringato nelle modalità, ma capace di andare al nocciolo della questione. La risposta alla domanda del titolo è, chiaramente, “Niente”. O “Ben poco” per i più ottimisti. Ma che cosa si intende per eccellenza tecnica? “Le pratiche degli sviluppatori che abilitano la condivisione di nuove funzionalità a un ritmo costante a ogni iterazione e che non danneggiano altre funzionalità”.

Il talk prosegue con una sensata considerazione: a seconda dei diversi contesti e della prospettiva degli interessati, l’agilità viene percepita e compresa in modo molto differente. Si passa poi a elencare una serie di buone pratiche tecniche che consentono all’eccellenza tecnica di dispiegarsi all’interno dei progetti che si basino sullo sviluppo incrementale e il Continuous Deployment.

Il testing ci sonsente di capire che quello che c’è funziona e che quello che c’era prima smette di funzionare.

Il refactoring aiuta a tenere a bada il debito tecnico e a incorporare nuove conoscenze nel codice.

Il pair programming e, in seconda battuta, la code review, garantiscono un codice coerente con la codebase.

Il monitoring permette di indagare gli errori e di avere sempre codice affidabile.

E infine, il linguaggio di dominio aiuta tutte le parti coinvolte a parlare una sola lingua.

Perché, pur rappresentando le pratiche appena citate una indispendabile fonte di eccellenza tecnica, anche in questo ambito resta fondamentale la buona comunicazione.

Giovanni Valli – Rivoluzione AI: il futuro delle organizzazioni intelligenti

Non poteva mancare un talk dedicato a uno dei temi più discussi del momento, l’Intelligenza Artificiale. Si parte con una serie di dati e di eventi che dimostrano come l’Artifical Intelligence abbia ormai raggiunto un discreto livello di maturità e di penetrazione nella quotidianità.

Nel 2023, ChatGPT ha superato il test di empatia, qualcosa di veramente notevole anche se paragonata alla pur enorme rivoluzione digitale avvenuta da ArpaNet al World Wide Web agli smartphone. Ma la rivoluzione dell’Intelligenza Artificiale va oltre: i modelli di AI sembrano volerci dire: “Siamo macchine, ma trattateci come umani”.

Nel 2024, Il premio Nobel per la fisica è andato John J. Hopfield e Geoffrey E. Hinton “per le scoperte e le invenzioni fondamentali che consentono l’apprendimento automatico con reti neurali artificiali”, quasi a voler sottolineare come anche un riconoscimento così importante sia legato all’AI.

Ma siamo quindi al momento in cui l’AI sostituirà le persone reali… be’, non è proprio così. Ci saranno sicuramente lavori sostituiti del tutto dall’Intelligenza Artificiale; ma ci saranno altre professioni che necessiteranno di persone che usano la AI e non saranno sostituite, ma solo impattate: più che la macchina che sostituisce l’essere umano, vedremo l’uomo che usa la AI sostituire ll’uomo senza AI.

Lo vediamo in un’applicazione AI come GitHub Copilot che assiste nella programmazione, come se avessimo accanto un collega in pair programming. Lo vediamo nell’uso di personas create dall’Intelligenza Artificiale. E lo vediamo con il fatto che le immagini create direttamente dall’AI sono inferiori a quelle create da persone che usano la AI fornendo le indicazioni più corrette.

Il tema, quindi, delle persone che usano l’AI è di primo piano e avrà un impatto anche all’interno delle organizzazioni.

L’esperto non è più chi ha le risposte, ma chi sa fare bene le domande e valutare i risultati ottenuti. È una svolta nel ben modello delle competenze T-shaped che assume una forma e un significato diverso.

Si passa da organizzazioni solution–driven a quelle question-based: fare le domande giuste e saper valutare le risposte diventa lacompetenza fondamentale in un’organizzazione in cui la AI entri in maniera significativa.

Chiaramente, in tutto questo, etica e trasparenza diventano elementi cruciali. Un primo criterio da adottare è dichiarare esplicitamente  se si usa o meno l’intelligenza artificiale, un po’ come avviene negli alimenti con certi ingredienti controversi, tipo l’olio di palma.

Ma la portata dell’intelligenza artificiale è tale che non basterà solo questo e sarà fondamentale mandare di pari passo la sua adozione con gli interrogativi etici e lo sguardo rivolto alle conseguenze della sua diffusione. Per esempio, se l’intelligenza artificiale riduce i tempi di lavoro, poi come impiegheremo il tempo libero che avanza? E sarà tempo davvero libero?

Conclusioni

Nel panorama delle conferenze, IAD mantiene il suo ruolo di evento piuttosto neutrale, slegato da un target troppo specifico, ma anzi aperto a un ampio ventaglio di proposte. Resta, tra l’altro, una delle poche conferenze a ingresso gratuito — sebbene ovviamente le donazioni all’associazione siano ben gradite — capace di parlare a un pubblico ampio e variegato.

L’impressione, lo ripetiamo, è di essere ormai lontani dai tempi della scoperta, della novità, della curiosità per il “grande nome” presente all’evento. Venti anni di IAD hanno fatto assumere a questa conferenza un tono di maturità: ma è quello che è successo all’agilità, passata da essere considerata inizialmente una bizzarria a risultare oggi pienamente inserito nelle realtà aziendali e organizzative che un tempo la guardavano con diffidenza.

Riferimenti

[1] Il sito dell’evento
https://www.agileday.it

[2] Il primo Italian Agile Day del 2004
https://web.archive.org/web/20090221161727/http://agileday.it/2004/

[3] Unconference: cos’è e come svolgerla da remoto
https://mia-platform.eu/it/blog/unconference/

[4] Manifesto per lo sviluppo agile di software
https://agilemanifesto.org/

[5] Mia Platform
https://mia-platform.eu/it/

[6] Giallocobalto, service design
https://www.giallocobalto.it