Il Dream Team

Loading

3, 2, 1...si parte

Rotta: il mondo sommerso

dell'Agilità.

Sommerso in quanto non ancora noto in una azienda che inizia ad approcciarlo. Può essere applicato in vari settori, ma come? Un tema molto ampio. Occupiamoci quindi degli approcci possibili.

Nel corso della conferenza Agile4Management tenutasi al Palazzo delle Stelline di Milano lo scorso 22 gennaio sono stati presentati scenari per l'introduzione (con successo) dell'agilità nella gestione dei progetti in alcune aziende come Vodafone, BancaSella, Enelx, Credem.

In tutti i casi è emerso come la comunicazione e la condivisione tra azienda, intesa come management e dipendenti è stata  un elemento fondamentale senza il quale le persone non si sentono coinvolte, valorizzate, legittimate.

Il primo step, come già sappiamo dalla teoria della gestione del cambiamento è creare un senso di urgenza questa è la partenza del nostro viaggio.

Il Senso di Urgenza

In alcuni contesti l'approccio è stato quello di creare una sorta di "Dream Team". Il team di persone, scelto su un progetto significativo, dovrà completarlo nella nuova modalità, utilizzando un opportuno framework Agile. L'approccio quindi è empirico e può darci, al termine, degli ottimi feedback su come  poi agirlo nel resto dell'azienda, magari un team per volta.

Siamo in un'ottica di change management dobbiamo introdurre un cambiamento e per farlo capire dobbiamo avere quell'atteggiamento mentale che potremmo riassumere in questo claim di Steve Jobs:  

stay hungry, stay foolish.

Per senso di urgenza si intende mettere in luce tutte le situazioni che non ci possono più tenere nella confort zone e cosa succederebbe se ci ostinassimo a rimanere. Insomma mantenerci affamati e anche un pò folli. John Kotter, professore emerito di leadership ad Harvard ha realizzato un divertente cartone animato dal titolo Our Iceberg is Melting (Il nostro iceberg si sta sciogliendo) che trovate su Youtube e di seguito linkato, dura solo dieci minuti.

In questo video un gruppo di pinguini si rende conto che l'iceberg dove vive la loro numerosa colonia si sta sciogliendo e non resisterà all'estate. Questa è l'opinione di Fred il pinguino più visionario. Fred prima deve convincere il comitato dei saggi dell'urgenza e lo fa attraverso un esperimento che mostra le conseguenze dello scioglimento dell'iceberg. Il successo dell'esperimento spinge i saggi ad avvisare il resto della colonia e ad attivare un piano di ricerca di una nuova casa. Il processo non è noto a priori, i pinguini imparano man mano che procedono e capiscono non solo che dovranno trovare un nuovo iceberg, ma anche che non potranno più ri-diventare stanziali. Dovranno cercare nuove case in continuazione così come è nella loro natura, spostarsi, modificarsi, evolversi. Stare fermi sarebbe la loro fine.

Il Dream Team

Ritornando quindi al senso di urgenza, una volta creato , il passo successivo è creare un "dream team". Un gruppo di persone che si occuperà di delineare una visione della soluzione, verificarla e poi comunicarla assieme alla necessità del cambiamento. Il dream team deve mettere in atto tutte quelle strategie di supporto rivolte a chi fa fatica ad accettare il cambiamento creando piccoli successi nell'immediato (lavorando a sprint). Il dream team deve anche, se necessario, isolare gli eventuali Signor "no no" ovvero quelle persone che sono sempre contrarie a tutto perchè "nessuno si è mai lamentato della situazione attuale" o perchè "cambiare vuol solo dire cambiare in peggio"; vengono rimossi gli ostacoli. Questi sono atteggiamenti fragili che non puntano a migliorare il sistema.

Nel nostro video infatti i pinguini rifiutano soluzioni che potrebbero irrobustire l'iceberg, come mettere della colla....!!! Perchè come scrive Taleb nei suoi libri, questo comportamento irrobustisce il sistema iceberg ma fino al nuovo evento negativo (chiamato da Taleb il Cigno Nero) . I pinguini decidono di cambiare visione e trovare una nuova casa. Ciò che nel mondo aziendale è  un nuovo sistema, un nuovo prodotto, una nuova metodologia. Stiamo evolvendo a fronte di un bisogno, di una urgenza.

Stiamo realizzando implicitamente l'antifragilità.

Conclusioni

Ecco quindi che, come dicevamo all'inizio, un modo per partire è quello di costituire un dream team che realizzi il progetto secondo le nuove metodologie Agile inserendo varie figure professionali, non solo tecniche. Al termine del progetto questo dream team diventerà il gruppo di "evangelisti" che aiuterà l'azienda ad evolvere mutuando la propria esperienza con all'attivo un risultato appena raggiunto.

Naturalmente questo non è l'unico approccio possibile per introdurre il cambiamento nella gestione dei progetti, ma sicuramente un approccio che di per sè incorpora i principi del manifesto Agile e che raggiunge obiettivi concreti ed analizzabili con metriche che ci consentiranno una successiva analisi. 

Buona visione!

Antifragilità o AntifrAGILEità

Loading

Abstract

Posso trasportare dei bicchieri di cristallo senza romperli? Certo in una scatola di cartone. 

E se viaggio in treno? Be’ una scatola più robusta.

E se la scatola viene messa in un bagagliaio? Ci mettiamo delle belle scritte sopra “FRAGILE”. E se faccio un incidente?

Posso trovare sistemi sempre più robusti? Come proteggo i miei bicchieri nel trasporto?

Forse non dovrei proprio utilizzare oggetti così fragili in un trasporto, ma ripensare ad altre soluzioni: andare verso un approccio antifragile.

Testo integrale dell'articolo sul mensile di AgileForItaly di Marzo 2020

Prosperare nel disordine

Ho preso spunto dal libro di Taleb sull’antifragilità proprio per introdurre con poche parole ciò di cui parleremo nei prossimi paragrafi prima ancora di darne una definizione.

Nei sistemi naturali l’antifragilità è nota e fa parte del concetto di evoluzione della specie secondo il quale solo gli organismi che si adattano sopravvivono. Se siamo d’accordo che tutto cambia, anche la natura cambia quindi, ad esempio, alcuni organismi adatti alla vita un milione di anni fa potrebbero non esserlo più oggi. 

Il meccanismo in questo caso è l’evoluzione, la natura non si limita a proteggere gli organismi per farli sopravvivere il più possibile ma li porta ad evolvere mettendoli “sotto stress”  così che il loro dna è spinto ad adattarsi e cambiare. I cicli di adattamento sono lunghi, non stiamo parlando di qualche giorno/settimana come nei progetti , ma di migliaia di anni. La natura non solo accoglie i cambiamenti ma ne li utilizza per trarne vantaggio.

Di seguito ho voluto fare un esercizio. Ho preso alcuni punti tratti dal manifesto Agile e li ho applicati al sistema “evoluzione naturale” per iniziare ad introdurre un concetto fondamentale, la resistenza e la resilienza non sono concetti antitetici alla fragilità. Ci sono altre vie.

I principi del Manifesto Agile e la natura

Primo Principio

“Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo.

I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.”

Se il cliente è la natura, intesa come ambiente naturale in cui vivono gli organismi (tra cui l’uomo) ed il progetto è il dna di una qualunque specie, i cambiamenti sono accolti, con tempi molto lunghi, ma per mantenere la natura competitiva: non può certo evolvere un predatore se non evolve anche la preda. Questi cambiamenti sono continui anche su specie molto antiche ed hanno un senso che va visto dal punto di vista “del tutto”. La visione dall’alto che ci permette di capire come cambiamenti visti da vicino possono non avere senso.

Secondo Principio

“La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale”.

Qui si intende che tutto ciò che non è utile non va fatto. In natura non esistono organismi non utili, tutto serve e tutto ha uno scopo, anche le fastidiose meduse? Sì anche loro...

Terzo principio

“A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza”

Il team qui non è facile da vedere. Dobbiamo introdurre una visione più sistemica. Da un lato abbiamo esigenze evolutive naturali, la natura cambia e spinge quindi ogni organismo ad adattarsi. Gli organismi fra di loro non agiscono singolarmente. Chi si adatta in modo estemporaneo o non conforme non è destinato a durare molto. C’è quindi un modo di procedere per soddisfare i requisiti del cliente “natura” e questo modo, una volta trovato, va implementato da tutti i dna coinvolti. Come abbiamo detto però è impensabile ipotizzare che l’evoluzione riguardi un singolo sistema (organismo), deve essere generalizzata. Se una preda si evolve per vivere di notte, anche i suoi predatori devono farlo, altrimenti non sopravviveranno. In questo caso quindi i team sono i dna degli  esseri viventi che devono, a intervalli regolari, risintonizzarsi e adattarsi. Certo non lo fanno attraverso meeting, ma lo fanno in continuazione. Nel “breve periodo” lo vediamo sui batteri che si modificano per essere più resistenti agli antibiotici. Col passare del tempo dobbiamo creare antibiotici diversi ovvero sempre più potenti, ma cosa in realtà stiamo facendo? Stiamo tentando di mettere sotto una campana di vetro (l’antibiotico) l’essere umano, anzichè trovare il modo di evolvere modificando comportamenti atti a rinforzare il nostro sistema immunitario o a migliorare lo stile di vita in modo che l’ambiente ci faccia ammalare di meno.

Cos’è quindi l’antifragilità?

Il libro di riferimento di questa disciplina è “Antifragile. Prosperare nel disordine” di Taleb.

Taleb sostiene che non è utile e neanche possibile prevedere e misurare il rischio di eventi rari e importanti per un sistema, un programma, un’azienda. Anche qualora riuscissimo, avremo solo misurato il rischio ma non avremo comunque risolto il problema o evitato che quell’evento accada, anche se distruttivo.

Nei sistemi e nelle aziende, viste come processi, ci sono per natura eventi “casuali”, incerti nella loro manifestazione, ci sono errori. Per esempio quando si rilascia un software in test se non si verificano errori (bugs) il programmatore è più preoccupato di quando invece si verificano. Un software funzionante “al primo colpo” è come se portasse in sé un problema non visibile, crea inquietudine nel programmatore. Ma se il problema si verifica nelle fasi di test allora siamo certi di aver scoperto tutti i difetti di quel programma ? No.

Quindi l’evento problematico può sempre avvenire. Possiamo misurare statisticamente la frequenza con cui gli eventi negativi si possono verificare, ma non risolverlo a priori perchè non sappiamo cosa si verificherà.

Secondo Taleb è necessario un cambio di approccio che veda i “sistemi” non come oggetti fragili che devono quindi essere contenuti in apposite scatole che li proteggono da tutto, ma come oggetti antifragili che si rafforzano dall’incertezza e dalla casualità. Vediamo in dettaglio.

Fragile e Antifragile

Gli errori che sfociano in problemi non possono secondo Taleb essere eliminati costruendo sistemi di contenimento asettici. 

Portare antifragilità nei nostri sistemi vuol dire quindi accogliere l’incertezza evitando di chiudersi in una gabbia dorata.

Antifragile quindi non è l’opposto di fragile. Fragile è un sistema che ha delle criticità e per il quale dobbiamo mettere in atto un comportamento cauto: la scatola di imballaggio che contiene fragili porcellane, l’antibiotico, il vaccino. In un sistema fragile possiamo attuare un comportamento atto a proteggere ma non a risolvere il problema alla base. 

Volendo ipotizzare uno scenario possiamo pensare alle situazioni in cui un committente ha un solo fornitore per tutte le attività “core”. Se queste attività sono per il committente critiche e se richiedono molto know-how, maturato dallo stesso fornitore negli anni, allora abbiamo un sistema  fragile. Il committente è legato mani e piedi al fornitore che può decidere di alzare le tariffe o modulare le richieste del committente senza che ci sia la possibilità di avere una concorrenza. Iniziano una serie di controversie che mettono in crisi il rapporto lavorativo. Che fare?

E’ possibile irrobustire questo contratto cambiandone i termini giuridici e fissando le tariffe nel tempo, è anche possibile che il committente inserisca persone in modo che il know-how si sposti più all’interno. Se entrambi riescono a raggiungere un accordo allora avranno mostrato comportamenti resilienti e quindi hanno saputo reagire alla difficoltà del momento.

Tuttavia la risoluzione della crisi, se vista in termini generali, non ha portato grossi vantaggi ai due attori. Non c’è stata una evoluzione ma una risoluzione. Committente e fornitore hanno solo indossato delle armatura più resistenti.

La stessa situazione potrebbe ripetersi nel tempo. Probabilmente le stesse contromisure verrebbero messe in atto dopo una serie di meeting, discussioni, litigi e reciproche accuse. “Alla fine a nessuno conviene cambiare” si direbbe, oppure “dove andiamo a prendere un altro fornitore con questa esperienza”. Frasi di questo tipo le abbiamo sentite tutti in ambito aziendale e, credo, in qualunque settore che preveda un rapporto cliente-fornitore.

Serve un nuovo approccio

Un comportamento antifragile è altra cosa e nella situazione appena descritta prevede di ridefinire l’accordo tra i due attori in modo che ciascuno possa trarre beneficio dalla crisi in un senso evolutivo. Il committente potrebbe decidere di ampliare il “parco fornitori”, il fornitore del servizio core potrebbe proporsi ed essere coinvolto su altri fronti, per lo stesso committente, in modo da non sentirsi messo da parte e da risolvere la situazione di monopolio.

La cosiddetta situazione win-win della teoria dei giochi.

Questa modalità implica uno sforzo non indifferente perchè si tratta di rischiare, di cambiare modalità e mindset, di imparare da ciò che probabilmente è già avvenuto in passato per modificare il nostro dna. 

Le modifiche poi non riguardano solo certi livelli di management aziendali, quelli che devono prendere decisioni su fornitori e forme contrattuali, ma anche i livelli più operativi che dovranno interfacciarsi a fornitori da formare, uscendo da una certa confort zone alla quale erano abituati.

Ancora una volta torniamo al manifesto agile notando delle similitudini che ci portano a dire che l’antifragilità è agile, potremmo coniare un nuovo termine: antifrAGILEità

Possiamo dire che l’antifrAGILEità accoglie l’incertezza così come in agile si predilige il cambiamento dei requisiti. Si preferiscono strategie basate sulla sperimentazione così come in agile non c’è nulla di definito a priori se non il product backlog che può cambiare nel tempo. Nei review meeting di Scrum ciò che è stato rilasciato può essere soggetto a richiesta di modifiche da parte degli stakeholder. In antifragilità si evitano approcci calati dall’alto o da persone specifiche. Agile è corale, tutto il team partecipa, si auto-organizza ed è competente. 

L’antifrAGILEità promuove la cultura della collaborazione così come in qualsiasi framwork agile

Come tutto ciò si legge nei processi aziendali e nei progetti it?

Processi e framework rigidi, fissi, e che abbiano un feedback loop molto lungo sono sicuramente fragili perchè gli eventi che possono accadere possono destabilizzare qualunque punto della loro catena. Possiamo irrobustirli e migliorarli ma non possiamo azzerare il rischio.

Spesso ad esempio nei progetti vogliamo fare stime precise e costi precisi ma non ci occupiamo delle disfunzioni, del fatto che ci sono molti fornitori che non si parlano o che chi fa analisi funzionali e stime non è preparato per farlo.

Parafrasando situazioni in cui mi sono trovato spesso ad operare, ho ricevuto richieste che potrebbero suonare così (e non sto esagerando molto):

D: “Mi serve un interfaccia grafica che mi consenta di fare delle ricerche su alcuni dati” Puoi sviluppare qualcosa?” 

R: “Si ma cosa? Cosa deve fare, a chi è rivolto, quali sono i campi di ricerca e che tipo di dati abbiamo?” 

D: “Non so però tu inizia a fare qualcosa e prima dammi una stima” 

In genere questa è l’analisi più precisa che si riesca ad ottenere. Quindi il committente vuole un primo approccio waterfall in cui vuole avere chiaro tutto, costi, tempi, rischi, analisi di dettaglio in modo da non avere sorprese sul budget e garanzie sul rilascio, ma…

Senza avere chiaro ciò che vuole, tanto poi lo si vedrà in corsa…

Quindi una stima waterfall da sviluppare con un approccio agile...

Come abbiamo detto non si tratta di irrobustire dando al cliente ciò che “forse” vuole e stimando cose impossibili, ma cambiando approccio, ad esempio convincendolo che l’approccio corretto in questo caso è indubbiamente agile, partendo da un product backlog e andando per raffinamenti successivi.

Il cliente ha la garanzia di vedere i suoi bisogni accolti nel corso del progetto, visto che ha ancora le idee molto confuse. Il fornitore deve adottare una metodologia forse diversa rispetto a quella a cui era abituato lo stesso il cliente, ma entrambi evolvono verso un nuovo modello progettuale. 

Conclusioni

Innovare e cambiare strategia, non chiudersi in una gabbia dorata, non stare sul proprio iceberg e accogliere l’incertezza sono solo alcuni dei principi del manifesto sull’antifragilità. Già qui troviamo alcune similitudini con altri concetti dell’Agilità. In questo articolo ho costruito un percorso per trovare dei punti di contatto tra i due mindset spiegando cos’è l’antifragilità anche con alcuni esempi tratti dal mondo reale e professionale. E’ un ulteriore passo per cercare di attraversare mindset, framework, tecnologie in un’ottica olistica che possa farci comprendere il tutto sotto le lenti di una visione sistemica.

Bibliografia

Principio di Antifragilità da Wikipedia

Manifesto agile

Manifesto antifragile

Antifragile. Prosperare nel disordine - N. Taleb (2013)

a