Tutti gli articoli di Felice Pescatore

Un Leader non è per sempre… meglio non essere Chief di se stessi

Facebooktwittergoogle_plusredditlinkedin

Devo ammetterlo: non riesco a trattenermi dal sospirare ogni qual volta, in una organizzazione che si ispira all’Agile, incontro qualcuno che aggiunge ai ruoli specifici il suffisso “Chief”, trasformando di fatto quel ruolo in una posizione di implicito comando.
Se ho la fortuna di lavorare con persone che amano mettersi in gioco, e sono predisposte nello sfruttare l’ironia come strumento di crescita, spesso scherzo evidenziando come “Chief” mi ricordi il noto detersivo,

cif spruzzatore

e di come, tale suffisso, potrebbe indicare, in chiave Lean (DevOps), una persona che ispirandosi alle 5S e al concetto di Servant Leader, si occupi di pulire la scrivania dei propri colleghi per aiutarli a migliorare la propria organizzazione locale. Di certo non è il “capo”!

poster 5s leanproducts

Le 5S di Lean

Al di la del “suffisso” (che potrebbe essere anche “chief”, vista l’implicita accettazione che ormai gli si associa), è innegabile che una visione complessiva di un’azienda in chiave Lean/Agile richieda l’aggiunta di diversi ruoli di coordinamento, ma la loro “istituzione”, se avviene a freddo e senza coinvolgimento dal basso, rischia di trasformarsi in una nuova piramide organizzativain cui c’è un “capo” che da degli “ordini” espliciti ai subalterni, piuttosto che un Leaderin grado di ascoltare, risolvere le problematiche e guidare, quando necessario, le Persone con autorevolezza e raramente (se dicessi “mai” sarei poco realista) con autorità.

La questione, chiaramente, è riuscire a coltivare delle Persone che sviluppino le caratteristiche primarie di un Leader, riassunte nell’esplicita infografica di Alessandro Ferrari, andando al di là del titolo assegnato e dell’atteggiamento di aver raggiunto una “posizione” di comando sugli altri.

leader infografica

Un’azienda che ha la bravura, e un pizzico di fortuna, di far crescere i propri Leader, non ha bisogno di assegnargli titoli che richiamino il “comando”, perché queste Persone sono implicitamente riconosciute al suo interno come “trascinatori”, contemplando il fatto che ogni membro dell’organizzazione può diventare Leader in qualsiasi momento, catalizzando l’attenzione dei propri colleghi.  

Ciò, ovviamente, implica che un “Leader non è per sempre” solo perché è un “chief”, ma deve guadagnarsi tale riconoscimento giornalmente sul campo per non trasformarsi, nella migliore delle ipotesi, in “chief di se stessi”.

Stay tuned J

Asciughiamo il Lago dei Difetti, aka Lake of Defects

Facebooktwittergoogle_plusredditlinkedin

Build-in Quaility è uno dei principi fondamentali di Lean, base del pillar Jidokadella famosa House of Lean. Il concetto di per sé rasenta il “banale”: ogni prodotto realizzato deve incorporare e abbracciare strutturalmente gli aspetti di qualità. La questione, però, è che il significato specifico di “qualità” e le azioniche concorrono al suo raggiungimento sono elementi tutt’altro che univoci e definibili in modo predefinito e/o predittivo. In fondo, siamo nel modo dei sistemi complessi, dove dobbiamo costantemente validare le nostre assunzioni per trovare la soluzione migliore adatta al prodotto e al contesto. 

Strumentipraticheprocessitoolci consentono di validare gli aspetti realizzativi e funzionali del prodotto, ma essere opportunamente innestatiall’interno del ciclo di sviluppo, dando dignità soprattutto alle Persone che ne sono i veri detentori, operativi e di know-how.

Nel mondo del software è comune associare l’idea di qualità al testing (anche se è un pelino riduttivo) ma spesso non si ha un approccio strutturato relativo, andando a fare “azioni artigianali” che finiscono per concentrarsi soprattutto alla fine delle attività di coding. Paradossalmente, questo modo di procedere genera uno dei più grandi Waste (Muda, Sprechi) che si possano incontrare lungo la filiera di Delivery, creando a valle del flusso di lavoro un Lake of Defects in cui i tester devono improvvisarsi sommozzatoriper poter individuare le deficienze del nostro prodotto e comunicarle in qualche modo agli sviluppatori. 

lake of defects

Lake of Defects

Si intuisce come tale azione sia estremamente lunga e costosa, aumentando notevolmente il Lead Time (che, lo ricordiamo, è il tempo totale di realizzazione di una funzionalità, da quando viene inserita nel Product Backlog a quando viene rilasciata) e diminuisce la capacità di avere feedback rapidi il più vicino possibile la cellula(o team) che fattivamente sta realizzando la specifica attività. 

L’approccio che mi capita spesso di utilizzare per cominciare a “drenare il lago” è quello di introdurre il noto modello della Piramide di Testing(Testing Pyramid, rif Mike Cohn), facendo attenzione sempre ad evidenziare che, appunto, si tratta di un modello e che, in perfetta chiave Agile, lo stesso va contestualizzato e validato operativamente sul campo.

testing pyramid

Testing Pyramid

Lo scopo è quello di spalmareil testing, ma più in generale tutte le attività annesse al raggiungimento dell’obiettivo build-in quality, lungo l’intera filiera di delivery. Si tratta di un approccio fondamentale e portante per avviare una “vera” trasformazione in chiave DevOps

Facciamo un esempio: se non ho un insieme valido di unit testall’atto della Continuous Integration, non sto facendo Continuous Integration (CI), ma semplicemente merge del codice! Ricordo che l’obiettivo della CI è quello di fornire rapidamente un feedback su quanto realizzato, non quello di generare la build!

Con un approccio strutturato alla qualità (o al testing, se preferite leggerlo in tal modo), si riesce ad asciugare il lago, trasformandolo progressivamente in una pozzanghera (Puddle of Defects) e, idealmente, facendolo scomparire del tutto.

puddle of defects

Puddle of Defects

Migliorando costantemente il proprio approccio alla qualità, la necessità di avere un “team di testing” viene tendenzialmente meno e le Persone che prima si comportavano da sommozzatori, possono dedicarsi a portare un reale e costante valore aggiunto, mettendo al centro il cliente in chiave Customer centric.

Stay tuned J

La Teoria della Scarpa a Rovescio

Facebooktwittergoogle_plusredditlinkedin

Più si cresce e più si tende ad amalgamarsi alle regole che tipicamente condizionano il nostro ambienteil nostrostile di vita. Si tratta di un processo che ci accompagna in modo silente, non accorgendoci nemmeno del fatto che esso sia in atto e di come limiti, in modo crescente, la capacità di guardare oltre gli schemi, così come quella di trovare modi ed atteggiamenti che riescano ancora a stupirci in risposta alla condizione di appiattimento generale.

Una metafora che “calza a pennello” è quella dei bambini che provano a camminare con le scarpe dei genitori: incoscientemente, e divertendosi, provano a indossarle in tutti i modi possibili, fin anche mettendola a rovesciorispetto al piede e provare a fare qualche passo.

scarpa rovescio

Ecco la magia! I bambini sperimentano per apprendere, senza nessuno che debba dirglielo o insegnarglielo… è così e basta.

Eppure, più si diventa grandi, meno possiamo mettere la “Scarpa a Rovescio”, non fosse altro che “fisicamente” non riusciamo a farlo: anche se prendessimo una scarpa della taglia doppia rispetto alla nostra, la cosa è probabilmente impossibile.

Riportando la metafora al nostro contesto, ciò significa che più ci amalgamiamoal contesto operativo a cui apparteniamo, più ne diventiamo contaminati, e più diventa difficile provare a guardare fuori dagli schemi.

Assimiliamo un modo di fare che ci porta in una comfort zone, trasformandoci in “pigroni” che provano a galleggiare sulle attività giornaliere, riducendo, se non perdendo del tutto, lo spirito disperimentazione della Scarpa a Rovescio.

Più cadiamo in questo limbo, meno siamo soddisfatti di quanto facciamo e, cosa che spesso sfugge alle organizzazioni, meno facciamo l’interesse per il contesto in cui operiamo: un manager che non sbaglia mai, non prova ad innovare, trovare nuove strade, non si ferma a riflettere, è, con molta probabilità, un cattivo manager che non sta guardando al futuro dell’organizzazione essendo “soffocato” dal quotidiano. Stesso discorso per tecnici, operativi, e tutte gli altri ruoli aziendali che possono venirci in mente.

Ma come reagiamo a questa condizione? Dobbiamo tornare un po’ bambini, andando a riscoprire la soddisfazione intrinseca nello sperimentare, nel porsi fuori dalla propria area di sicurezza, in modo da reinventarsi e reinventare la propria professione e professionalità.

Dobbiamo continuamente rincorrere l’effetto “WOW!”, rilassandoci ed imparando a guardare le questioni da una moltitudine di angolazioni, cercando lo spazio che gli altri ignorano e che ci permetterà di fare la differenza.

effetto wow 

Certo, per fare questo, è necessario che la nostra azienda abbia una cultura orientata alla sperimentazione ed all’apprendimento (la terza via di DevOps e uno dei pilastri di Lean), creando una safety-netin cui muoverci con la certezza che qualsiasi sarà il risultato della nostra azione, avremo comunque raggiunto un risultato apprezzato in quanto tale.

Chiudiamo con una frase resa famosa da Steve Jobs che sembra fatta a pennello: Stay Hungry, Stay Foolish!

Stay tuned J

Il Fattore Tempo dell’Obiettivo Sostenibile

Facebooktwittergoogle_plusredditlinkedin

Nel mondo Agile, il team è praticamente alla base di ogni aspetto operativo, tant’è che uno degli elementi primari che da coach affrontiamo è quello di “creare il team” in quanto “cellula vivente”, non considerando come team singole persone sedute adiacentemente.

Non potrebbe essere altrimenti, visto che questo aspetto è il succo del primo Valore del Manifesto: Persone e Iterazioni, più che Processi e Tool ed è anche il cuore dei movimenti che cercano di guardarne l’evoluzione, come Heart of Agile e Modern Agile, senza dimenticare Lean.

Ma, per quanto non sia mai semplice supportare questo percorso di amalgamazione, le azioni cambiano in funzione anche ad una considerazione profonda rispetto al motivo stesso di esistenza del team: siamo in presenza di un team di mercato (o di prodotto) o un team di progetto?

Per prodotto intendiamo un manufatto che soddisfi un’esigenza di uno o più stakeholder e che richiede un supporto appropriato per poter essere “consumabile” ed evolvibile nel tempo. Per progetto, invece, un’azione limitata nel tempo, sia relativa ad un prodotto che isolata da altri contesti.

SelfOrgTeam

Nel caso del team di mercato, il lavoro sarà proprio quello di creare una squadra orientata a soddisfare i propri clienti, andando così a lavorare sui concetti tanto cari al mondo Agile come: team cross-funzionali, skill t-shaped, comunicazione, collaborazione e così via. In questo caso il Fattore Tempo è legato agli impegni rispetto al mercato e non è un elemento caratterizzante il team.

Nel caso del team di progetto, le dinamiche possono essere completamente differenti. Il caso più articolato è quando il team viene “assemblato” per realizzare una iniziativa isolata, portando al tavolo persone che prima si conoscevano appena (o non si conoscevano affatto) e sono appartenenti anche ad aree organizzative diverse o, addirittura, a fornitori diversi. In questo scenario, il Fattore Tempo scandisce l’esistenza del team, un po’ come nel film Time Out, del 2011, dove la vita delle persone è scandito da un orologio biologico artificiale e ogni azione o acquisto comporta una riduzione del tempo a disposizione, spingendo, dualmente, a sacrificare il superfluo per aumentare o mantenere stabile quello residuo.

timeout film

L’orologio biologico artificiale del film Time Out

Partendo da queste considerazioni, come possiamo aiutare il team, sapendo che ogni azione comporta una riduzione del tempo alla base stessa della sua esistenza? Prima, probabilmente, bisogna fare un passo indietro e chiedersi perché in una tale situazione si voglia adottare un approccio Agile che predilige, come detto, il concetto di stabilità del team e orientamento alla soddisfazione del cliente, e se le motivazioni sono convincenti (prima di tutto per il Business!), andare ad intervenire in funzione dell’Obiettivo Sostenibile

Provo ad esplicitare questo concetto con un esempio: se so già che il team a fine progetto verrà sciolto, potrei provare a concentrare l’azione di coaching sulle pratiche più tecniche orientate all’aumento della qualità, piuttosto che dedicare il tempo all’adozione di un framework come Scrum. Potrebbe infatti bastare una Kanban-like board, con gli elementi essenziali inerenti alle Storie e alcune metriche annesse, per favorire una maggior comunicazione tra i membri del team, evitando di “consumare” troppo tempo.

Ecco, qui si evidenzia ancora una volta come l’esperienza, la caparbietà e lo spirito di osservazione di un coach possono fare la differenza nel portare l’Agile anche in quei contesti che, a prima vista, sembrano fortemente disfunzionali, evitando di cadere nella trappola di pensare che Agile significhi appendere post-it al muro [cit. Giulio Roggero]!

 

Stay tuned J

L’Ombra Ingombrante del Budget Previsionale

Facebooktwittergoogle_plusredditlinkedin

Quando andiamo a parlare di DevOps “nobile”, ovvero di Lean e del rapporto stretto al Value Stream inteso come la capacità di soddisfare continuamente il cliente con soluzioni consumabili, ci si scontra operativamente con un aspetto di non facile risoluzione: come gestire il budget?

Si tratta di una questione molto articolata e fortemente relazionata all’ambiente di riferimento, ma sicuramente caratterizzata da un concetto fondamentale: il budget non dovrebbe essere un budget di progetto, ma dovrebbe essere associato proprio al value stream.

Questo contribuisce a considerarlo come uno strumento a supporto dell’iniziativa, che deve, quindi, essere in qualche modo dinamicorelazionato alle evidenzeper poter accompagnare l’evoluzione stessa dello stream di valore in funzione di quanto realmente riscontrato. Non deve quindi essere un budget previsionale che “vincola”, piuttosto uno strumento riadattabile che fa propri i valori stessi di Agile ed i principi di Lean.

piggyshadow

Ad intuito dovrebbe essere già evidente come in un mondo complesso è veramente illusorio pensare di poter allocare un budget rigido e pretendere al contempo di definire e derivare puntualmente tutto il resto. Ma se l’intuito non fosse sufficiente, a suffragare questo sentore si trovano anche diversi studi e ricerche (fatti coinvolgendo i CFO e le prime linee interessate) che mostrano come quasi il 90% delle strutture relative non sono soddisfatte degli strumenti e degli approcci attuali al budgeting, mentre più della metà evidenzia come sia sempre più difficile relazionare il budget con gli obiettivi strategici perseguiti e raggiunti.

Essendo il budget estremamente vincolate (e spesso penalizzate), non deve meravigliare come questo aspetto rientri a pieno titolo in quelli interessanti da un’azienda che intraprende il cammino dell’Enterprise Agility e come framework quali SAFeDAcontemplino esplicitamente, seppur con un approccio diverso coerentemente con le relative specificità, tale aspetto, parlando, rispettivamente, di Lean BudgetsFinance.

Senza però doverci legare obbligatoriamente ad un framework di scaling, esistono diversi approcci che provano a sposare una filosofia di “Continuous Budgeting”, tra cui il più popolare è probabilmente Beyond Budgeting, basato su 6 principi e 6 pratiche fondamentali.

beyound budgeting

È interessante notare che, implicitamente, si mette ancora una volta in evidenza come LeadershipManagementsiano due facce della stessa medaglia che possono e devono convivere nell’azione organizzativa.

In generale, questo insieme di principi e pratiche consente di abbattere la rigidità della pianificazione tradizionale, focalizzandosi sull’obiettivo e non sul costo ipotizzato, per l’iniziativa o progetto che sia. Risulta evidente come la capacità di rivedere costantemente il budget impatti in modo diretto sul “contenuto” dell’iniziativa, aumentando l’efficacia e l’importanza di avere un backlog dinamico che consenta di modificarne lo scope, non solo in relazione alle nuove esigenze degli stakeholder, ma anche all’eventuale erosione imprevista delle risorse finanziare disponibili.

Stay tuned J

La burocrazia dei requisiti diluita nella Pila

Facebooktwittergoogle_plusredditlinkedin

Il Product Backlogè molto spesso l’elemento centrale da cui si sviluppano le diverse attività di un team Agile, siano esse di envisioning, pianificazione o relative al lavoro giornaliero.

Si tratta, per quanti non ne avessero dimestichezza, di un elenco verticale delle attività da realizzare, ordinate secondo diversi criteri (il più utilizzato è genericamente per Valore) dall’alto verso il basso: una sorta di pila che contiene tutto quanto necessario realizzare per completare il prodotto.

Ma è davvero così semplice creare un Product Backlog, capire cosa inserirvi e gestirlo adeguatamente in modo che sia anche un “manufatto live” che sostituisca in tutto e per tutto la burocrazia dei requisiti? La risposta è chiaramente no, e le sperimentazioni sulle diverse forme che il Product Backlog può assumere sono continue e spesso fonti di nuove domande.

pbacklog extended

Si pensi ad esempio all’interpretazione del Product Backlog in chiave Disciplined Agile in cui lo stesso deve soddisfare la necessità di creare una “Soluzione Consumabile” e non “Software funzionate”: questo implica che in esso troveremo non solo le iniziative di sviluppo, ma anche tutte le attività aggiuntive (se continuiamo a considerare Core lo sviluppo) che sono necessarie per rendere “consumabile” quel prodotto da parte degli utenti finale. Un esempio per tutti: la creazione del manuale utente.

Inoltre, esiste sempre più la tendenza di non vincolarsi strettamente a forme canoniche per la descrizione delle attività, come ad esempio le User Story(funzionalità orientate all’utente), ma contemplare anche elementi che in qualche modo l’utente non può toccare in modo diretto se non nel complesso del prodotto in quanto sua componente fondamentale. Ad esempio: se si crea un nuovo prodotto da zero, i servizi trasversali come logging security come li esprimo nel backlog? Che priorità hanno? Li lego ad una storia utente, oppure li esplicito per abbracciare i principi di chiarezza e trasparenza insiti nel backlog stesso? Io, generalmente opto per quest’ultima soluzione, lavorando con il PO per trovare la forma corretta di comunicazione relativa con il cliente.

Se andiamo in ottica DevOps (Lean), il Product Backlog non dovrebbe essere più considerato solo espressione del team di sviluppo, ma si dovrebbe guardare il quadro complessivo e includere, quantomeno, le attività annesse al deploy delle funzionalità realizzate. Anche qui un esempio: il product backlog dovrebbe contenere l’attività di creazione degli script per il provisioning delle macchine necessarie all’erogazione dei servizi, fondamentali per supportare fin da subito le attività di testing così come quelle di consolidamento delle pipeline di rilascio.

Anche sulla questione prioritizzazione c’è molto da lavorare: l’ordinamento per Valore utente, per quanto il concetto di Valore non sia di per sé univoco, può diventare semplicistico, non tenendo in conto, ad esempio, la necessità di esplorare tecnicamente alcune caratteristiche che possono rappresentare un forte rischio per il successo dell’iniziativa stessa. In generale è sempre utile avere almeno un ordinamento che si basa sul dualismo Valore-Rischio (value-risk driven) in modo da bilanciare due obiettivi: avere nuovi elementi di cui discutere con l’utente e diminuire il rischio intrinseco di quanto si sta realizzando, aumentandone la confidenza e spostandosi a destra lungo il Cono di Incertezza.

cone of uncertainty

Nella concezione qui evidenziata, il Product Backlog diventa quindi un contenitore live che, rispettando gli specifici criteri di ordinamento, consente di avere costantemente una fotografia di tutto quanto necessario per portare a termine l’iniziativa, evidenziando al contempo le specifiche ownership dei work center (DevOps/Lean) e le possibili criticità, in modo da intervenire prontamente per risolvere.

È sempre interessante sottolineare come dietro uno strumento apparentemente semplice, si celi una “cultura dell’utilizzo” che può essere coltivata solo in seno al team specifico e all’organizzazione di appartenenza, non dimenticando anche le caratteristiche proprie del prodotto che rappresenta.

Stay tuned J

Dalle Stelle alla Sfera Celeste

Facebooktwittergoogle_plusredditlinkedin

Molte delle azioni che si mettono in campo per intraprendere la strada dell’agilità riguardano i team, andando a lavorare su Teamcon la “T” maiuscola, intesi come una cellulain grado di adattarsi e riconfigurarsi per creare Valore.

Questo aspetto è specificamente formalizzato in Lean, relativamente al JIT Pillar, e identificato come Cellular Manufacturing, con l’obiettivo di aumentare la produttività, riducendo il Lead Time grazie alla semplificazione della programmazione, al controllo produzione e alla riduzione delle scorte. Il tutto è reso possibile dalla spinta sulla comunicazionee sul coordinamento.

cellular manufactoring

L’aspetto fondamentale è che il Team lavora su un’attività specifica e lo fa al meglio, tendenzialmente inseguendo lo stato dell’arte, coordinandosi con le cellule a monte e a valle per garantire un flusso costante e sostenibile.

Ma cosa succede se il team è un teamcon la “t” minuscola, ovvero un insieme di Persone che sono sedute vicine, a stento si parlano e che sono impegnati su più progetti contemporaneamente, anche gestendoli in modo esclusivo?

Si tratta di una condizione più comune di quanto si pensi, che rende arduo attuare una trasformazione Agile/Lean (o DevOps), e che non tiene conto di principi ormai universalmente riconosciuti come il costo di uno switch continuoe un ritmo di lavoro sostenibile(entrambi MUDA).

Difficile in queste condizioni, ad esempio, pensare a Scrum, perché: che senso ha fare Scrum se le attività (parlare di Product Backlog in tal caso è un eufemismo!) sono in carico ad una sola persona? Come farebbe il Daily… guardandosi allo specchio?

Scherzi a parte, in alcuni casi è più utile immaginare un percorso progressivo che permetta di inserire elementi di ottimizzazione e cominciare a porre le basi di una cultura orientata alla comunicazione e alla gestione sostenibile delle attività.

Di base può balzare in mente un approccio Kanban-like, ma non bisogna dimenticare che operare in tal modo richiede una forte maturità per non “lasciare indietro” aspetti fondamentali (si pensi al fatto di non fare la retrospettiva perché non si ha tempo), motivo per cui approcci di questo tipo spesso si utilizzano nello scaling… ma qui possiamo avere un problema: posso immaginare di usare Kanban come base e poi “scalare” a qualcosa più simile a Scrum quando aggrego più persone? Ha senso?

Per provare a immaginare un approccio che possa comunque supportare anche gruppi di 2 persone, guardando ad una dinamicità guidata dallo stream di attività legate ad un cliente, stiamo sperimentando quello che ha preso il nome di AgileConstellatione che trovate all’indirizzo agileconstellation.org

celestialsphere bigpicture

Siamo curiosi di avere i vostri feedback, suggerimenti o altro.

Stay tuned J

La congiunzione astrale dell’indipendenza del Verbo

Facebooktwittergoogle_plusredditlinkedin

Qualsiasi trasformazione richiede tre elementi fondamentali: tempobudgetsponsorship. Questo è un dato di fatto a prova di smentita, tant’è che il venir meno di uno di essi compromette fortemente, se non inesorabilmente, le possibilità di successo dell’azione intrapresa.

In particolare, è necessario riflettere molto sulla sponsorshipe capire se essa sia reale opportunistica:

  • la sponsorship è realequando gli sponsor sono i primi ad essere coinvolti nell’azione di trasformazione, calandosu di sé quando si sta sperimentando e accettandodi rimettersi in gioco, consci che il tutto possa portare un reale beneficio all’intera organizzazione. Bisogna essere convinti della necessità del cambiamento, unitamente ad una buona dose di umiltà e capacità di guardarsi intorno per capire se il percorso intrapreso sta portando benefici;
  • la sponsorship è opportunisticaquando non è minimamente sentita, ovvero quando si supporta un cambiamento solo perché “qualcuno lo ho detto o perché tutti lo fanno”. In tal caso si cerca di piegare la stessa ai propri interessi, intervenendo fortemente nelle diverse azioni al fine di plasmarle secondo le proprie necessità e mantenere la propria confort zone, eventualmente appuntandosi una nuova “etichetta” che però non modifica la sostanza. 

Come diceva Tancredi ne “Il Gattopardo”: Se vogliamo che tutto rimanga come è, bisogna che tutto cambi… e quindi bisogna fare molta molta attenzione nel rispondere rapidamente alla condizione che ci vede difronte ad una sponsorship opportunistica. 

lampedusa gattopardo

Purtroppo, è molto difficile riuscire inizialmente ad indentificare la specificità: solo il tempo ci da la possibilità di captarecapireed analizzarei segnali ed i fatti che possono portarci ad avere un’idea in merito. 

Un elemento che però è fortemente indicativo è l’Indipendenza degli Agenti di Trasformazione (o dei Coach se siete in chiave Agile), che devono potersi muovere calando sulle evidenze le azioni che ritengono più consone, dando messaggi chiari che evidenzino sempre quale sia l’obiettivo ideale e quali, invece, sono i compromessi da accettare per cominciare ad innescare il cambiamento e generare miglioramenti.

Guai se i messaggi sono “tarati” sui desideri dello sponsor: in questo caso non stiamo solo dicendo addio al nostro “viaggio”, ma anche alla credibilità stessa dell’approccio che stiamo proponendo. Nessun commento superfluo è ovviamente utile per definire chi si presta a tale azione.

Se si verifica una congiuntura astraleche allinea tutti questi elementi, il risultato ultimo si sintetizza con una frase che purtroppo si sente non di rado: “Agile non funziona!”che di per sé è priva di significato essendo Agile un mindset formato da Valori e Principi e non da processi che invece vanno contestualizzati… …nel modo giusto.

Stay tuned J