Elogio della procrastinazione, metodi agili e antifragilità
Introduzione
Nassim Nicholas Taleb, il lettissimo autore de “Il cigno nero” (2007) nel 2012 ha Scritto “Antifragile”, che egli stesso definisce la sua opera più importante.
In Antifragile Taleb dà per scontata l’affermazione che i Cigni neri dominino la società e la storia, poi passa a considerare le conseguenze pratiche di questa consapevolezza.
Ma cos’è un Cigno nero secondo Taleb? Un Cigno nero è un evento imprevedibile e anomalo con un impatto enorme su vasta scala. La proprietà più rilevante dei Cigni neri, oltre al grande impatto, è l’impossibilità di calcolare il rischio che si verifichino. Inoltre, i Cigni neri tendono a ingannarci, perché retrospettivamente si possono spiegare, ma il fatto è che la probabilità che un evento raro si verifichi è semplicemente impossibile da calcolare, il limite è matematico e inaggirabile.
A questo si aggiunga che alcuni sistemi, metodi, oggetti, realtà sono particolarmente soggette agli effetti negativi del caso, della variabilità, della volatilità, dei Cigni neri, dunque. È questa la caratteristica di ciò che è fragile.
Ciò che invece è indifferente (in una certa misura, s’intende) al caso, alla variabilità, alla volatilità lo si definisce robusto. La robustezza, però, non è il contrario della fragilità. Nell’arco delle possibili reazioni al caso la robustezza, o resilienza, è il punto neutro. È la proprietà di quelle realtà che non sono danneggiate dal caso e dall’imprevedibilità.
Ciò che invece trae vantaggio dall’imprevisto è definito da Taleb antifragile.
“L’Antifragile ama il caso e l’incertezza, il che significa anche, ed è fondamentale, che ama l’errore, o perlomeno un certo tipo di errori. L’Antifragilità possiede la singolare caratteristica di consentirci di affrontare l’ignoto…”.
Pertanto, sostiene Taleb, non sprechiamo tempo a cercare di prevedere i Cigni neri, non basiamo la nostra azione e i nostri metodi sull’illusione di poter dominare il caso tramite previsioni, agiamo invece in modo da essere relativamente immuni alle tempeste del caso o, meglio ancora, agiamo in modo da trarre vantaggio da una certa dose di caso, variabilità, imprevedibilità, volatilità, ecc.
Cosa c’entra tutto questo col project management e i metodi agili?
Lo studio del 2001 “Extreme chaos” di Standish Group International[1] definisce come criterio di successo di un progetto l’essere completato nel rispetto dei tempi, del budget e con tutte le caratteristiche originariamente specificate. Secondo il medesimo studio, in base alla definizione solo il 28% dei progetti può essere considerato di successo.
Il 72% dei progetti dimostra la propria fragilità in questo: che le previsioni iniziali sulle quali era basata la pianificazione non avevano pressoché nessuna attendibilità. Il caso e la variabilità le hanno distrutte.
In uno studio più recente (2014) di Standish[2] i dati emersi dalle interviste di un campione di 365 intervistati (IT manager) dimostrano che, complessivamente, il tasso di successo è peggiorato scendendo al 16,2%, contro il 52,7% di progetti fuori tempo, budget o features, e il 31,1% cancellati.
Tra i progetti senza successo quasi un terzo dei progetti ha avuto un superamento dei costi dal 50 al 100%.
Più di un terzo dei medesimi progetti ha anche sperimentato superamenti di tempo dal 100 al 200%.
Più di un quarto sono stati completati con solo dal 25% al 49% delle caratteristiche e delle funzioni originariamente specificate.
Ma c’è un problema ulteriore alla quantità impressionante di progetti che superano il tempo o il budget a disposizione o si concludono senza tutte le caratteristiche stabilite dalle specifiche iniziali.
Il problema ulteriore è che anche un progetto che si concluda con tutte le caratteristiche inizialmente specificate non è necessariamente un progetto di successo, anzi, molto probabilmente non lo è. Utilizzando la terminologia di Taleb possiamo dire che un tale progetto si è rivelato robusto, ha resistito alla variabilità, ha saputo mantenere la rotta e condurre in porto la nave.
È un risultato notevole, senz’altro, ma insufficiente. Perché è la stessa definizione di successo a essere insufficiente in questo caso.
Il motivo è che raramente le specifiche iniziali sono le migliori. Le caratteristiche di cui deve essere dotato il prodotto per essere innovativo e di successo, tipicamente emergono, o si precisano, nel corso del tempo e stabilire tutte le specifiche all’inizio significa farlo proprio nel momento in cui le informazioni a disposizione sono le minori possibili. La variabilità delle specifiche verso la quale il progetto si deve immunizzare per garantire uno dei criteri di successo – l’implementazione di tutte le caratteristiche originariamente specificate – è proprio la fonte di quelle informazioni che potrebbero rendere il prodotto finale migliore.
Gli utenti e i clienti del prodotto non sarebbero probabilmente soddisfatti se le idee di nuove meravigliose caratteristiche emerse durante lo svolgimento del progetto fossero rifiutate in favore di quelle mediocri semplicemente perché le caratteristiche mediocri erano nel piano iniziale.
[1] https://www.cin.ufpe.br/~gmp/docs/papers/extreme_chaos2001.pdf
[2] https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
Da questo punto di vista potremmo definire i metodi tradizionali di project management come una ricerca della robustezza. Ciò che è robusto resiste agli shock rimanendo inalterato. Come si è detto, nel project management ciò significa che lo scopo di un metodo di conduzione di progetto robusto è quello di condurre a termine l’ardua impresa di soddisfare tutti i requisiti iniziali rispettando tempi e costi.
Così facendo il project management classico però non trae vantaggio dall’incertezza, che è invece esattamente la missione dell’Antifragilità: anziché resistere di fronte alle tempeste del caos, migliorare grazie ad esse.
Lo ripeto, perché non è facile crederci, non si tratta di arginare l’incertezza e il caso, ma di volgerli a nostro vantaggio.
Questa è, io credo, la specificità dei metodi agili, come dichiarato in uno dei quattro punti del manifesto agile (agilemanifesto.org):
“Rispondere al cambiamento più che seguire un piano”
Iatrogenicità
Iatrogenesi, che letteralmente significa «causato dal guaritore», è il danno ovvero la tendenza ai danni causati dal guaritore, per esempio quando gli interventi del medico fanno più male che bene.
Il termine è di origine medica ma Taleb lo generalizza e lo estende agli effetti collaterali dannosi dell’interventismo eccessivo che impedisce ai sistemi che ne hanno la capacità di autoregolarsi.
L’applicazione al project management è mia. Io vedo iatrogenicità nel project management che cerca di limitare i cambiamenti di specifiche per preservare inalterate le probabilità di successo. La cura per preservare i progetti dalle influenze nefaste del caso conduce comunque, come abbiamo visto, a risultati imbarazzanti dal punto di vista del tasso di “successo” dei progetti e sicuramente impedisce di sfruttare al meglio tutte quelle conoscenze a proposito del prodotto e del metodo che si sviluppano e precisano nel corso dell’attività progettuale.
I metodi agili hanno tra i loro principi programmatici l’accettazione del cambiamento, per questo lavorano in modo iterativo. In Scrum, il framework agile più noto[1], l’iterazione si chiama Sprint e tipicamente dura da 1 a 4 settimane.
Alla fine di ogni Sprint sono previsti due eventi specificamente votati alla raccolta di feedback da parte degli stakeholder e del team stesso che svolge il lavoro. Questi momenti sono, rispettivamente, la Sprint Review e la Sprint Retrospective.
La Sprint Review è una riunione che si tiene alla fine dello Sprint per ispezionare l’incremento di prodotto e adattare il Product Backlog (l’equivalente, per certi versi, della lista dei requisiti o della WBS[2]), se necessario. La presentazione dell’incremento è proprio intesa a suscitare un feedback e favorire la collaborazione. Il risultato della Review è un Product Backlog rivisto che definisce i probabili elementi del Product Backlog per il prossimo Sprint. Il Product Backlog può anche essere aggiustato complessivamente per soddisfare nuove opportunità o comunque in base alle nuove conoscenze acquisite nel corso dello Sprint.
La Sprint Retrospective è invece un’opportunità per il team di ispezionare sé stesso e creare un piano di miglioramento da attuare durante lo Sprint successivo. Lo scopo della Sprint Retrospective è di:
- Ispezionare come è andato l’ultimo Sprint per quanto riguarda le persone, le relazioni, il processo e gli strumenti
- Identificare e ordinare gli elementi principali che sono andati bene e i potenziali miglioramenti
- Creare un piano per implementare i miglioramenti
[1] https://scrumguides.org
[2] Work breakdown structure (WBS), l’elenco di tutte le attività di un progetto. Le WBS sono usate nella pratica del project management e aiutano il project manager nell’organizzazione delle attività di cui è responsabile.
Sul procrastinare
Sono un procrastinatore e come credo molti procrastinatori mi sento in colpa per esserlo. Apprendere dunque da Taleb i vantaggi della procrastinazione è stato un balsamo per la mia autostima.
Secondo Taleb la procrastinazione in alcuni casi è positiva perché è una forma naturale di decision making basata sul rischio. Noi esseri umani, infatti, siamo poco dotati nel filtrare le informazioni, la procrastinazione può aiutarci a filtrarle meglio e a resistere alle conseguenze dell’assalto delle informazioni.
Ho trovato il medesimo principio nella letteratura Agile e Lean[1] espresso come Last Responsible Moment (LRM), la strategia di non prendere una decisione prematura ma di ritardare l’impegno e di tenere aperte le decisioni importanti e irreversibili finché il costo di non prendere una decisione diventa maggiore del costo di prenderne una. Anche questa strategia ha come scopo la massimizzazione dell’apprendimento nel corso di un progetto, ovvero la massimizzazione della possibilità di tenere conto di informazioni disponibili solo tardivamente.
[1] Mary Poppendieck, Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison-Wesley Professional (2003)
Effetto Drachten, sovracompensazione e pianificazione
La sovracompensazione è il processo di adattamento di un organismo ai fattori di stress. Secondo Taleb il meccanismo di sovracompensazione è presente in tanti ambiti. Nell’ambito dell’allenamento fisico il fenomeno è ben conosciuto e su di esso si basa quasi tutta la teoria dell’allenamento. Nell’ambito psicologico un esempio ne è il fenomeno della crescita post traumatica. Molto meno nota del disturbo post traumatico, la crescita post traumatica rappresenta in tipico esempio di antifragilità in quanto in essa lo stress non agisce negativamente (fragilità), né rimane privo di effetti (robustezza), ma determina una crescita. Tale crescita è provocata da una sovracompensazione che scatena una iperreazione a una difficoltà e tale iperreazione rappresenta la crescita.
All’inizio degli anni duemila nella cittadina di Drachten, in Olanda, è stato condotto un esperimento: sono stati tolti tutti i cartelli stradali e tale deregolamentazione ha portato a un aumento della sicurezza[1], confermando l’antifragilità dell’attenzione e il fatto che questa sia stimolata da un senso di pericolo e responsabilità.
Applicato al project management agile l’effetto Drachten lo si può rinvenire nell’atteggiamento di potenziale maggiore vigilanza indotto dal non seguire un consolatorio (quanto illusorio, spesso) diagramma di Gannt, unito alla maggiore attenzione all’esito del proprio lavoro, da parte dei membri del team, dato dal fatto che, lavorando per brevi iterazioni, il momento di confronto con gli stakeholder non è mai troppo lontano nel tempo, contribuendo così al mantenimento di un senso di urgenza.
Sto forse sostenendo che sia sbagliato pianificare? No. Quello che sto sostenendo è che sia sbagliato illudersi di prevedere l’imprevedibile. Noi agilisti pianifichiamo e pianifichiamo molto, ma non ci illudiamo a proposito delle pianificazioni. Una pianificazione è agile se può essere cambiata facilmente e viene effettivamente aggiornata spesso.
Il processo di pianificazione agile, descritto brevemente, è così strutturato:
- Costruisci un primo backlog inteso come elenco, ordinato in base al valore, delle caratteristiche di prodotto descritte dal punto di vista dell’utente
- Stima lo sforzo complessivo necessario alla implementazione di ciascun elemento del backlog in modo unicamente relativo (un elemento che vale 2 richiede il doppio dello sforzo di un elemento che vale 1), con numeri puri tratti dalla successione di Fibonacci[2] (ma non andare oltre il 13 perché l’essere umano riesce a stimare meglio, in senso relativo, all’interno di un solo ordine di grandezza). Chiama questi numeri ‘punti’
- Esegui una iterazione (uno Sprint, lo Sprint 0) e vedi quanti punti il team riesce a lavorare
- Dividi la sommatoria dei punti dell’intero backlog per i punti che sei riuscito a lavorare nello Sprint 0 e avrai una prima stima (in numero di iterazioni) di quanti Sprint serviranno per finire, moltiplica il numero di iterazioni così ottenuto per la durata di una iterazione (da 1 a 4 settimane) e avrai una data di calendario (molto indicativa, si intende)
- Aggiorna a ogni sprint la stima con la media dei punti lavorati negli ultimi 3 sprint
- Ad ogni sprint includi tanti elementi del backlog quanti ce ne stanno rispettando l’ordine determinato dal loro valore
Un tale processo di pianificazione è relativamente immune da alcuni difetti che affliggono le pianificazioni basate su WBS e Gannt:
- Grazie alla stima in punti non vengono stabilite all’inizio le durate dei task, come richiede un diagramma di Gannt. Stabilire la durata di un task equivale ad ammettere che la sua durata sarà maggiore o uguale a quella stabilita. In virtù della legge di Parkinson[3]: “Il lavoro si espande in modo da riempire il tempo a disposizione per il suo completamento.”
- A causa della dipendenza tra le attività, inoltre, gli eventuali ritardi si propagano. Quindi, in virtù del punto precedente, una attività non richiede mai meno tempo del previsto, poi se c’è un ritardo questo si propaga per effetto della dipendenza tra le attività
- Grazie alla pianificazione per caratteristiche di prodotto e non per attività, la misura del reale avanzamento diventa il numero di caratteristiche implementate, e non quello delle attività completate. Completare attività senza produrre caratteristiche di prodotto visibili all’utente finale non consente di avere feedback dall’utente stesso. Si potrebbe anche giungere al paradosso di avere completato tutte le attività tranne una, quell’ultima che renderà il prodotto ispezionabile al cliente o utente, per accorgersi solo in quel momento quanto distante sia il prodotto dalle aspettative reali degli stakeholder
- Spesso nella pianificazione tradizionale non c’è un esplicito ordinamento delle attività inteso a produrre in definitiva le caratteristiche in un ordine determinato dal loro valore (per l’utente finale), le attività sono invece ordinate sulla base della convenienza del team
[1] https://www.lastampa.it/motori/2006/12/18/news/la-citta-che-ha-spento-i-semafori-1.37142348
[2] La successione di Fibonacci ha la proprietà notevole di avere intervalli crescenti tra un numero e il successivo. L’eliminazione di alcuni numeri toglie l’illusione di esser capaci di distinguere davvero tra un 12 e un 13.
[3] https://www.treccani.it/enciclopedia/legge-di-parkinson_%28Dizionario-di-Economia-e-Finanza%29/
Sbagliare poco e spesso
Lavorare per brevi iterazioni (se breve significhi 1 o 4 settimane dipende dalla durata del progetto) consente di sbagliare poco e spesso.
Senza grandi danni, dunque, e con la costante possibilità di imparare dai propri e altrui, eventuali, errori.
Quando un progetto o metodo di project management è fragile, è necessario che le cose vadano alla lettera come da programma, evitando al massimo i cambiamenti, in questo caso più dannosi che utili. È per questo che il fragile ha bisogno di un approccio previsionale molto dettagliato. Ma, d’altro canto, i sistemi previsionali portano fragilità. Antifragile è invece il metodo di project management che accoglie le deviazioni perché sa che sono portatrici di nuova conoscenza. Inoltre, nel metodo per tentativi l’elemento casuale non è poi così casuale, se portato avanti razionalmente e l’errore viene utilizzato come fonte di informazione. Se ogni tentativo fornisce informazioni su ciò che funziona e ciò che non funziona, ogni tentativo è utile e più simile a un investimento che a uno sbaglio. E lungo il percorso se ne scopriranno delle belle!
Digital Distributed Workplace
Lavorare ad elevata performance nell'era della digital trasformation.
