Pubblicato il

Leadership e comunicazione degli obiettivi

Loading

Definire chiaramente gli obiettivi, ma con quale limnguaggio?

Il leader quali aspetti deve curare?

 E’ meglio evidenziare ciò che il team dovrebbe raggiungere o ciò che dovrebbe evitare? 

Per rispondere a queste domande ho fatto un parallelismo con una sessione di coaching in cui gli obiettivi vanno sempre espressi in positivo. Vediamo perchè e come utilizzare questa tecnica nella gestione della leadership.

 

La definizione dell’obiettivo di una sessione di coaching riveste un'importanza fondamentale al fine del successo della sessione stessa, identifica il punto di arrivo. Assieme al risultato atteso permette ad entrambi gli attori della sessione (coach e coachee) di costruire un percorso di esplorazione, di consapevolezza, di strategia e di azioni. Naturalmente tale obiettivo deve essere carico di motivazioni per il coachee, altrimenti il percorso non avrebbe la giusta energia per essere costruito ed attraversato.

Sappiamo, per chi ha una formazione da coach, che, tra le altre cose, l’obiettivo va espresso in positivo. Perchè? Qual è l’effetto del formularlo in positivo?

C’è differenza tra negativo e positivo?

Esprimere l’obiettivo in positivo permette al coach di facilitare il coachee nella definizione del suo percorso di consapevolezza. L’obiettivo, espresso in maniera chiara e diretta delinea il traguardo che il coachee vuole raggiungere utilizzando risorse che sono già presenti in lui/lei. E’ un viaggio che si intraprende con ruoli distinti costruendo un ponte tra dove il coachee è ora e dove vorrà essere al termine della sessione. 

 

L’obiettivo deve avere quindi una bella energia, intensa e riconoscibile.

 

Partire esprimendo, all’interno dell’obiettivo, un concetto negativo, abbassa l’energia. Proviamo inoltre a pensare cosa succede quando qualcuno ci chiede di non pensare a qualcosa. Dopo pochi secondi noi la pensiamo, magari anche solo per non pensarla…

A parte il gioco di parole, se dicessi: “ora non pensare a quanto eri arrabbiato stamattina” quale effetto sortirei? Sicuramente, anche solo per pochi secondi, la vostra mente vi riporterà a quella sensazione di rabbia, alle sue cause, se note, ma in ogni caso i processi mentali porterebbero parte delle mie energie verso una direzione da cui invece voglio prendere le distanze.

Concentriamoci quindi su ciò che vogliamo piuttosto che su ciò che non vogliamo. Proviamo però a scendere ad un livello più profondo per capire davvero cosa stiamo facendo trasformando in positivo la definizione dell’obiettivo di sessione.

La nostra mente tende a riproporre sempre gli stessi schemi. Ce lo spiega bene Gallwey in uno dei suoi libri, “Il gioco interiore del tennis”. Ma non è il solo, anche John Kotter in un simpatico cartone animato intitolato “Who moved my cheese”, reperibile su youtube, ci mostra come è più semplice aspettare che le cose cambino.

Ma chi le deve far cambiare? Qualche entità esterna? Una magia forse?

Alice: Quale via dovrei prendere? 

Gatto: Dipende dove vuoi andare. 

Alice: Ma io non so dove andare. 

Gatto: Allora non importa quale via prendere!” 

(tratto da Alice nel paese delle meraviglie di Lewis Carroll)

Se il coachee ha chiesto una sessione è perchè vuole lavorare su qualcosa che non gli sta più bene. Qualche volta ha già le idee chiare, altre, come nel caso di Alice, deve chiarirsele. In questo processo abbiamo un nemico, che Gallwey chiamerebbe il Sé1. Una parte razionale e controllora della nostra mente che vuole fare poca fatica, vuole ripercorrere gli stessi sentieri perchè cambiare implica imparare, andare verso l’ignoto, costruire nuovi schemi mentali e nuove sinapsi. Questa parte vuole comandare, scegliere il percorso da fare, che però sarà sempre lo stesso di sempre.

Lo stesso modo con cui scegliamo un nuovo lavoro, un nuovo partner, una nuova casa o la pizza quando andiamo al ristorante.

Se voglio mettere in atto nuove strategie Galwey e Kotter (ma anche altri) ci dicono che è più semplice ed immediato descrivere la mia voglia di cambiamento parlando di una insoddisfazione: parlo quindi dell’ostacolo, lo rappresento nella mia mente e lo espongo al mio coach.

Implicitamente sto dando a questa immagine mentale energia. E’ come se la facessi continuamente resuscitare anche se, in qualche modo, rappresenta qualcosa che vuole cambiare, evolvere, altrimenti non farei una sessione di “cambiamento”.

Quindi io voglio costruire una nuova strada o, in termini più tecnici un ponte tra questa immagine e il futuro.

Se il futuro lo immagino identico al presente allora inutile percorrere la strada, siamo già arrivati!

Meglio sforzarsi a immaginare un obiettivo che parli del nuovo: ciò che vorrei “al posto di”, come vorrei essere. Insomma cara Alice dove vuoi andare?

Nel momento stesso in cui, con l’aiuto del coach, riuscirò a mettere a fuoco la mia nuova meta, il fatto stesso di descriverla a parole attiva il cambiamento. Credo che ripetere insieme al coachee l’obiettivo, espresso in positivo, sia come un rituale, un mantra. 

L’atto di parlare del resto è vibrazione, lo dicono anche altre discipline, parlare di cose negative abbassa l’energia e quindi la vibrazione. 

Iniziamo quindi la sessione aumentando l’energia, alzando il livello di vibrazione, da qui in poi, verso il futuro.

Conclusione

Coach e coachee sono qui sostituibili con leader e team. Il leader formulando gli obiettivi in positivo inizia un processo di comunicazione che ha vibrazioni, e quindi energie, in crescendo stimolando simili vibrazioni in chi lo ascolta.

La comunicazione è parola e questa è vibrazione e chi ascolta può entrare in risonanza




Pubblicato il

Fixed Date nei Progetti Agili

Loading

Introduzione

Quando si pensa ai progetto “Agili”, realizzati con un qualsiasi framework, il pensiero successivo è “perdo il controllo”. Non ho più date fisse e il budget non è sotto controllo. Me lo sono sentito dire molte volte, come se agilità fosse un sinonimo di improvvisazione.

Niente di più sbagliato!

Vedremo anzitutto come le date variabili possono essere fonte di incertezza e possono creare anche più problemi; allo stesso tempo chiariremo il dubbio su tempi e costi di un progetto agile.

Date, Budget, Scope

In un articolo a proposito della gestione delle date fisse nei progetti Agili, Ron Jeffries, scrive: ”It's not that we don't have enough time. We have too much to do.”

Mantenere i tempi ed aumentare il carico di lavoro prima o poi fa “scoppiare il team”: rende le comunicazioni pessime e diminuisce la proattività del team. Questi sono dati ottenuti da varie fonti autorevoli che si occupano di teamwork e di soft skills, cito Goleman piuttosto che Scharmer. 

In questo tipo di situazione è il management che deve intervenire perché il suo compito è quello di identificare gli obiettivi e identificare risorse e persone necessarie a raggiungerli in modo razionale e pianificato. Non si tratta di puntare a caso il dito sul calendario, fissare una data e poi costruirci intorno un processo di sviluppo che, in molti casi, non la potrà soddisfare.

Del resto il management non può e non deve neanche delegare il team a identificare una data perché farlo vorrebbe necessariamente dire delegare anche l’autorità per gestire risorse e persone al fine di centrare la data. E’ chiaro che stiamo chiedendo al team di fare il manager. In realtà il team può solo fare il manager di se stesso e dei suoi compiti relativi al processo di sviluppo. Infatti per poter centrare una data di rilascio sarebbe necessario avere il controllo delle persone e delle features (dello scope).

Quindi il manager dovrebbe assumere un ruolo differente ed entrare in un’ottica di facilitatore. La responsabilità di gestione della data rimane la sua con l’aiuto del product owner.

Le variabili in gioco sono quindi tre, la data, lo scope ed il budget, rappresentabili con un triangolo:

Avere una data fissa per una certa release a volte aiuta, altre è proprio necessaria. Il rilascio di una funzionalità o di un prodotto potrebbe infatti coinvolgere più uffici, non solo il team di sviluppo, anche il marketing o la logistica che devono organizzare i propri piani di lavoro per arrivare all'obiettivo. Se non avessimo quella data stabilita potrebbe essere, ad esempio, impossibile far partire delle campagne pubblicitarie per il prodotto che stiamo rilasciando.

Stabilito quindi che è possibile gestire le date fisse, come gestiamo le altre due grandezze, budget e scope?

Anzitutto fissiamo il budget. In genere il business e l’it amano fissare il budget per ogni progetto al fine di avere quella sensazione di “ho tutto sotto controllo”. In realtà invece spesso si sfora con il budget perché le modifiche richieste sono spesso numerose ed impattanti. Consideriamo comunque, ai nostri fini, che il budget sia stato stabilito. In ogni caso stakeholder e eventuali sponsor dovrebbero sapere quanti soldi voglio investire nel progetto.

Come gestiamo lo scope?

Come per le altre due variabili possiamo fissarlo o renderlo variabile. Uno scope variabile ci permette di gestire i cambiamenti e le richieste di modifiche che, da manifesto agile, dovrebbero essere ben accolte. Ma accettare il cambiamento e accompagnarlo attraverso la rimodulazione dello scope, cosa che nell’agilità si fa attraverso il product backlog, è il primo passo per essere antifragili.

Quindi se il nostro obiettivo, mantenendo un focus variabile, è quello di avere una data ed un budget fissi, necessariamente dobbiamo avere il controllo sul team di persone, potendolo anche rinforzare, considerando sempre la legge di Brooks:  aggiungere forza lavoro ad un progetto software in ritardo, lo farà ritardare ancora di più.

Conclusioni

Tenendo in mente il nostro triangolo e fissata la data ed il budget, manteniamo variabile lo scope di progetto.

Lo facciamo attraverso un backlog di prodotto che cambia nel tempo in base alle richieste del business e dei clienti e anche all’andamento del progetto stesso. Alcune features potrebbero ad esempio essere tolte dal pb se non sono di primaria importanza e se il tempo o il costo di progetto sta aumentando troppo.

Lo scope quindi è il nostro strumento per essere antifragili e per rispondere alle avversità che sicuramente incontreremo, siano esse tecniche, che di persone.

I progetti agili permettono di far variare forma al triangolo vedendo appunto lo scope variabile. 

Pubblicato il

Report Agilità 2020: cosa ci racconta?

Loading

In Quale scenario viviamo? L’Incertezza

Un nuovo approccio è necessario da quando abbiamo esponenzialmente aumentato la nostra “velocità” di vita personale e professionale. Le tecnologie cambiano rapidamente, più della velocità di adattamento delle aziende che non utilizzano framework di gestione del progetto flessibili al cambiamento stesso, come mostra questo grafico.

Secondo i risultati forniti da IBM, il 90% dei dati disponibili  nel mondo sono stati prodotti negli ultimi due anni e ogni giorno vengono creati 2,5 quintilioni di byte dove un quintilione è pari a un miliardo di triliardi, ovvero 10 elevato alla 30, che corrispondono più o meno al download di mezzo miliardo di film in HD.

Viviamo quindi in un contesto altamente fluido in cui non possiamo avere certezza che la situazione odierna sarà la stessa che troveremo alla fine del nostro progetto.

Dobbiamo quindi essere antifragili, accettare il cambiamento ed utilizzarlo per evolvere.

Recentemente è stato pubblicato il quattordicesimo report sullo stato dell’Agilità, vediamo cosa dice…

Il Campione

I dati sono ottenuti da interviste fatte in aziende worldwide, il 41% delle quali ha meno di 1000 dipendenti. Tra queste il 36% sono aziende software. Gli altri range aziendali per numero di dipendenti sono il 19% tra 1000 e 5000, il 15% tra 5000 e 20000, il 25% sopra i 20000.

La maggior parte delle persone che hanno risposto al questionario sono scrum master, seguiti da PM, manager, team di sviluppo (nei diversi ruoli).

La maggior parte delle aziende dice che meno della metà dei propri team usa Agile.

L’aspetto interessante è che l’81% degli intervistati dicono che i loro team non sono co-locati ma lavorano da remoto. Questo dato è antecedente l’evento corona virus, quindi ci fa capire come la stessa agilità sta cambiando lasciando spazio a chi crede che la presenza non sia sempre necessaria.

Un altro aspetto interessante, che spesso viene richiesto è: come posso misurare il successo della trasformazione di uno o più team verso l’agilità?

Sebbene i KPI varino molto da una realtà aziendale all’altra e possano essere identificati andando ad intervistare direttamente il team, il report ci racconta quanto segue.

Il 58% risponde che il successo viene misurato attraverso la soddisfazione del cliente. Agilità infatti è anche maggior coinvolgimento del team e del cliente che attraverso i review meeting controlla a intervalli di “breve” durata la corrispondenza con le aspettative del cliente. Di seguito abbiamo il business value. Rilasciando spesso chiaramente si arriva prima a rilasciare “valore” e ad avere un ROI (return of investment) che, potenzialmente potrebbe anche autofinanziare il progetto.

Il report delinea anche i tool utilizzati maggiormente dai teams agili, ma vediamo quali sono i principali benefici, secondo gli intervistati, rispetto all’adozione dell’agilità.

Benefici Agili

Cambiamenti nelle priorità di business

Il 70% dei rispondenti al sondaggio attribuisce agli approcci agili la capacità di gestire i change delle priorità di business, del resto sappiamo tutti che le specifiche stile waterfall non sono stabili fino alla fine del progetto. In Agile il product backlog gestito dal p.o. è lo strumento per governare i cambiamenti nelle priorità di business. Il team poi accoglie questi cambiamenti gestendoli negli sprint.

Avere questa libertà è un grande vantaggio che consente al business dell’azienda di far procedere il progetto secondo piani di breve durata e non lunghi mesi o anni.

Visibilità sul progetto

Non serve il project manager, le informazioni sono appese alla parete o virtualmente. Può sembrare una provocazione ma nei progetti agili ci sono alcuni strumenti che consentono sempre al team di verificare lo stato del progetto. Ci sono poi metriche come il burndown chart e il control chart che aiutano il team ad avere importanti informazioni.

Allineamento It-Business

Il 65% pensa che i progetti agili migliorino la relazione tra it e business.

I progetti infatti seguono un approccio value-driven diversamente da quello dei progetti tradizionali che è plan-driven: ogni iterazione produce un incremento di prodotto autoconsistente e potenzialmente rilasciabile

  • minimizzando sprechi ed attività che non producono valore (priorità basse nel PB)
  • accolgono i cambiamenti come potenziali opportunità per produrre maggiore valore basandosi sulle evoluzioni del mercato e/o sui feedback del cliente
  • prevedono una strettissima e costante collaborazione con il business: il Product Owner è parte del team ed uno dei suoi compiti è fare in modo che il team comprenda i requisiti, condivida la vision e gli obiettivi del progetto
  • il backlogdi prodotto è costantemente prioritizzato: viene prodotto prima ciò che crea più valore

A questo punto è evidente che il team lavora su ciò che davvero genera valore e che conta per tutto il team.

E il Team?

Il morale dei membri del team risulta sensibilmente migliorato per il 61%

  • la possibilità di autogestirsi ed auto-organizzarsi da spazio alla creatività, all’innovazioneed alla possibilità di mettere a frutto la propria esperienza
  • un team cross-funzionale amplifica le possibilità di apprendimentoreciproco da parte dei membri
  • un ritmo sostenibile di lavoroprotegge le persone da eccessivo stress e gli consente di bilanciare lavoro e vita privata aumentandone il benessere
  • il modello di Servant-Leadership, contrapposto allo stile Command-and-Control, consente ai membri del team di accrescere la propria autonomia, l’autostima, l’impegno ed il senso di responsabilità
  • il generale clima di fiduciae rispetto accresce la soddisfazione ed il benessere
  • lo stile di comunicazione trasparentee face-to-face (anche virtuale) accresce la coesione e riduce incomprensioni e conflitti
  • la condivisione di vision ed obiettivi con il cliente accresce motivazione e senso di appartenenza
  • la co-locazione non è più un vincolo.

Tutti questi aspetti creano un “ambiente” fisico, virtuale e di relazione che permette alle persone di lavorare bene. Naturalmente è impossibile averlo se tutta l’azienda, col suo management, non è coinvolta nel processo di trasformazione agile. In caso contrario avremo infatti scrum master che spingono in una direzione e project manager che si intromettono per portare il team su binari tradizionali.

Altri interessanti aspetti vengono evidenziati dal report. Possiamo comunque trarre una conclusione generale, l’agilità si conferma un mindset che funziona, se applicato in modo pervasivo nell’azienda. Quest’ultima, nel management deve accettare un nuovo modo di gestione della leadership che sia “diffuso” e condiviso.

Si va quindi verso una servant leadership oppure una no leadership…?

Riferimenti

State of Agile report 2020

Pubblicato il

Progettazione Agile in tempi di cambiamento…(Parte 3/3)

Loading

Terza e ultima parte del nostro percorso nel mondo della pianificazione Agile con l'aiuto di Mike Cohn e del suo bellissimo libro Agile Estimating and Planning.

Introduzione

Nella seconda parte di questa serie di articoli abbiamo visto perchè la pianificazione nei progetti spesso fallisce.

In quest'ultima parte vedremo come pianificare accettando di convivere, anzi, incoraggiando i cambiamenti che avvengono nel corso del progetto.
Cambiare un piano non significa necessariamente cambiare le date. Forse servirà ma invece magari
scopriamo che alcune funzionalità che dovevamo realizzare non servono più oppure
potremmo introdurre più persone nel team. 

Questo è un primo pensiero di base. Ma ci sono altre tecniche che possiamo utilizzare per modificare la nostra iniziale stima.


Replanning

Un piano di progetto per essere utile deve essere accurato, ma dobbiamo accettare che
piani fatti nelle prime fasi del progetto portino in sé incertezza.
Se vogliamo poter accogliere nuovo requisiti e avere il massimo feedback possibile dal
committente ad ogni iterazione allora è necessario che il nostro piano sia flessibile, che
tutti i partecipanti accettino questa flessibilità e che soprattutto il nostro budget si adegui di
conseguenza sebbene seguendo determinati parametri.
Allo stesso tempo è possibile che i task non corrispondano esattamente alla stima che avevamo
ipotizzato.
Diciamo, per fare un esempio, che il nostro progetto è stimato in story points ed è composto da tre task.

Nel corso della prima iterazione pianifichiamo di realizzare i primi due task ma al termine ci
accorgiamo di non esserci riusciti.
Il task 1 infatti ha occupato tutta l’iterazione.
Che fare?
Convochiamo il team e nel retrospective meeting decidiamo la strategia da seguire.
Per gestire la situazione dobbiamo necessariamente fare replanning ma di cosa? Di quali
storie?
Un modo è identificare le relazioni tra le storie. Se ad esempio la storia 1, quella che era stata sotto-
stimata, ha relazione con la 2 e la 3 , allora meglio rifare la stima di entrambe.
In questo modo possiamo procedere nella prossima iterazione con dati aggiornati e basati
sull’esperienza.
E’ chiaro che ciò che stiamo facendo è spostare la data di fine del progetto,
ma nel contempo stiamo lavorando su dati reali, su stime sempre più accurate e stiamo
anche accogliendo i feedback del committente perché, come ogni progetto Agile che si
rispetti, ad ogni iterazione accogliamo tutte le osservazioni.

 

Buffering

Anche questa è una tecnica usata ovvero tenersi del tempo di buffer nella stima delle attività.
E’ una tecnica usata anche in progetti con una gestione più lineare come il waterfall. Fatto
100 il mio impegno per realizzare una attività, la stimo 120 al fine di tenermi un buffer per
gestire le incertezze.
C’è però una grossa differenza. In waterfall arrivo troppo tardi ad accorgermi di
cambiamenti necessari e richiesti dall’utente. Gestirli potrebbe ritardare ulteriormente e
nessun buffer ci può salvare.

Così come le stime possono essere sbagliate o poco precise, anche il cliente cambia idea,
e non è poco frequente.
Non sempre il cliente chiede cambiamenti che implicano un allungamento dei tempi, a volte rinuncia a
features rendendosi conto che non servono o che era poco attuabili.
Lo può fare se nel corso del progetto ha dei propotipi con cui “giocare”.
Da qui, togliendo feature, emerge la possibilità di recuperare del tempo o di inserire altre
funzionalità, ecco quindi che cambiare non vuol dire necessariamente...peggiorare.

Riassumendo quindi pianificare tutto e con troppo anticipo non ci consente di accogliere l'incertezza che è sempre presente in ogni progetto. Come è già stato delineato in "Un Cono al gusto di incertezza" e in "Se vuoi una garanzia comprati un tostapane" la certezza è una chimera che non fa parte della progettazione. Forzare i progetti entro schemi rigidi vuol dire non renderli antifragili e quindi potenzialmente fragili, delicati come dei bicchieri di cristallo.

Apriamo quindi la mente progettuale ad accettarli al fine di evolvere assieme al progetto accogliendo ogni richiesta di modifica in termini, appunto, evolutivi.

Pubblicato il

Progettazione Agile in tempi di cambiamento…(Parte 2/3)

Loading

Dopo aver visto, nella prima parte di questa serie di tre articoli, la necessità di pianificare vedremo in questo secondo episodio perchè la pianificazione fallisce.

Introduzione

Quando si mollano gli ormeggi uno non va a Capraia ma parte per Capraia.
"Andare a"  o "Partire per" sono due concetti che sembrano simili ma profondamente
diversi... (cit Marco Viganò: insegnante di vela, skipper, navigatore, imprenditore)

Partiamo da qui per riassumere i principali motivi, secondo Mike Cohn, per i quali la
pianificazione nei progetti fallisce:

  •  perché ragioniamo per attività
  •  perché i ritardi si accumulano e le attività non sono indipendenti
  •  il multitasking è dannoso
  •  ignoriamo l’incertezza
  •  le stime diventano “impegni

Ragionare per Attività

Nell’approccio tradizionale alla gestione dei progetti l’organizzazione e la suddivisione del
lavoro è fatto per attività anziché per feature, facciamo un esempio. In ambito IT una
attività può essere lo sviluppo di tutto il supporto per memorizzare i dati del back end, ad esempio
implementazione del database in cui memorizzare i dati. Al termine di questa attività non
potremo comunque dimostrare nulla all’utente perché la parte applicativa: le interfacce, le
pagine del sito, non sono ancora pronte. Quando verranno completate andremo dal nostro
committente per fare una prima demo e quasi sicuramente verremo “rimbalzati” con
alcune segnalazioni. Accogliere questi feedback può voler dire non solo modificare le
pagine del sito, ma anche scendere a livello di db e modificarne la struttura con tempi e
costi notevoli.
Se invece avessimo sviluppato la feature per memorizzare i dati di login e password,
avremmo contenuto i tempi per arrivare al primo rilascio senza sviluppare strutture non
necessarie e passibili di modifiche.

I ritardi si accumulano

Legge di Parkinson:
Il lavoro si espande fino a occupare tutto il tempo disponibile; più è il tempo e più il lavoro
sembra importante e impegnativo
Questo è vero in media, poi certamente ci sono eccezioni.
Prendersi tutto lo slot di tempo disponibile per quell’attività vuol dire che se sono in ritardo
non ho un buffer per espandermi ma finirò a passare il ritardo all’attività successiva. Inoltre
ragionando come detto per attività, vediamo spesso che queste non sono indipendenti fra
loro. Lavorare per feature limita questa dipendenza e isola i ritardi.

Il multitasking

Un falso mito. Per anni abbiamo pensato che svolgere attività in parallelo fosse
vantaggioso. In realtà è stato dimostrato come occuparsi di due task in parallelo aumenta i
tempi. Bisogna infatti considerare il tempo di switch per passare da un contesto di un task
all’altro. In alcuni ambiti e situazioni non sono immediati. Se devo riprendere un lavoro
complesso che ho abbandonato qualche giorno fa, può essere necessaria qualche ora
prima di ridiventare operativo.

Inoltre lo stesso "penny game" dimostra con un semplice gioco questa teoria. Lo potete vedere in un video su YouTube qui oppure descritto in tutti i suoi dettagli su Mokabyte.
In sostanza il multitasking costa energie mentali e psicofisiche, non produce benessere
per la persona, anzi, aumenta lo stress.

Ignorare l’incertezza

Pensiamo che una volta scritte le specifiche funzionali, fatta la stima , ottenuto e approvato
il budget, il progetto partirà e sarà stabile fino alla fine. Ma inevitabilmente le idee
cambiano, il committente ci darà nuove specifiche, incontreremo problemi tecnici e
gestionali (una persona si licenzia e va sostituita). In sostanza la differenza, come scritto
nella citazione iniziale di Marco Viganò tra partire per e andare a.
L’incertezza va prevista, accolta e ne va fatto un elemento che ci rinforza.

Le stime

Se io stimo un lavoro 5 giorni lavorativi ecco come verrà percepito.
Da me: ho detto 5 giorni quindi diciamo che in base al resto delle attività che ho da fare,
tra due settimane potrò rilasciarlo.
Dal cliente (lo stesso che mi aveva già assegnato altri task che non considera possano
occuparmi tempo…): mi ha detto 5 giorni, siamo a lunedì, quindi per venerdì ho tutto.
Una stima porta in sé un concetto di “probabilità” e quindi di incertezza. Non può essere
considerata come un commitment.

Quindi come possiamo pianificare e raggiungere delle stime in modalità Agile? Lo vedremo nell'ultima parte di questa serie di articoli.

Pubblicato il

Imprevisti e Gestione del Proprio Tempo

Loading

Come Organizzo la Giornata

In questo periodo molti di noi lavorano da casa a causa delle disposizioni governative in merito alla situazione sanitaria.

La nostra quotidianità cambia radicalmente soprattutto se abbiamo figli.

In questo articolo propongo l’uso di tecniche spesso utilizzate nella gestione dei progetti con modalità Agile .

Prima delle restrizioni…

Probabilmente la tua vita era scandita da una intensa giornata di lavoro, i bambini da gestire in parte tu e in parte le baby sitter, la spesa, la cena, le attività sportive tue e di tuo figlio. Le cose si complicano per chi ha più figli o per chi li gestisce da solo/sola. Hai comunque trovato una “quadra” per la tua settimana anche se la gestione dell’imprevisto, che c’è sempre, crea non poca ansia...

Dopo le restrizioni

Arriva l’imprevisto. Uno bello grosso in questo caso.  Sebbene arrivato gradualmente, chiusura scuole, smart working e poi chissà, la domanda che tutti si fanno è:

Oddio e adesso come gestisco tutte le mie attività?

Improvvisamente ci troviamo con una serie di attività annullate, altre da gestire totalmente, ed una quotidianità da inventare, tutto in poco tempo e senza sapere se funzionerà.

Aiuto come faccio?

Anzitutto pensiamo che qualsiasi soluzione trovata non è scolpita nella pietra e quindi ben vengano aggiustamenti in corso d’opera accogliendo anche i cambiamenti, sia quello appena avvenuto che i futuri.

I cambiamenti, soprattutto quelli radicali, ci fanno cambiare a nostra volta e ci obbligano ad adottare forme pensiero e azioni che non fanno parte della nostra precedente quotidianità.

Anche se la nostra mente tende ad aver paura del nuovo e a auto proteggersi, come descrivo nell'articolo Le Neuroscienze e il cambiamento.

Bisogna attivare quindi una certa “Agilità mentale” un mindset Agile che ci aiuti a riorganizzare il momento e a modificarlo in continuazione, in base alle necessità. Noi siamo i protagonisti di questo cambiamento Agile, noi e tutte le persone coinvolte (es i nostri figli) che vanno messe opportunamente al corrente creando un team.

In Pratica

Partiamo dal giorno 1.

Oggi e per i prossimi giorni cambia tutto. Tu sei quello che viene definito il product owner e il tuo obiettivo è scrivere su un bel foglio di carta l’elenco di tutte le attività relative a questa settimana. Ma proprio tutte? Sì!

Quando hai terminato inizia, se possibile a mettere di fianco a ciascuna il tempo che impiegherai a farla e anche la priorità. Ad esempio seguire tuo figlio che fa i compiti in remoto con l’insegnante potrebbe avere priorità massima e una durata di due ore ogni giorno. Dove non hai dati precisi prova a stimare.

Inizia il gioco

Eh sì perché va preso un po' come un gioco anche per alleggerire la situazione.

Quando hai terminato l’attività precedente ovvero hai realizzato il tuo Product backlog (PB) rimane da “spalmare” le attività sui vari giorni...eh già ma così qualcosa non torna. Se io pianifico tutta la settimana e poi succede qualcosa martedì, cosa ho risolto? Nulla!

Infatti procediamo in un altro modo

Sprint!

Non Spritz! Ma Sprint. Dobbiamo realizzare la nostra lista di attività, chiamata anche Sprint Backlog per il primo giorno della settimana.

Scegliamo ovviamente le attività con priorità più alta, si ma quante?

Dobbiamo sceglierne tante quanto è il nostro tempo a disposizione o meglio, un po' meno del tempo a disposizione per sicurezza.

Una volta scelte partiamo finalmente con la realizzazione di queste attività, una dopo l’altra secondo le priorità che ci siamo dati.

Al termine della giornata facciamo un piccolo review. Capiamo quali attività abbiamo fatto, quali non siamo riusciti a portare a termine. La prossima giornata ne potremmo fare di più o meglio diminuire? Delle restanti attività settimanali da fare, quelle presenti nel PB, le priorità sono ancora valide? Oppure vanno riviste? E le stime? L’esperienza odierna ci potrebbe portare a rivederle, forse siamo stati ottimisti o al contrario troppo prudenti.

A questo punto ritorniamo a pianificare il prossimo Sprint, ovvero l’elenco di attività che realizzeremo domani. Stiamo in pratica iterando il processo.

Chiaramente ogni imprevisto viene gestito nello Sprint successivo, quindi l’approccio lascia spazio di adattamento di fronte agli imprevisti. Attenzione questo è un passaggio fondamentale…

Resistiamo? No!

Nel nostro processo siamo felici finchè tutto procede bene. Ogni giorno abbiamo il nostro piano di attività e ogni giorno rivalutiamo nella fase di review ciò che abbiamo fatto. Ma che succede di fronte a un imprevisto?

Dovevo fare la spesa e anche portare mio figlio in piscina ma...mi è venuta la febbre!

Resistiamo, mettiamoci qualche giorno in “sospensione” e poi ripartiremo.

NO! Questo no. Non stiamo adattandoci all’imprevisto, stiamo semplicemente resistendo. La resistenza non è altro che un’altra forma di fragilità.

Quindi possiamo, a fronte della nostra febbre annullare lo Sprint che avevamo pianificato e rifarne un altro che tenga conto del nuovo scenario.

Le attività che dovevamo fare ritornano a far parte del Product Backlog per essere pianificate successivamente, non appena ritorneremo operativi.

Intanto facciamone passare avanti altre oppure attiviamoci per costruire una rete di persone che ci possano aiutare in questo momento e nei futuri momenti di crisi.

Riassumendo quindi con questi semplici passi:

  • definire la lista di attività settimanali (PB)

  • definire gli Sprint e i relativi backlog giornalieri

  • fare i review

  • iterare

Possiamo gestire meglio la nostra quotidianità, accogliere i cambiamenti e i cosiddetti "cigni neri" o imprevisti di ogni genere. Il risultato sarà non solo una gestione meno ansiogina ma anche un nuovo modo di organizzarsi e di vivere, siamo cambiati, ci siamo adattati alla nuova situazione.

Pubblicato il

Progettazione Agile in tempi di cambiamento…(Parte 1/3)

Loading

Introduzione

Alcune domande che ho avuto in testa nei miei primi approcci all’Agilità, intesa come modalità di condurre i progetti e lavorando nel settore dell’information technology in stile waterfall, erano: come faccio a gestire un progetto in modalità Agile dovendo gestire anche la pianificazione di budget e di scadenze? In altre parole se l’agilità accetta ed anzi promuove i cambiamenti in quanto fonte di miglioramento, come faccio a gestirmi il piano? Cambiano i tempi di consegna se accetto, anzi promuovo le modifiche in corso d’opera? Per non parlare dei costi.

Potrei anche accettare di non basarmi su un Gantt ma se ho stimato 100 giorni uomo e un costo di qualche centinaio di migliaia di euro, come faccio ad andare dal committente a dirgli che qualcosa è cambiato nella data di rilascio e nei costi?

In questa serie di tre articoli vi proporrò un percorso che ha come tema la pianificazione in ambito progettuale. Nel primo articolo analizzeremo la necessità di pianificare, nel secondo perché la pianificazione fallisce ed infine nel terzo ed ultimo vedremo l’approccio Agile alla pianificazione. Riassumendo come gestire l’incertezza iniziale di alcuni (o forse molti) progetti cambiando approccio.

Perché si pianifica 

Quanto mi costa? Quando me lo consegnerai ? Quando potrò vedere qualcosa? 

Spesso queste domande arrivano in coda al primo incontro col cliente in cui si sta delineando l’opportunità di realizzare un progetto/prodotto/servizio.

Le risposte a queste domande servono per pianificare campagne di marketing, gestire i costi aziendali, organizzare l’eventuale training degli utenti e così via.

Non è sempre possibile dare risposte perché non abbiamo chiaro il contesto o tutti i dettagli necessari. Non è solo importante la vision del progetto ma anche la vision degli stakeholder. In altre parole cosa vogliamo realizzare per loro? Se vogliamo avvicinarci alle loro aspettative dobbiamo quasi sicuramente avanzare a step. Se invece il nostro obiettivo è realizzare un progetto “chiavi in mano” e puntare a consolidare tutti gli step in anticipo, anche perchè non siamo troppo avvezzi ai cambiamenti, allora molto probabilmente avremo una visione degli stakeholder come soggetti che sono quasi fastidiosi nell’ambito del progetto. Gli stakeholder introducono cambiamenti, chiariscono in ritardo rispetto all’inizio e quindi alterano i piani.

Già da queste considerazioni si capisce bene il senso del concetto “mindset Agile”. Andare verso l’agilità non è solo organizzare persone e lavoro in modo da cambiare il nome alle riunioni e fare qualche board dove appendere i nostri post-it, bensì è qualcosa di concettualmente più profondo. Le interessantissime testimonianze portate da alcune persone, principalmente HR e It manager nel corso dell’Agile for management forum tenutosi a Milano e organizzato da AgileReloaded lo hanno dimostrato: 

l’agilità è sistemica. 

Sebbene molti abbiano iniziato con un progetto pilota, il progetto per essere sostenuto e per potersi poi diffondere ha bisogno di appoggi da parte di diverse funzioni aziendali. 

Per dirla con un bellissimo concetto espresso da Marquet nel libro Turn the Ship Around, non dobbiamo spostare l’informazione verso “l’alto” (intesa come vertici aziendali) ma portare “l’alto” verso l’informazione. Nell’agilità è proprio questo uno dei passaggi fondamentali. “L’alto” deve andare “in basso” e acquisire le necessarie informazioni per capire le criticità e per vedere come un diverso modo di organizzare il lavoro può migliorare il processo e la vita stessa dei dipendenti. 

Quando il piano sfugge

Recentemente mi sono trovato a parlare con il mio istruttore di vela e amico (M.V. metto solo le iniziali per rispettare la sua privacy), ottimo velista, imprenditore e skipper. Mi chiedeva cosa fosse l’agilità e scrum. Nello spiegarglielo (spero chiaramente) ho fatto spesso riferimento al suo mondo professionale: le barche a vela e la nautica.

Progettare in modo Agile vuol dire accettare di andare a vela. Conosco il tuo porto di arrivo ma quasi mai lo puoi raggiungere con una rotta diretta, se ho il vento contro dovrò “bordeggiare”, vedi figura.

Andatura di “bolina” di una barca a vela

Bordeggiare vuol dire adattarsi ai cambiamenti del vento, risalire le difficoltà, con una modalità antifragile piuttosto che robusta.

Sempre per rimanere in un contesto nautico, quanto impiega una barca a vela per raggiungere l’isola al largo delle coste dalle quali siamo partiti? Possiamo fare una stima certo, considerando il vento che probabilmente ci sarà, ma dovremmo anche considerare la corrente, già più difficile da calcolare. Quindi come facciamo a capire dopo quanto tempo arriveremo?

Stimiamo il percorso e accettiamo di avere una stima non totalmente precisa, iniziamo a percorrerne una parte e poi rifacciamo la stima per il percorso rimanente. Reiteriamo questo procedimento fino alla fine ad intervalli regolari. Questo è sinteticamente l’approccio che possiamo seguire ma, comandante dell’imbarcazione, equipaggio e persone che ci attendono a terra devono tutti essere consapevoli della modalità con la quale stiamo conducendo il nostro viaggio altrimenti andremo a creare delle false aspettative rispetto all’orario di arrivo.

Nell’accezione Agile di progettazione i cambiamenti sono i benvenuti. Naturalmente non è il solo principio da seguire, ma quello che vorrei qui mettere in evidenza. Se i cambiamenti sono i benvenuti e se i clienti sono sempre da soddisfare allora non sarebbe più facile lavorare day-by-day senza piani? Non avremmo l’assillo delle deadline, dei release plan, la velocity, gli sprint e quant’altro.

Chi ha lavorato con questa modalità sa, senza altro aggiungere, che lavorare così è una vera tortura. Alcuni addirittura si spingono a sostenere che non ci sono altre possibilità. 

Purtroppo a volte hanno ragione ed in contesti in cui gli stakeholder non sono in grado di formulare le proprie esigenze e il business dell’azienda è confuso non è facile pianificare e progettare. Malgrado queste premesse rimane costante domanda che tutti noi progettisti, PM, Agilisti e quant’altro temiamo:

“Ma quanto mi costa e quando me lo consegni?”

Sempre per cercare dei parallelismi credo che nessuno vada in concessionaria chiedendo: ”Vorrei un’auto che sia comoda da guidare in città e anche per lunghi viaggi con un pò di optional carini e utili e che trasporti un pò di persone. Quanto mi costa e per quando sarebbe pronta?”

Nella seconda parte di questo articolo risponderemo a queste domande.

Pubblicato il

Un Cono al gusto di Incertezza

Loading

L' incertezza

Il cono di incertezza descrive l'evoluzione del grado di incertezza di un progetto, ma è utilizzabile anche nei percorsi di crescita professionale delle risorse umane così come in ambiti di vita quotidiana.

Risultato immagini per cone of uncertainty

Osservando questo grafico si nota come all'inizio l'incertezza è elevata per poi convergere fino ad esaurirsi. L'alto valore iniziale è dovuto a vari fattori quali: idee poco chiare da parte di stakeholder, specifiche e piani non ben definiti.

Il "cono" è stato rielaborato da Steve McConnell sulla base del lavoro di un esperto di ingegneria del software: Barry Boehm nel 1981. La curva mostra sull'asse orizzontale il tempo mentre l’asse verticale rappresenta il margine di errore che si presenta nelle stime. Tale margine solitamente si riduce notevolmente dopo un terzo del tempo trascorso dall’avvio del progetto.

Applicazioni

Lo vediamo anche nella vita quotidiana. E' praticamente impossibile avere un percorso certo nell'implementazione di una soluzione di un problema complesso. Avanzando ogni elemento si chiarisce. Ma non era, con un pò di sforzo, possibile chiarire i dettagli in una fase primordiale del nostro percorso? 

La risposta è...no!

Anche perchè alcune decisioni rispetto alla nostra soluzione possono esserci chiare solo in fase avanzata e anche grazie al lavoro fatto fino a quel momento. L'unica cosa chiara è l'obiettivo che però può essere raggiunto attraverso diversi percorsi.

Anche nell'ambito delle risorse umane, volendo approcciare un metodo per fare crescere professionalmente una persona, non possiamo pianificare ogni parte del suo percorso senza vedere passo passo come reagisce e, eventualmente, aggiustando il tiro.

Agile pensaci tu

Il mindset Agile ci aiuta e grazie alle sue fase iterative (ad es: Sprint) ci consente di implementare le fasi più "importanti" del nostro progetto per poi valutare ciò che abbiamo fatto e ciò che ancora dobbiamo fare. Ad ogni fase l'incertezza diminuisce e la strada verso il nostro obiettivo si assottiglia fino a diventare un piccolo sentiero. Se ciò non accade il progetto o il nostro percorso rimane in una nube di incertezza e procede con fatica con ricicli sempre più dispendiosi.

Pubblicato il

Progettazione Digitale e Pensiero Sistemico: la mente digitale al servizio delle donne

Loading

Si parla tanto di approccio manageriale Agile e di organizzazioni orizzontali, in cui l’innovazione è costante e i cambiamenti si adattano a tutto il sistema attraverso un processo di apprendimento continuo.
L’obiettivo del lavoro agile è cambiare il punto di vista sulla sequenzialità delle azioni da intraprendere per raggiungere gli obiettivi di progetto e sul coinvolgimento in ogni fase di tutti gli attori. Proviamo a pensare ad una giornata-tipo piena di obiettivi da realizzare in cui è difficile delegare pienamente alcune fasi ed è troppo tenerle in carico tutte.


Il problema non è solo attribuire correttamente le priorità o delegare efficacemente, ma è cogliere in
un’ottica sistemica il processo organizzativo ed efficientarlo secondo logiche gestite dagli stessi attori.
Una delle tecniche più utilizzate è il metodo Scrum che consente di procedere per fasi di durata costante e utilizzare il feedback come leva per l’evoluzione dei progetti, tenendo sempre aggiornati tutti gli attori del processo.
Questo consente alle persone coinvolte di esprimere il proprio talento e le proprie capacità piuttosto che
essere controllate.
I team del lavoro Agile (e pensiamo ad ogni forma di organizzazione dalla famiglia, alle associazioni,
all’azienda) si autogestiscono, facendo da manager a sé stessi e auto-organizzando le proprie attività.
E in questo il potenziale femminile può essere molto ben utilizzato.
Il corso si propone di coinvolgere in chiave esperienziale i partecipanti fornendo strumenti pratici in grado di creare consapevolezza e di trasformare i comportamenti.

Destinatarie

Il corso di rivolge a Manager di linea, di staff e di progetto di tutte le funzioni aziendali, ma anche a
tutte le donne che operano in azienda a vari livelli.

Come

Le partecipanti impareranno a:
• Capire l’urgenza del cambiamento
• Acquisire un mind-set agile
• Organizzare il lavoro e le attività dimezzando i tempi e aumentando la leadership di sé stessi
• Prendere consapevolezza dei propri schemi mentali
• Trasformare i comportamenti in azioni positive

Per altre informazioni ed iscrizioni scaricate la locandina del corso sul sito di Human-Acedamy. Il corso si terrà a Milano.

Chi

Il corso sarà tenuto in co-docenza dalla Dott.ssa Rossella Cardinale e da me.

Rossella Cardinale è direttrice scientifica  del Progetto Connessioni (di Human Academy), di cui questo corso fa parte. Rossella, autrice del blog AllenaiPensieri,  è facilitatrice formata alla Pratica collaborativa  e socia dell’AIADC - Associazione Italiana Professionisti Collaborativi. Fa parte di una rete di formatori che offrono servizi alle aziende sul tema dell'intelligenza emotiva e Coordina per AIAS - Confcommercio (Associazione Italiana ambiente e sicurezza) l’Osservatorio “Donne, innovazione e sostenibilità professionale”.
È Professionale Counselor di formazione psicosintetica iscritta al C.N.C.P. e collabora con l’Istituto di psicosintesi di Milano, coordinando gli “Aperitivi letterari”, conferenze sui temi della crescita personale.
Con l'obiettivo di integrare il lavoro su corpo e mente, pratica e insegna Hatha yoga e Pranayama.

Pubblicato il

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