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