Pubblicato il

Come conquistare i propri sogni in un salto quantico

Loading

La conoscete la storia dei due topolini e del deposito di formaggio all’interno di un labirinto di S. Johnson?

E’ una bellissima storia e in fondo a questo articolo troverete anche il link per visualizzarla su YouTube. 

In questa storia vi riconoscerete...ve la racconto in modo sintetico.

In un labirinto vivevano due topolini: Nasofino e Trottolino e due omini: Tentenna e Ridolino.

I quattro personaggi avevano trovato un deposito di formaggio che dava loro nutrimento.

Ogni giorno i due omini andavano a trovare l’oggetto che dava loro la felicità e se ne nutrivano. I topi facevano la stessa cosa ma...esploravano anche altre parti del labirinto coscienti del fatto che il formaggio sarebbe, prima o poi, finito. Gli omini, col passare del tempo, andavano al deposito con sempre meno entusiasmo, erano certi di trovare il formaggio quindi non avevano molti stimoli di conquista.

In questi primi passaggi possiamo ritrovarci con la nostra vita. Le nostre abitudini ci portano a fare sempre la stessa strada per recarci nei posti in cui dobbiamo andare (es il lavoro) o in cui vogliamo andare. Diventiamo comodi siamo certi della nostra routine di cui ci lamentiamo ma che ci dà sicurezze.

Per Ridolino, il formaggio significava sentirsi al sicuro, farsi un giorno una bella famiglia ed andare a vivere nel posto dei suoi sogni. Per Tentenna, il formaggio rappresentava invece lo strumento per una bellissima carriera, avere schiere di sottoposti e possedere una casa sconfinata con immensa vista mare.

Improvvisamente, ma forse neanche tanto, il formaggio finì!

I due omini rimasero sbalorditi e iniziarono a rattristarsi, per poi cedere a preoccupazione e a sconforto, cercando, come si fa spesso, di identificare qualcuno o qualcosa a cui dare la colpa della situazione.

Anziché mettersi alla ricerca di un altro deposito, tornarono in quello vuoto ogni giorno, con l’idea che forse sarebbe cambiato qualcosa ma riuscendo a capire una cosa fondamentale: più dai importanza al tuo formaggio più ne vuoi avere.

Intanto gli altri due topolini avevano già scovato il nuovo deposito... Non appena il formaggio era finito, infatti, si erano messi alla ricerca, seguendo il loro istinto, liberi da ogni condizionamento razionale.

Dopo qualche giorno Ridolino si stufò di fare le stesse cose: tornare al deposito vuoto e arrabbiarsi per l’assenza di formaggio. Lamentarsi della propria condizione ma non fare nulla per cambiarla.

Anche questo dovrebbe risuonare con noi non trovate?

Ridolino capì che talvolta le cose cambiano e non tornano più le stesse, che il nuovo formaggio si sarebbe trovato altrove e che se non cambi...rischi di scomparire.

Vogliamo fare questa fine? Rimanere tranquilli nella nostra comfort zone aspettando che il nostro formaggio ci venga portato? Accusare gli altri o le circostanze se siamo ancora qui anziché andare verso i nostri sogni?

Ridolino si immaginava altrove e già l'idea lo metteva nuovamente di buon umore mentre Tentenna utilizzava tutte le sue energie per capire chi avesse potuto spostare il suo formaggio! Era anche certo che prima o poi sarebbe tornato tutto come prima!

Ridolino decise che il momento era giunto, ma aveva paura a pensare di inoltrarsi da solo nel labirinto. Infatti Tentenna non ne voleva proprio sapere di andarsene, era convinto che qualcosa sarebbe cambiato.

Per farsi coraggio Ridolino scrisse una frase "che cosa fareste se non aveste paura?”

Scrivendo questa frase Ridolino aveva fatto il suo "salto quantico", ma ancora non se ne era accorto.

Ridolino intraprese il suo viaggio, dapprima titubante poi man mano che avanzava sentiva in lui sempre più energie, non ne capiva il motivo! Del resto era a digiuno da tanti giorni.

Stava rendendosi conto del suo salto...e scriveva frasi sui muri del labirinto mentre camminava, frasi come "annusa spesso il formaggio, così ti accorgi se diventa vecchio", "seguire una direzione nuova, aiuta a trovare un formaggio nuovo".

Poi ci prese gusto.. e su altri muri scrisse: "quando superi le tue paure ti senti libero", "se immagini di gustare il nuovo formaggio già prima di trovarlo, scoprirai la via giusta per conquistarlo".

Queste frasi (veri  propri riti) non solo gli davano coraggio ed energia ma dimostravano che Ridolino si era lasciato il passato alle spalle, aveva svoltato, era in contatto col suo presente per dirigersi verso i propri sogni! Trovare nuovo formaggio.

Ogni tanto sulla strada incontrava piccole sorprese, pezzetti di formaggio che gli facevano capire si essere nella direzione giusta

Finchè un giorno non arriva al nuovo deposito, ancora più ricco di formaggio.

Ridolino torna dal suo compagno Tentenna per convincerlo ad andare con lui, ma Tentenna è convinto che il nuovo formaggio non gli piacerà, lui vuole quello vecchio, il passato. E' irremovibile.

La storia finisce così, Risolino torna al deposito e dopo qualche giorno sente dei passi ...forse Tentenna aveva cambiato idea…

Questa è la fine della storia o, come dice l’autore, un nuovo inizio...

Mi pare che la storia sia molto autoesplicativa. Dare la colpa agli altri, trovare cause esterne a noi sono tratti caratteristici della crisi in cui ci troviamo. Lo stesso Peter Senge delinea queste tra le cause che portano a rimanere ancorati alla nostra situazione.

Cambiando invece atteggiamento, possibile solo quando ci si lascia alle spalle davvero il passato, possiamo dirigerci verso i nostri sogni.

Non occorre sapere la strada!!!

Ridolino non la sa. Ma scrive che se ti immagini la tua meta allora scoprirai la strada.

Immaginati il tuo sogno, assaporalo, vedilo con la mente e disegnalo se vuoi. Già così le energie inizieranno a crescere per fare il tuo viaggio.

Ogni giorno cambia qualcosa nel tuo stile di vita, i percorsi che fai e come li fai.

Stai attento ai piccoli segnali che ti possono arrivare per farti capire se sei sulla giusta strada.

Dai modo al sogno di realizzarsi e trovalo, spostati con il formaggio una volta che lo hai raggiunto perché ci sarà semrpe qualcuno che te lo sposta

Riferimenti

Who moved my cheese. S. Johnson

La Quinta Disciplina. Peter Senge

 

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

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!

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

Pubblicato il

Una diversa visione del project management, la commistione di framework: agile, lean, devops,kanban

Loading

Abstract

Riorganizzare e cambiare visione vuol dire abbracciare anzitutto una vision “del tutto”,

olistica, dall’alto. Nella gestione dei progetti e quindi delle persone passare da una “non

organizzazione” ad una organizzazione vuol dire scegliere nuove metodologie. Ma quali?

E se volessi unirle, intersecarle è possibile?

In questo articolo provo a dimostrare che è possibile e che alla base di Agile c’è un concetto

non scritto che ci aiuto a non fossilizzarci su regole e metodi come abbiamo fatto per anni

almeno nel mondo IT.

Un caso comune

Nell’ambito del project management e senza scomodare alcun framework, posso

tranquillamente dire, almeno nella mia più che ventennale esperienza, che il modello

waterfall non è l’unico. Esistono altre modalità per gestire un progetto in cui l’unico

prerequisito è avere un’idea iniziale, più o meno chiara, della necessità da parte del cliente.

Uno scenario è il seguente. Il cliente ha una necessità o un’idea che viene inizialmente

discussa assieme ai “tecnici” al fine di estrapolare un’analisi, quasi sempre non scritta.

Chi sono i “tecnici”? Sono gli sviluppatori, che in genere sono anche i tester gli integratori e

coloro che rilasciano il prodotto o servizio. In quest’ambito non sempre esiste una figura di

project manager quindi gli sviluppatori sono gestori e non solo di se stessi e del proprio

lavoro ma anche del proprio flusso: produzione del software, test, integrazione e deploy. Un

esempio di team auto-gestito ma sicuramente non motivato!!

Attenzione a non confondere questa visione come una sorta di system thinking. In questo

caso infatti gli sviluppatori vedono solo il proprio flusso, quello che permette di portare il

proprio task verso il deploy. Interagiscono poco con gli altri membri del team e non hanno

assolutamente idea della vision del progetto. Nessun sviluppatore può realmente

considerarsi responsabile del proprio lavoro perchè non c’è alcuna organizzazione, nessuno

sa su quale task sta lavorando l’altro, non c’è un release plan.

Volendo introdurre dei cambiamenti in questa gestione “non gestita” del progetto, è

obbligatorio affidarsi ad un framework e attenersi totalmente alle sue direttive oppure

possiamo integrare e incrociare tecniche, strumenti, metodologie?

Proverò a rispondere a questa domanda.

La Vision

Vediamo ancora come un progetto non gestito può procedere.

Nel corso dei rilasci il prodotto inizia a prendere forma e naturalmente anche le richieste di

modifica da parte del cliente così come le richieste di correzione bachi. Quasi nulla è

documentato, le richieste sono fatte via mail o al più nel corridoio antistante l’ufficio, se

proprio siamo all’avanguardia abbiamo un timido sistema di ticket tracking, quasi fosse la

panacea in questo marasma.

Le richieste vengono accolte secondo una modalità “ansiolitica”. In pratica lo sviluppatore

porta a termine prima il requisito che lo preoccupa di più o che preoccupa di più il cliente.

Se però è venerdì allora implementerà quello più breve così lunedi non si dovrà ricordare a

che punto era arrivato. Ah! Naturalmente in quest’ultimo caso, pur essendo venerdì, termino

lo sviluppo, faccio qualche test (se ho tempo) e ...rilascio!! In produzione ovviamente!

Ma cosa sto sviluppando? Quale contributo sto dando e dove stiamo andando?

A queste domande non è possibile dare risposta perché non esiste una vision del progetto.

Volendo quindi dare una degna organizzazione al nostro progetto cosa possiamo fare?

Sicuramente dobbiamo evitare di infilarci in un’altra rigidità.

Di fronte a questo scenario è necessario un cambio di visione e di cultura. Quali strumenti ci

vengono incontro?

Una visione sistemica

Siamo in un’ottica di cambiamento. Non vogliamo più gestire i progetti in questo modo,

vogliamo strutturarli. Ma i progetti non hanno di per sé una personalità, non sono persone,

non sono oggetti. Strutturare un progetto vuol quindi dire strutturare le persone e quindi

l’azienda.

Stiamo parlando di cambiare visione.

L’obiettivo è costruire ciò che interessa agli stakeholder ma per farlo bene è necessario che i

componenti del team abbiano una visione olistica.

A tal proposito ci viene in aiuto la storiella dei sei ciechi e dell’elefante, che qui sintetizzo.

Sei persone cieche dalla nascita tentano di capire cosa sia un elefante ovviamente non

avendolo mai conosciuto e visto. Ognuno di loro cerca di farlo attraverso il tatto

concentrandosi chi sulla coda, chi sulla testa, chi sulle zampe, ecc. Siccome ognuno tocca

una parte diversa il risultato saranno sei interpretazioni diverse che non si integreranno fra di

loro. Non si avrà una visione sistemica del tutto e le parti di oggetti descritte, anche molto

bene nel dettaglio, saranno comunque diverse dall’insieme delle parti.

Chi non ha sperimentato queste problematiche in progetti con scarsa organizzazione alzi la

mano!

Cambiare vuol dire passare dall’osservazione (in senso generale del termine) del particolare

a quella del generale ma non nel senso di più “distante da” ma più dall’alto. Una visione

olistica che ci fa comprendere il tutto e dalla quale possiamo partire per creare il nostro

nuovo modello di progetto e di relazione con le persone.

Il Team

Il primo step del cambiamento deve agire sul team. Occorre cambiare passando, come

abbiamo detto, ad una vista più sistemica. Scrum ad esempio consente di cambiare le

abitudini del team introducendo un ritmo, una sequenzialità delle fasi, dei meeting in cui

confrontarsi, delle priorità nei task.

In Scrum il development team ha responsabilità e libertà di decidere come organizzare il

lavoro e come realizzarlo ma sempre in un’ottica condivisa. Il team lavora insieme,

fisicamente nella stessa stanza e attraverso i daily meeting realizza una comunicazione

continua.

L’approccio Scrum prevede inoltre un continuo miglioramento attraverso review e

retrospective meeting. Scrum sfrutta l'impegno del team come agente di cambiamento.

Ma non è sufficiente.

Il Flusso

Occorre lavorare sul flusso, per esempio utilizzando il framework Lean.

I principi Lean si concentrano sul flusso più di ogni altra cosa: i colli di bottiglia nel processo

devono essere rimossi e le attività dispendiose devono essere identificate ed evitate.

Lean si concentra sul processo, sulla visualizzazione del lavoro da fare, l’identificazione

degli sprechi e passa la ownership del flusso al cliente. La produzione infatti è pull: tirata

dalle necessità del cliente. In questo senso è molto utile introdurre Kanban negli stessi

Sprint. Kanban ci aiuta ad avere una visualizzazione del lavoro, dello stato e di chi prenderà

in carico ciascun task.

Abbiamo quindi preso in considerazione due framework Scrum con Kanban e Lean.

Lean ha origine in Giappone presso la Toyota con il nome di Toyota Production System

(TPS). Le sue basi vengono sviluppate da Taiichi Ohno e Shigeo Shingo durante gli anni

’50. Successivamente, negli anni ’90, grazie al libro “The Machine That Changes the World,

Lean Thinking and Lean Solutions” di James Womack and Daniel Jones, viene formalizzato

con il nome di Lean, consentendo alle aziende di adottarlo in modo strutturale.

Agile è decisamente più giovane: la sua origine è databile agli inizi del 2001 quando un pool

di esperti di sviluppo software danno vita al famoso Manifesto, che ne definisce i valori ed i

principi.

E’ possibile però integrare i principi Agile e Lean in modo da avere una commistione di

tecniche e di procedura finalizzate a migliorare la conduzione del nostro progetto?

Nell’IT abbiamo passati lunghi anni ad adottare la metodologia cosiddetta waterfall. Fasi ben

definite, moltissima documentazione, pochi spazi alle modifiche in corso d’opera, tempi

lunghi di rilascio tra un deliverable e l’altro, rilasci complessi. Un framework molto rigido.

Ma anche la “non gestione” di cui ho già parlato è di per sé un framework. Potremmo infatti

codificarne alcuni aspetti e notare come sono ricorrenti tra un progetto e l’altro.

Se proprio vogliamo abbandonare questi modelli è auspicabile adottarne di più duttili, dove

la diversità è ricchezza e la visione olistica del tutto (leggasi progetto o azienda) è un

prerequisito importante.

Lean - Agile

Iniziamo quindi a confrontare e a trovare i punti di contatto tra Scrum e Lean.

In Lean dobbiamo:

● identificare ciò che vale (value) individuare ciò per cui i clienti sono disposti a pagare

un prezzo

● identificare il flusso del valore (value stream): allineare le attività che creano valore

nella giusta sequenza

● far scorrere il flusso del valore (flow): mettere in atto le attività a valore senza

interruzioni

● fare in modo che il flusso sia tirato (pull): fare scorrere il flusso in base alle richieste

del cliente

In Scrum viene creato il Product Backlog da parte del Product Owner. Il backlog è la

rappresentazione tramite user story delle necessità del cliente (Value) che vengono eseguite

secondo priorità (value stream) definite dal PO, che è la “voce” degli stakeholder. Gli item

selezionati dal development team sono quelli ad alta priorità e che hanno tutti i dettagli

necessari (flow). Il flusso è pull infatti nel review meeting le priorità del backlog possono

cambiare a seguito di richieste del PO o degli stakeholder.

In Scrum è inoltre intrinseco identificare ciò che non è importante (waste), si dice infatti “se

non è presente nel product backlog allora non esiste”. Il backlog è realizzato in base alle

reali necessità del cliente.

Il visual management in Scrum è realizzato attraverso l’utilizzo di diverse board in cui tutti i

componenti del team possono aver accesso. Kanban può essere integrato in Scrum

portando un ulteriore vantaggio.

Il dev team (al massimo di 9 persone secondo le direttive Scrum) è composto da persone

cross-funzionali, che lavorano fisicamente insieme, che stanno insieme per un lungo periodo

al fine di consolidare la conoscenza reciproca. Insomma un feature team in grado di portare

a termine, ad esempio, il task di assemblaggio dell’elefante. Nel team avremo le persone

specializzate nelle gambe, quelle esperte con la testa, quelle esperte di coda e così via e

naturalmente gli esperti di integrazione e test.

Il team è considerato un tutt’uno e come tale, nel suo complesso, ha tutte le skills necessarie

a portare a termine il proprio lavoro, è un team auto-organizzato e che ha come focus

massimizzare il valore per il cliente e non il numero di linee di codice prodotte da ciascun

membro.

Lean – Agile - Devops

In Scrum il rilascio avviene al termine di uno Sprint e dopo lo sprint review meeting.

E’ possibile integrare tecniche Devops per massimizzare i rilasci e ottimizzare il valore per

gli stakeholder, fermo restando che un task, prima di essere rilasciato, deve soddisfare i

done criteria e i criteri di accettazione. Lo sprint review infatti è un modo o un’opportunità per

avere il feedback degli stakeholder ma non vieta i rilasci anticipati. Oltretutto rilasci ed

integrazione continui facilitano la correzione di eventuali comportamenti che non soddisfano

il cliente.

Conclusione

Nel mondo della musica esiste una parola che mi è sempre piaciuta: patchanka.

In italiano si pronuncia pacianca. Non se ne conosce l’etimo certo ma si può interpretare

come un genere musicale caratterizzato da una commistione di stili musicali diversi, che

rimandano a punk, ska, reggae, rock, funk, rap e molto altro.

Ho esordito in questo articolo dicendo che per migliorare ed uscire da disorganizzazione o,

da eccessiva organizzazione, è opportuno abbracciare un pensiero sistemico, olistico e più

generale. La visione del tutto, termine sempre più presente anche in altre discipline

esoteriche e nella fisica quantistica.

Non pensiamo alle singole parti ma al tutto...

Un ingegnere fisico, ricercatore, e autore di numerosi libri e seminari, Vittorio Marchi, tra i

suoi illuminanti pensieri parlava proprio di questo concetto che provo a riportarvi con parole

mie. Se io prendo un bicchiere d’acqua dal mare, posso dire che ho ottenuto qualcosa di

diverso? Ovviamente no, è solo un modo diverso di vedere la stessa cosa. E’ quindi solo un

problema di visione, osservando più dall’alto il mare e il contenuto del bicchiere ci

appariranno come la stessa cosa.

La direzione che ho voluto qui delineare è quella della commistione (patchanka) di

framework:

Scrum, Lean e Devops. Non vedere lo Sprint come scolpito nella pietra ma permeabile di

miglioramenti continui anche nella sua stessa definizione.

Ogni cosa evolve in questo nostro universo, anche le metodologie di progetto.

Bibliografia

Numero di Gennaio 2020 di Agile Italian Magazine 

The Beer Game 

Scrum and DevOps 

Lean-Agile-Devops 

La quinta disciplina. Peter Sege

Pubblicato il

Design thinking e vocazione lavorativa

Loading

Si sente sempre più spesso parlare di design thinking.

L’etimologia della parola deriva dal verbo inglese “to design”, inteso come l’intero processo creativo di progettare. Ma è anche il pensare ad un progetto con l’ottica del designer. Se ci guardiamo intorno, tutti gli oggetti che vediamo sono stati progettati da qualcuno. E ogni designer è partito da un problema. Il modo di risolvere i problemi dei designer è diverso da quello degli ingegneri. L’ingegnere fa un’ipotesi e la verifica. Il designer, invece, parte dal problema e cerca la soluzione più confacente creando diversi prototipi da testare sul mercato. Quest’estate ho letto un interessantissimo libro scritto da due americani Bill Burnett & Dave Evans, due veterani della Silicon Valley che insegnano alla Stanford University un percorso formativo, che si chiama, appunto Designing your life. Secondo i due studiosi , possiamo progettare anche la nostra vita lavorativa partendo da questo metodo. Se pensiamo come designer, scopriremo che progettare la nostra vita è costruire qualcosa che non c’è mai stato prima e che potrebbe declinarsi in un’accezione nemmeno immaginabile.

Chi di voi non si è mai posto le seguenti domande?

· Come posso trovare il lavoro che amo?

· Come posso costruire la carriera che mi consenta di vivere bene?

· Come posso bilanciare carriera e vita personale?

· Come posso fare qualcosa di veramente diverso?

Disegnare un nuovo scenario lavorativo è un percorso che parte dalla comprensione profonda di ciò che ci piace fare unito alla consapevolezza di ciò che sappiamo fare. Non solo. Per disegnare un lavoro su misura per noi dobbiamo apprendere un nuovo modello di pensiero. Per prima cosa occorre adottare alcuni semplici atteggiamenti mentali.

1. Attiva la tua naturale curiosità. Ogni giorno la vita ci mette di fronte a nuove opportunità. Se manteniamo uno sguardo aperto e uno stato d’animo fiducioso, potremo metterci nella condizione di coglierle.

2. Prova cosa nuove. Provare a modificare i nostri ”automatismi” ci aiuta ad attivare nuove parti del cervello.

3. Ridisegna il tuo pensiero. Al giusto problema corrisponde una giusta soluzione.

4. Resta sempre connesso al processo: Non focalizzarti solo sull’obiettivo, conoscere è un processo.

5. Chiedi aiuto: costruisci un processo collaborativo e fai rete con le persone a te vicine.

Nasceranno preziose sinergie.

Il processo di design thinking applicato alla vocazione lavorativa prevede tre step.

Definire il Problema

Per prima cosa devo chiedermi qual è la mia visione lavorativa, cosa rappresenta per me il lavoro e che peso sociale ha. E poi passare all'analisi della mia visione della vita (in cosa credo? Cosa sto facendo? Cosa è giusto o sbagliato per me?) . Posso poi cercare le intersezioni tra le due visioni o gli eventuali punti di conflitto.

Generare Soluzioni

Poiché non possiamo sapere ciò che vogliamo se non analizziamo ciò che potremmo volere, occorre generare il maggior numero di soluzioni possibile con la tecnica del brain-storming.

Più le idee sono pazze, meglio è. Non è detto che la strada da percorrere sia una sola. Dobbiamo ampliare la nostra visuale.

Il lavoro più difficile è quello di sintesi.Una volta raccolte tutte le idee occorre scegliere quelle migliori, per poterle trasformare in azioni concrete per costruire il nostro nuovo scenario lavorativo. Ma da dove vengono le buone scelte e come le riconosciamo?

La parte basale del cervello, la più antica, ci porta a fare le scelte migliori. Gli studi sull’intelligenza emotiva, codificati da Daniel Goleman ci hanno portato a riconoscere la “saggezza delle emozioni”. Le forme di conoscenza intuitive sono solitamente silenziose ed emergono quando non le cerchiamo, ma lasciamo loro lo spazio per emergere.

Validare il Progetto

Come ultimo passo, una volta concepito un progetto concreto lo dobbiamo verificare sul campo, per esempio chiedendoci onestamente se lo vogliamo davvero e se non siamo spinti da credenze distorte o proiezioni (magari derivanti da condizionamenti familiari o sociali).

Possiamo, ad esempio isolare solo un aspetto del nostro progetto e immaginarne in tutti i dettagli un suo possibile sviluppo futuro. Immaginare il futuro è viverlo. Mettere energia in questa operazione di costruzione mentale la vivifica e la rende anche praticamente possibile.

Il processo creativo si nutre, in questo modo, di quell’insieme di azioni e fatti concreti connessi alle idee che li hanno generati, che a loro volta possono generare altre idee.

Non lasciarsi scoraggiare lungo il cammino è il lavoro più difficile: aggiustare il tiro e continuare a progettare... fino a che il nostro progetto ci somiglia veramente!

Trovate questo articolo anche sul mio blog, Allena i Pensieri.

 

Pubblicato il

“If you want a guarantee, buy a toaster”- Clint Eastwood.

Loading

Una delle prime domande, poste dal committente di un progetto, è:

"Quanto ci vuole per realizzare ciò di cui ho bisogno?"

In sostanza, che garanzia mi dai che poi non mi chiederai di più? La risposta è nella famosa frase di Clint Eastwood tratta dal film La Recluta del 1990 che da' il titolo a questo articolo:

"se vuoi una garanzia comprati un tostapane"

Premesso che sarebbe interessante valutare il livello di chiarezza dei requisiti sui quali dobbiamo fornire la stima, a questa domanda non andrebbe

MAI DATA RISPOSTA!

Se infatti diciamo 5 giorni di lavoro nella nostra testa vuol dire, "Dunque 5 giorni di effort ma considerando qualche urgenza e qualche riciclo saranno quasi sicuramente quasi due settimane prima della consegna".

Nella testa del committente invece è:"5 giorni? Ottimo al prossimo SAL (stato avanzamento lavori) tra una settimana la posso vendere come cosa fatta!!"

Ora, a parte la metafora, uno dei motivi per cui le stime spesso "saltano" è che vengono fraintese, diventano dei commitments. La differenza però è che le stime sono intrinsecamente legate ad un concetto di probabilità, i commitments no, sono legate a precise date di consegna.

Importante quindi tenerle distinte e comunicarle con diverse unità di misura.