Author Archives: Felice Pescatore

Un nuovo orizzonte per l’Agile: conclusioni

Come detto, Modern Agile ed Heart of Agile sono, rispettivamente, le proposte di Kerievski e Cockburn, per un “ritorno alle origini” dell’Agile. Probabilmente nessuna delle due soluzioni diventerà predominate o main stream, ma di certo entrambe portano a riflessioni interessanti.

I Valori ed i Principi Agili sono tutt’oggi attuali, ma, in perfetto stile inspect-and-adapt, è innegabile che bisogna riflettere su come il mondo sia cambiato negli ultimi 16 anni (ricordiamoci che l’Agile Manifesto è stato appunto scritto nel 2001), su come stia cambiando e, di conseguenza, come essi vadano probabilmente “modernizzati”, non fosse altro per le sfide moderne che accompagno lo sviluppo del software.

past future now

Ma Agile guarda ormai al di là del mondo del software, portando a parlare di “Soluzioni Consumabili” e Business Agility, il nuovo cappello sotto cui si sta sviluppando tutto questo.

Concetti come: “People Centric”, “Fast Delivery” ed “Experimentation and Learning”, accompagnano giornalmente lo sviluppo e la creazione di soluzioni innovative, legandole al Business in chiave Value Stream, cosa che ci porta alla contaminazione di Agile con Lean, sempre più comune e i cui confini sono sempre meno marcati. Anche DevOps, per quanto sia una declinazione di Lean applicata allo sviluppo del Software, contribuisce ad accelerare questo processo.

La cosa fondamentale è avere sempre una chiara visione di quali sono le necessità da soddisfare e gli obiettivi da perseguire, andando di volta in volta ad individuare pratiche e principi che possano meglio essere calati nel contesto specifico, misurandone i risultati e prevedendo un pivot laddove le scelte si rilevino insoddisfacenti.

È fondamentale sottolineare che i Valori del Manifesto, al di la della nomenclatura, sono i pilastri dell’intero movimento, ma bisogna riconoscere che la “parte destra” della loro formalizzazione ha sempre creato confusione e miti che negli anni hanno portato a tanti fraintendimenti, e che hanno richiesto richiesto tempo per riportare il treno sulle rotaie.

Probabilmente l’essenza dei Valori resterà tale finché la realizzazione di Soluzioni Innovative dipenderà fortemente da gruppi di persone che lavorano insieme e che mettono al servizio le proprie competenze e la capacità di reagire agli imprevisti.

Stay tuned J

Un nuovo orizzonte per l’Agile: Heart of Agile (pt.3)

Heart of Agile è la proposta di evoluzione, o forse sarebbe meglio dire di “snellimento”, dell’Agile di Alistair Cockburn (tra i firmatari del manifesto stesso), che, come Modern Agile, si focalizza su quattro Elementi principali:

  • Collaborate
  • Deliver
  • Reflect
  • Improve

rappresentati graficamente attraverso una sorta di “diamante”.

heart of agile

Heart of Agile

Esattamente come Kerievsky, Cockburn esplicita che Heart of Agile non è né un framework né una metodologia, ma non riesce a proporre una definizione chiara, affermando che:

“I think I’ll call it ‘Do this: collaborate, deliver, reflect, and improve.’”

contribuendo, così, ad acuire quel grado di confusione di cui parlavamo nel primo post della serie.

L’idea di fondo è però ben rappresentata dal “cuore” al centro del diamante, ovvero dal “Kokoro”, traduzione della parola in giapponese: tornare al cuore dell’Agile, spogliando quest’ultimo degli “orpelli” e delle “decorazioni” che nel corso degli anni hanno distratto dalla sua essenza.

Ognuno dei quattro elementi può essere espanso secondo la filosofia Shu-Ha-Ri, dettagliando le azioni specifiche con un diverso livello di attuazione e padronanza da parte degli utilizzatori.

È così che il diamante visto in precedenza, rappresentativo della fase “Shu”, si espande come segue nella fase “Ha”:

heartofagile expanded

andando ad associare agli Elementi portanti una prima serie di Comportamenti effettivi:

  • Collaborate: Collaboration e Trust
  • Deliver: Deliver for Learning e Deliver for Income
  • Reflect: Reflect for Insights e Reflect for Improvements
  • Improve: Experiment (remember, it’s just an experiment) e Change (actually change)

È importante sottolineare come Cockburn evidenzi che questa non sia l’unica possibile estensione degli Elementi portanti, ma è quella che, nel momento in cui ha dato vita ad Heart of Agile (settembre 2015), meglio rappresentava la sua idea in merito.

Una ulteriore espansione si ha nel momento in cui si passa alla di “Ri

heartofagile expanded ri

Se vi steste chiedendo in che modo Cockburn abbia scelto i diversi elementi ai diversi livelli, sappiate che il tutto ha preso forma partendo da “Ha”, per poi condensare ed estendere tutti gli aspetti relativi e mettere al centro il Kokoro, la cui posizione è dovuta al “Valore nobile da acquisire”, raggiungibile solo dopo la fase di “Ri”, che consente, a chi lo raggiunge, di operare nel senso più nobile dell’Agile.

Heart of Agile è quindi maggiormente focalizzato sul “tornare alle origini” e ritrovare i Valori che hanno ispirato i firmatari del Manifesto Agile, più che preoccuparsi di come renderlo “moderno” e applicabile in seno alla Business Agility.

Per ora ci salutiamo qui, in attesa del prossimo post dove, provando a fare un confronto di merito tra Modern Agile ed Heart of Agile, cercheremo di fare una serie di considerazioni relative.

Stay tuned J

Un nuovo orizzonte per l’Agile: Modern Agile (pt.2)

Nel precedente appuntamento abbiamo cercato di fare luce sull’esigenza, sempre più forte, di ripensare l’essenza stessa dell’Agile, legandola ai nuovi scenari organizzativi e produttivi che si sono strutturati negli ultimi anni.

In sintesi, possiamo evidenziare come la discussione nasca da 3 elementi portanti:

  • l’Agilità appartiene all’Organizzazione nel complesso, e non è esclusivo appannaggio dei team operativi;
  • l’Agilità interessa tutti i settori Produttivi, non solo quello del software;
  • è necessario creare un Mindset chiaro, per dirimere l’enorme confusione che oggi è associata all’Agile.

Come detto, tra i diversi movimenti che si stanno affacciando sulla scena internazionale, due sono quelli capaci di catalizzare maggiormente l’attenzione della Community: Modern Agile ed Heart of Agile. In questo post ci concentreremo sul primo.

Modern Agile (modernagile.org) è l’idea proposta da Joshua Kerievsky, in cui i Valori (ed implicitamente i Principi) del Manifesto Agile vengono riletti con una “connotazione moderna”, frutto del processo di inspect-and-adapt dell’Agile nell’ultimo ventennio, unitamente all’associazione non esplicita/esclusiva al mondo del software.

Modern Agile Wheel

Modern Agile Principle

La cosa da sottolineare è che, a differenza dei framework di Scaling (o di Growing se preferite), il focus è su 4 Principi fondamentali che vanno ad ispirare e guidare l’azione organizzativa e produttiva dell’azienda:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

Caratteristica fondamentale è che tali principi non sono solo indipendenti dal settore di applicazione, ma anche dall’area organizzativa afferente (HR, produzione, progettazione, ecc..).

ma awesomeMake people awesome (Rendere le persone eccezionali).

Il mondo è fatto di Persone, e, organizzativamente parlando, possiamo divederlo in due insiemi: quello su cui si basa la propria organizzazione, e quello a cui essa si rivolge. Attorno a questo secondo insieme ruota oggi il compito nobile dell’organizzazione: non più realizzare prodotti, ma realizzare servizi che possano migliorare o, addirittura, trasformare la vita delle Persone, rendendole “straordinarie”. Il tutto gira intorno alla Customer Satisfaction.

Per raggiungere tale obiettivo, però, il patrimonio interno di Persone deve essere a sua volta “eccezionale”, mettendo ogni singolo individuo nelle migliori condizioni possibili di esprimersi ed essere allineato su obiettivi chiari. Più tali obiettivi sono ambiziosi, più si diventa “straordinari” e più si ottengono innovazioni dirompenti (Kaikaku), supportate dualmente da miglioramenti incrementali che permettono di ottimizzazione le attività nel loro complesso (Kaizen).

kaizen kaikaku

Fintess Change Landscape (Management 3.0)

Molti elementi caratterizzanti questo principio si ritrovano nel lavoro di Kathy Sierra, e in particolare nel suo libro Badass: Making Users Awesome.

ma safetyMake safety a prerequisite (Rendere la sicurezza un prerequisito).

Le Persone che fanno parte dell’organizzazione devono sentirsi al sicuro, rimuovendo la “paura di sbagliare” che tipicamente accompagna le nostre attività professionali.

Sbagliando si impara”; gli errori sono quindi alla base dell’apprendimento e, ancora più importante, sono intrinsecamente legati al cambiamento in modo direttamente proporzionale: quanto più il cambiamento è ambizioso, tanto più il rischio di sbagliare aumenta.

Se la Cultura aziendale è incentrata sulla “ricerca del colpevole”, più che sulla comprensione dei problemi e la creazione di opportune azioni di risoluzione, la possibilità che le Persone siano “incredibili” è veramente remota, perché ognuno cercherà di auto proteggersi, senza assumersi rischi, confinandosi nella propria confort zone.

Le Persone vogliono eccellere, e una Cultura organizzativa basata sulla paura blocca al nascere ogni spinta di innovazione e miglioramento. Come ha affermato Seth GodinPeople aren’t afraid of failure, they’re afraid of blame” [Le Persone non hanno paura di fallire, hanno paura di essere incolpate].

ma experimentExperiment and learn rapidly (Sperimentare e apprendere velocemente).

Nessuna organizzazione può permettersi di “restare immobile”, non guardando oltre l’attuale orizzonte e fornendo soluzioni non adeguate alle aspettative degli utenti.

Essendo le nuove soluzioni sempre più complesse, è fondamentale avere un approccio pragmatico all’innovazione stessa: bisogna sperimentare le proprie ipotesi, validarne l’esito, riflettere e agire di conseguenza.

Si tratta di un “approccio scientifico all’innovazione”, ben presente in tutti quei contesti dove si vuole creare vera innovazione, formalizzato anche grazie a diverse pratiche come il Build-Measure-Learn, di Lean Startup, o Popocorn Flow, che associa il grado di innovazione al numero di esperimenti effettuati.

Per poter procedere in tal senso, è evidente come i precedenti principi debbano essere già radicati ed acquisiti, in modo da poter procedere con serenità ed obbiettività nella sperimentazione di nuove idee e nuove soluzioni.

ma deliveryDeliver Value Continuously (Rilasciare Valore continuamente).

Il concetto di rilascio continuo di Valore è oggi uno dei desiderata predominanti: appena una parte della nostra soluzione è pronta, diventa importante renderla disponibile ai nostri utenti, in modo da fornire subito un nuovo vantaggio competitivo (ROI più rapido) e ottenere rapidamente feedback che consentano di allineare gli step successivi.

Il rilascio continuo ha, inoltre, l’obiettivo di aumentare la qualità di quanto prodotto e ridurre al minimo i disservizi: è sicuramente più semplice intervenire nella risoluzione di problemi che affliggono piccoli rilasci frequenti (perché localizzati), piuttosto che “scovare” e risolvere un problema annesso ad un rilascio che ha richiesto mesi di lavoro e quindi un numero molto alto di aggiunte e modifiche.

Questo principio è inoltre fondamentale per “Experiment and learn rapidly”, creando un loop che fa fluire costantemente le informazioni dallo sviluppo ai clienti e viceversa.

I quattro principi di Modern Agile racchiudono, quindi, un approccio Culturale orientato a trasformare l’azienda in una

Organizzazione Dinamica focalizzata sulla Soddisfazione del Cliente, nonché capace di assecondare le ambizioni e le necessità delle Persone che ne costituiscono la linfa vitale.

Nel prossimo appuntamento daremo uno sguardo a Heart of Agile per poi fare un confronto nel merito e trarre le opportune e dovute considerazioni conclusive.

Stay tuned J

Un nuovo orizzonte per l’Agile: introduzione (pt.1)

Il mondo organizzativo è in constante fermento, con nuove sfide che, quasi a ritmo giornaliero, interessano le diverse realtà produttive, costantemente impegnate a mantenere una propria dignità sul mercato e ad espandere il proprio campo d’azione.

Si tratta di un contesto operativo molto differente da quello di un ventennio fa, periodo in cui si sono poste le basi e si è formalizzato l’Agile Manifesto nella concezione nobile: un insieme di 4 valori e 12 principi che danno vita ad un mindset per creare outcome di Valore (ne abbiamo chiacchierato qui).

Nel corso degli anni, però, Agile è diventato: una metodologia, un framework, un processo, un’azione di Scaling, un “pezzo” di DevOps, un tool, e chi più ne ha più ne metta!

Il risultato primario è una forte Confusione, soprattutto nel mondo del middle-management e tra i CxO che sono arrivati al punto di dire “…ancora Agile! Non voglio più sentirne parlare!”.

is scrum agile

Come dicevamo, il mondo è cambiato, si è evoluto e, nonostante i Valori ed i Principi Agili restino un caposaldo di quello che io amo definire “approccio scientifico alla creazione di Valore”, sono diventati sempre più nascosti, soffocati dagli elementi che abbiamo appena citato.

Inoltre, il Manifesto è nato con un focus sul mondo dello sviluppo software, mentre oggi l’Information Technology è Business, per cui probabilmente bisognerebbe rileggerlo e attualizzarlo: in fondo Inspect-and-Adapt è uno dei mantra che come coach cerchiamo di trasmettere alle Persone con cui lavoriamo.

Bisogna quindi tornare al “Cuore” dell’Agile, spolverandone i concetti chiave per renderli auto esplicativi, sia ai diversi livelli organizzativi sia in relazione a diversi campi produttivi. Proprio in tale direzione si sta assistendo alla nascita di alcuni movimenti, tra i quali i più interessanti, allo stato attuale, sono “Modern Agile” ed “Heart of Agile”.

Modern Agile (modernagile.org), proposto da Joshua Kerievsky, rilegge i valori Agile in chiave indipendente dal mondo del software creando la cosiddetta “Modern Agile Wheel”.

Modern Agile Wheel

Modern Agile Wheel

Approccio simile quello seguito da Alistair Cockburn (che ricordiamo è uno dei firmatari del Manifesto) per la creazione di “Heart of Agile” (heartofagile.com).

heart of agile

Heart of Agile Diamond

Le due proposte, anche se con le proprie specificità, oltre ad avere diversi punti di similitudine, condividono l’obiettivo di “tornare alle origini”, riscoprendo in chiave moderna il senso intrinseco dell’Agile. Andremo a dare uno sguardo approfondito a “Modern Agile” e “Heart of Agile” nei prossimi appuntamenti, ma prima è utile fare alcune ulteriori considerazioni in merito a questa spinta “revisionista”.

Non tutti sono convinti che sia necessario rivedere l’essenza del Manifesto Agile, ritenendo che esso esprima già tutto il necessario per creare un contesto dinamico, efficace ed efficiente. Personalmente è un atteggiamento che non condivido molto, perché significherebbe negare l’essenza stessa dell’Agile, fondata sull’adattamento e il miglioramento continuo. Tanto più che già in occasione della conferenza “Agile 2011”, l’argomento fu portato alla luce sollevando diverse discussioni interessanti (https://pragprog.com/magazines/2011-09/the-only-agile-tools-youll-ever-need).

Cosa diversa sono, invece, le preoccupazioni che derivano dalla possibile ulteriore confusione che potrebbe andare a crearsi, e della ulteriore resistenza che potrebbe aggiungere a quanto abbiamo già evidenziato all’inizio. Tale aspetto è tutt’altro da sottovalutare, basti pensare al fatto che ne Kerievsky e ne Cockburn, ad ora, hanno trovato un modo sintetico per definire le loro proposte e rispondere alla domanda: “cos’è….”, dando le seguenti risposte:

            “what is Modern Agile?”… “it is not a framework or a methodology… is a sticker”

“what is Heart of Agile?”… “I think I’ll call it ‘Do this: collaborate, deliver, reflect, and

improve”

Decisamente un po’ troppo vago per spiegarlo a qualcuno, anche considerando che spesso il lavoro fatto nel supporto all’adozione dell’Agile si è concentrato maggiormente sull’adozione di una metodologia specifica o un tool, piuttosto che fornire all’organizzazione gli strumenti per avviare il necessario cambiamento Culturale.

Questo però non è sicuramente un buon motivo per restare ancorati al passato senza valutare i nuovi scenari, considerando immutabile qualcosa che, ripeto, lo è per definizione.

Per ora ci fermiamo qui, sperando di avere da parte vostra spunti e feedback in merito ed aggiornandoci al prossimo appuntamento in cui vedremo più in dettaglio “Modern Agile”.

Stay tuned J

L’innata iperbole recondita dell’inutilità degli strumenti freddi

Lunedì mattina presto, viaggiando in pullman, mi sono imbattuto in una situazione già vista diverse volte, ma che in questo caso mi ha fatto riflettere: per circa un’ora, ovvero per tutta la durata del viaggio, un tizio è stato letteralmente incollato al portatile, scrivendo email di risposta ai vari colleghi. La cosa che più di tutte ha stimolato la mia riflessione, oltre l’orario, è che l’atteggiamento complessivo (postura, smorfie facciali, ecc.) dava l’impressione che questa persona si comportasse come se dovesse recuperare il “tempo perso del weekend”.

laptop travel

La sensazione è stata rafforza vedendolo tirare quasi un sospiro di piacere quando abbiamo incontrato un rallentamento… tempo in più per le mail!

Sia chiaro non è il lavorare in viaggio che mi ha stupito, visto che anch’io, quando sono in treno (nel pullman non riesco in alcun modo a causa del rumore, degli spazi limitati e del modo “fantasioso” di guidare degli autisti), utilizzo il tempo per lavorare e per approfondire le tematiche che professionalmente mi interessano.

Piuttosto, sono le particolari caratteristiche di contesto che mi hanno fatto riflettere, portandomi a ripensare a quanto siano importanti i Valori e i Principi Agili che metto le Persone al centro di tutto, evidenziando la necessità di mantenerle motivate (“Build projects around motivated individuals”). Sesso discorso per una la vista organizzativa “Energize People” di Management 3.0.

Come si può immaginare di essere produttivi e dare il meglio di sé, se il lunedì mattina alle 6.00 siamo già in queste condizioni? Arriveremo in ufficio stressati dal primo minuto, soprattutto perché l’abuso di strumenti freddi, email in primis, ci porta ad avere una sensazione dell’incompiuto perenne, quasi vergognandoci di dedicare il giusto tempo a noi stessi e ai nostri cari.

incompiuto

Non è possibile immaginare di essere sempre “immersi” nel lavoro, per quanto appagante sembri, perché questo non ci consente di respirare, confrontarci al difuori della sfera professionale, e arricchire le nostre azioni con contaminazioni esterne.

E poi… basta con tutte queste email! “Face to Face conversation”… parliamo con i nostri colleghi, con i nostri clienti, collaboriamo con loro per trovare la giusta quadra in funzione degli obiettivi e delle necessità che dobbiamo soddisfare nell’immediato, con un occhio a quelli generali.

Per darvi un’idea di come la comunicazione tramite email possa essere assurdamente istituzionalizzata, date un’occhiata alla “Email Etiquette: Guidelines for Writing to Your Professors” (https://www.math.uh.edu/~tomforde/Email-Etiquette.html), che spiega agli studenti della Houston University come scrivere una email ai propri professori.

Ad onor del vero, la “guida” si chiude con un “Do Not Use Email as a Substitute for Face-To-Face Conversation”, ma sembra più che altro una cosa buttata li per dovere.

Il succo di tutto il discorso è che non bisogna mai “vergognarsi” di ritagliarsi i propri spazi, staccare la spina e ricaricarsi: non si tratta di un plus, ma di un obbligo che anche l’organizzazione per cui si lavora deve tenere in conto. È un dovere nei riguardi del proprio collaboratore, ma anche un elemento di vantaggio competitivo, potendo contare su Persone che sentono di avere un giusto equilibrio, andando a soddisfare i propri desideri intrinseci.

Stay tuned J

Il dilemma del tentativo unico sul valore ignoto

Per quanto sia coinvolto ormai da molti anni nel mondo Agile, resto ancora spiazzato nello scoprire quanto sia difficile spiegare in parole semplici cosa sia “Agile”.

Qualche settimana fa sono stato coinvolto in una interessante discussione con un gruppo di manager, apparentemente lontani da questo mondo, e, parlando del più e del meno, ad un certo punto uno di loro mi ha chiesto: “convincimi che l’Agile è utile per quello che facciamo nel tempo che impiegheremmo ad attraversare dieci piani in ascensore”.

elevator pitch

Ok, al di là del mio velato sorriso relativamente all’Elevator Pitch, che molti di voi immagino conoscano, devo dire che condensare una risposta efficace in pochi secondi è stato più difficile del previsto.

A primo acchito ho risposto con una definizione che spesso sento usare da Giulio Roggero: “… un set di 4 valore e 12 principi che ci consentono di lavorare insieme in modo efficace ed efficiente”.

Nella mia mente sembrava una risposta chiara e limpida, ma il risultato ottenuto con il manager è stato piuttosto deludente, visto che lo stesso mi ha fatto notare che essa può essere applicata in modo praticamente identico a diversi approcci che sostengono le iniziative del business.

Cavolo… ha decisamente ragione!

Spesso siamo così immersi nel “nostro mondo” che fatichiamo a guardarci intorno e renderci conto che esistono anche altre opzioni che permettono di raggiungere risultati interessanti, in funzione del contesto Culturale in cui vengono applicate.

Resta il fatto che nei giorni a seguire ero rimasto con il cruccio di trovare una definizione o una metafora per avvallare la mia tesi con il manager in questione, e dopo diverse ipotesi ho tirato fuori il “One-Shot Dilemma” che voglio condividere con voi:

Hai a disposizione 1 euro e puoi investirlo in tre modi diversi: una bottiglina d’acqua [bisogno attuale], una penna [bisogno ricorrente] o un gratta e vinci [bisogno futuro]. Cosa scegli?

Il manager è restato sconcertato dalla domanda perché non ha colto il nesso tra le tre diverse scelte, apparentemente casuali e non associabili a problematiche di gestione (non ho chiaramente esplicitato il concetto di bisogno che sopra ho inserito tra parentesi). Dopo qualche secondo, la riposta è stata:

…onestamente non saprei… compro una bottiglina d’acqua così almeno mi disseto!”

dice

Alche, la mia reazione è stata:

Bingo!… è esattamente questo il punto: non puoi decidere cosa fare se non hai visione del bisogno da soddisfare e non hai gli strumenti adatti per contestualizzarlo. È come se sfidassi costantemente la fortuna, sperando che la tua scelta sia quella giusta.

Agile ti permette, invece, di utilizzare al meglio le risorse a tua disposizione, ottenendo valore contestuale da esse e riducendo il rischio “one-shot” perché aiuta a concentrarsi su obiettivi ragionevoli a breve termine, pur inseriti nel quadro generale.” 

La discussione è poi continuata su diversi aspetti di dettaglio che non vi racconto per non annoiarvi.

La considerazione che voglio condividere, però, è quella che in un momento in cui si comincia a parlare con insistenza di Business Agility, Modern Agile e similari, dove l’Agilità si “scrolla di dosso” quel legame forte con lo sviluppo software per divenire uno strumento con cui l’azienda può rispondere in modo più efficace alle perturbazioni di Mercato, dobbiamo imparare ad essere meno “tecnici” nelle nostre discussioni ed abbracciare un vocabolario che ci permetta di dialogare con successo con il nostro interlocutore (Ubiquitous Language!) in modo da far comprendere il Valore annesso al mondo Agile, Lean e DevOps.

Stay tuned J

La sorpresa attonita della massa superficiale

Diciamola tutta: il mondo dell’Information Technology ama le buzzword!

Le amano i commerciali, che vendono sotto “mentite spoglie” prodotti in cui poco o nulla cambia. Le amano i consulenti, che possono rivendere le proprie conoscenze (e sottolineo “conoscenze” e non “competenze”!) cambiando il titolo sulle proprie slide. Le amano gli sviluppatori, che possono atteggiarsi con l’ultimo framework javascript, anche se, probabilmente, verrà abbandonato in meno di un mese. Le amano moltissimo i manager, che intrinsecamente gioiscono nel mostrarsi alla moda.

dilbert buzzword

Relativamente al mio campo di attività, due sono le buzzword che oggi dominano la scena: DevOps ed Industry 4.0. Ci tengo a precisare subito una cosa: non c’è nulla di male, in generale, nel rendere “appetibili” concetti, approcci e tecnologie che sono maturati nel tempo e che subiscono, conseguentemente, anche una metamorfosi nella nomenclatura, rendendoli apprezzabili dalla “massa” e non solo da piccole nicchie della popolazione interessata.

Quello che però è deleterio, è vedere le espressioni di quanti pensano di aver scoperto il santo graal, e ripetere (fino alla noia e sicuri di sé) affermazioni del tipo: “Agile? Ma cosa me ne faccio, tanto io uso DevOps”… oppure “Ho comprato Arduino, riesco a misurare la temperatura… ovvio che sono Industry 4.0!”.

La cosa preoccupante è il fatto che, tali affermazioni non sono la sintesi di un percorso di approfondimento e applicazione empirica dei concetti portanti alla base delle diverse tematiche interessate. In questo caso, infatti, sarebbero comunque rispettabili, anche se opinabili. Spesso, troppo spesso, sono il risultato di una improvvisazione e della presunzione che leggere le prime 2 righe di Wikipedia faccia di noi degli esperti in grado di applicarle nel concreto e ci permetta addirittura di dibattere di esse (dico 2 righe, perché se ne sono state lette 3 allora si è “gran. farabutt. ladr. matricolat. paracul” [cit. fantozzi]).

Ma torniamo alle due buzzword con cui abbiamo iniziato, andando a sintetizzare perché le ritengo un prodotto “commerciale”, utile per parlarne, anche se nella sostanza aggiungono poco alle trasformazioni già in atto da tempo.

Per chi mi segue, non è un mistero il fatto che io non apprezzi particolarmente il termine DevOps, sia perché lega il tutto in modo esclusivo, ed errato, ai soli Developers ed Operation, sia perché, in fondo, avevamo già il termine in grado di rappresentarne l’essenza: Lean.

Ebbene si, DevOps non è null’altro che Lean applicato in modo efficace all’IT (molto più di quanto si sia riusciti con Lean Software Development dei Poppendieck), avvalendosi delle nuove piattaforme tecnologiche, in grado di automatizzare le attività e misurare i progressi ottenuti.

Non siete convinti? Provate a leggere The Phoenix Project, l’unico, e sottolineo unico, libro che dovete leggere per capire cos’è DevOps, e provate ad annotarvi quante volte incontrate il termine DevOps… curiosi? Ebbene, solo nella seconda di copertina, nella frase di introduzione al libro stesso: “A Novel About IT, DevOps, and Helping Your Business Win”.

Qualcuno potrebbe dirmi… vabbè, però la Continuous Integration e la Continuous Delivery è roba dei nostri giorni che prima non c’era… sicuri? La CI è uno dei Principi cardini di eXtreme Programming (XP), una delle principali metodologie Agili nata nella seconda metà degli anni ‘90. E sempre in XP troviamo le pratiche (corollarie) di Incremental Deployment e Daily Deployment che possiamo considerare una prima formalizzazione della Continuous Delivery.

Quindi roba “vecchia” che oggi è diventata di “moda” spesso perché “… è facile farla”, perdendo però di vista il vero scopo del “perché farla”: non faccio Continuous Integration perché è figo vedere il flag verde sulla build. Faccio CI perché in questo modo ottengo feedback rapidi che consentono ai membri del team di migliorarsi e risolvere velocemente i problemi, evitando che il costo di integrazione diventi uno spreco rilevante del budget che ho a disposizione. Se in un team di 7 persone, solo uno fa CI e gli altri creano 30 branch di GIT che si ricordano di integrare solo dopo 2 mesi… beh, immagino che non ci sia neanche bisogno di dire cosa accade all’atto dell’integrazione. Stesso discorso se non ho gli unit test: Continuous Integration senza Unit Test è come una Cena senza del buon Vino…

Ed Industry 4.0? Anche qui, proviamo a dare una definizione di quella che viene indicata come quarta rivoluzione industriale:

“Industry 4.0 connota una filosofia aziendale Customer Centric basata su produzione flessibile e ottimizzazione delle risorse.

L’obiettivo è quello di combinare l’efficienza della produzione di massa con quella on demand, inclusa l’ottimizzazione real-time della catena di distribuzione (Supply Chain)”

hmmm… a me ricorda molto un’altra definizione che condivido con voi:

[..] is a systematic method for waste minimization (“Muda”) within a manufacturing system without sacrificing productivity. Lean also takes into account waste created through overburden (“Muri”) and waste created through unevenness in work loads (“Mura”). Working from the perspective of the client who consumes a product or service, “value” is any action or process that a customer would be willing to pay for.

sapete di cosa si tratta? Lean Manufacturing (o se preferite Toyota Production System). Ovviamente, anche qui ci sono delle evoluzioni importanti, soprattutto relativamente alle tecnologie disponibili, ma l’essenza non è cambiata di molto.

Le buzzword sono quindi il male in terra? Direi di no. Come accennato sono uno strumento che, utilizzato con parsimonia, può contribuire a diffondere meglio la trasformazione che tutti i settori produttivi stanno attraversando.

Indipendentemente dal campo specifico, infatti, oggi si è giunti ad una maturazione del concetto di produzione, in cui si realizzano Servizi (e non solo prodotti) in grado di raccogliere e soddisfare le esigenze delle Persone (non utenti!), facendo attenzione a rendere i processi sostenibili dalle Persone che tali servizi sono chiamati a realizzarli.

E anche qui, Persone e Iterazioni prima di tutto!

Stay tuned J

L’ossimoro implicito dell’ortodossia innaturale nel cambiamento stagnante

Quando si parla di cambiamento, è interessante notare come la maggior parte delle aziende ascoltano con interesse ma poi alzano subito una prima barriera dicendo “…eh… sarebbe bello, ma da noi è difficile convincere le persone a cambiare!”.

change resistance

Tale affermazione è supportata da diversi report che, annualmente, aggregano dati di centinaia di aziende a livello globale per capire lo stato di adozione dei diversi approcci ed evidenziare quelli che sono i principali problemi annessi.

change barriers

Al top della classifica c’è proprio la resistenza al cambiamento: organizzativa, culturale e personale. La questione è che, se non si trova il modo di superare questo impedimento primario, l’adozione di nuovi Approcci Culturali come Agile, Lean e DevOps perde di qualsiasi significato, riducendosi all’adozione di alcune pratiche o strumenti che portano un micro beneficio locale senza contribuire in modo sistematico al riassetto generale in funzione del business.

In queste condizioni basta un piccolo intoppo o un cambiamento al vertice per tirare conclusioni del tipo: “Mah… in fondo Agile non è che funzioni poi tanto, torniamo ad un approccio più tradizionale con maggiore controllo su ciò che accade” o anche “Vabbè, ma poi noi manager che fine facciamo in questo nuovo modo di impostare le cose? Forse è meglio attendere”.

Questo atteggiamento è estremamente pericoloso per qualsiasi azienda che voglia essere competitiva sul mercato ed è paradossalmente sbagliato per definizione: ognuno di noi, in quanto Persona, cambia implicitamente in modo costante, giorno per giorno, in relazione alle esperienze, ai problemi, alle opportunità, alle esigenze e così via. Quindi come si fa a dire che una persona non è incline al cambiamento quando lo fa di continuo?

La questione è che quando il cambiamento è esplicitato ed “comandato” dall’organizzazione, le Persone sono portate ad assumere un atteggiamento diffidente e farsi 1000 domande del perché si sta avviando tale processo.

Il tutto è ben rappresentato dal noto diagramma seguente, che trova le proprie origini nella ricerca (1969) effettuata dalla psichiatra svizzera Elisabeth Kübler-Ross in relazione alle reazioni che mostravano i pazienti quando gli veniva comunicata la prognosi di morte (si lo so è decisamente triste la sua nascita).

change acceptance

La curva indica il livello di motivazione ad accettare il cambiamento che la Persona deve “subire” e che non è sotto la sua governance, e, su di essa, sono rappresentati i principali stati (fasi) emotivi in cui viene a trovarsi.

Lo studio originale individuava 5 stati: negazione, rabbia, contrattazione, depressione, accettazione, mentre negli anni le diverse contestualizzazioni hanno portato ad avere i 7 stati indicati nella figura precedente e generalmente accettati oggi:

  • Negazione, non accettazione della novità;
  • Realizzazione, si prende atto che qualcosa è avvenuto e se ne cerca riscontro;
  • Frustrazione, ci si difende implicitamente da quanto sta avvenendo;
  • Accettazione, si assume un atteggiamento rassegnato con scarsa propositività;
  • Sperimentazione, si cerca di capire come posizionarsi nel nuovo contesto;
  • Riflessione, si scava in dettaglio su ciò che il cambiamento sta comportando, integrandosi con esso e aumentando la propria produttività;
  • Integrazione, si è a proprio agio con il nuovo contesto.

Per quanto illuminate, questa curva non risponde però ad una domanda evidente: perché in alcuni casi il cambiamento ha successo ed in altri no? Per rispondere ad essa possiamo utilizzare l’Equazione del Cambiamento (o anche Formula di Gleicher) che descrive in maniera lineare quando scatta il cambiamento:

C = I x V x P > S

Quindi il Cambiamento avviene quando la risultate dell’Insoddisfazione (I), della Vision (V) e dei Primi Passi (P) compiuti nella sua direzione è maggiore dello Status quo (S) attuale. Tali fattori devono sussistere contemporaneamente per portare al cambiamento: se, banalmente, non vivo in modo insoddisfacente la situazione attuale, non c’è leva che mi porterà a cambiare.

Ma come possiamo fare allora a spingere al cambiamento le Persone e l’organizzazione nel complesso? Uno degli approcci più apprezzati è il Change Management Process (CMP) di John Kotter, professore alla Harvard Business School e autore del libro “Leading Change”, che consta di 8 passi:

  • Sviluppare un senso di urgenza
  • Costruire il team che guiderà il cambiamento
  • Creare una visione chiara
  • Comunicare la visione
  • Rimuovere gli ostacoli
  • Creare piccoli successi nell’immediato
  • Non mollare la presa
  • Fare attecchire il cambiamento

Questi passi sono spesso anche alla base anche degli ultimi ritrovati come The Lean Change Method di Jeff Anderson e, probabilmente, ognuno di noi ne ha avvertito la presenza durante una fase di cambiamento che l’ha interessato direttamente. Da essi è possibile estrarre alcuni principi base che gli agenti del cambiamento devono tener presenti nella loro azione di promozione al cambiamento stesso:

  • Awareness, creare una consapevolezza generale del perché è necessario cambiare;
  • Desire, far emergere il desiderio al cambiamento e spinge le persone coinvolte ad avere un atteggiamento proattivo;
  • Knowledge, esplicitare come il cambiamento dovrebbe avvenire;
  • Ability, costruire nuovi modelli organizzativi che supportino il cambiamento in modo naturale;
  • Reinforcement, sostenere e supportare costantemente il cambiamento.

Come affermato da Sun Tzu: “Combatti con metodi ortodossi, vinci con metodi straordinari“… e questo è solo l’inizio….

 

Stay tuned J

La dissonanza dell’effetto Zeigarnik nello spezzatino del tempo

Ogni strategia di business richiede un programma di attuazione che abbina la flessibilità alla chiarezza degli obiettivi da raggiungere, sia in termini di mercato che di profitto. Ciò implica che una fetta, più o meno consistente, della nostra azienda si organizza per concretizzare il programma stesso e far si che esso sia sempre coerente con la Vision e Mission aziendale, contribuendo a raggiungerla.

A livello operativo è nomarle creare appositi gruppi di lavoro che pianificano, gestiscono e reagiscono alla risposta del mercato e che sono spesso dedicati in modo quasi esclusivo all’obiettivo complessivo, ritenuto troppo complesso da poter essere gestito in concorrenza. Questo focus diventa fondamentale per permettere al gruppo di tenere sempre presente l’obiettivo generale da raggiungere, andando a contestualizzare il tutto rispetto alla propria organizzazione e al mercato di riferimento. Questi ultimi, come è noto, si influenzano a vicenda.

Nel mondo dell’IT, il focus e la concentrazione su poche attività specifiche, chissà perché, è quasi sempre visto come un limite o una incapacità, se non addirittura una scarsa attitudine al lavoro. Spesso le Persone sono considerate alla stregua di automi da poter allocare su attività multiple per percentuali ridicole di tempo senza neanche rendere chiaro il senso del loro stesso lavoro.

the multitasking myth

Tutti voi condividete con me quanto sia tristemente comune imbattersi in pianificazioni che creano il fantomatico “spezzatino del tempo”: “durante le prossime settimane, Tizio sarà alloca per il 10% sul progetto A, il 25% su quello B, il 50% su quell’altro e il 20 a supporto del precedente”.. ovviamente non ci si accontenta del 100%, ma si abbonda sempre un po’, cosa che ricorda l’esilarante scena in cui Totò diceva a Peppino De Filippo di non risparmiare sull’uso della punteggiatura: “…ma sì, fai vedere che abbondiamo… Abbondandis in abbondandum” (dettatura della lettera in Totò Peppino e la Malafemmena).

La domanda è: serve a qualcosa questo tipo di pianificazione? Si, a far impazzire le Persone e a ridurre drammaticamente la loro Produttività!

crazy productive people

Ma come si può anche solo minimante pensare che una Persona possa esprimersi professionalmente al meglio se la sua attività viene trasformata in una sorta di “zapping” su task disconnessi, costringendolo continuamente a cambiare focus operativo, sia rispetto al prodotto che rispetto alle relazioni che caratterizzano l’ambiente con cui operare.

È empiricamente dimostrato che una persona può seguire al massimo due progetti in contemporanea (non lo dico io, ma diversi studi antropologici): uno principale e uno secondario che serve anche come “distrazione”. Se si comincia a saltellare da un progetto all’altro, aumenta solo l’entropia, incrementando il costo del cambiamento di contesto, e acuendo il poco noto, ma estremamente significativo, effetto Zeigarnik.

Tale effetto (osservato e formalizzato dalla psicologa lituana Bluma Zeigarnik) evidenzia come, tipicamente, quando si lascia incompiuto un compito a cui ci si è dedicati, si sperimentano pensieri intrusivi che rendono difficile concentrarsi su altro: in soldoni ci ricordiamo più facilmente delle cose che non abbiamo portato a termine rispetto a quelle completate.
Questo perché, sembra essere nella natura umana l’indole di finire quanto avviato e, se non riusciamo a farlo, tendiamo a sperimentare una dissonanza.

Quindi, più cose lasciamo in sospeso più la nostra mente cerca di ricordarcele, impedendoci di concentraci su altro.

Morale della favola: diamo alle Persone la possibilità di portare a termine, al meglio, le proprie attività, evitando di impegnarle in decine di progetti differenti solo perché “così si utilizza al meglio la risorsa”: avvaliamoci della professionalità dei nostri collaboratori senza avere la presunzione di volerne gestire il tempo.

Stay tuned J

L’esponenziale negativo dell’equazione lineare

Lavorando con aziende di medie e grandi dimensioni, mi capita spesso di imbattermi in discussioni riguardanti l’outsourcing dell’IT e di come esso rappresenti spesso una strategia utilizzata dal top management per tagliare idealmente i costi.

Sicuramente, finché esiste un buon bilanciamento tra IT interno ed outsourcing, la strategia può effettivamente rilevarsi vincente, il problema è quando si passa all’outsourcing estremo: “l’IT è esclusivamente un centro di costo, per cui lo metto fuori e pago solo per i servizi che richiedo”.

In linea teorica, questa soluzione potrebbe sembrare la panacea di tutti i mali, tanto che i costi potrebbero essere teoricamente rappresentati da una comune equazione lineare:

oustourcing cost eq lineare

costi = Δ * TCF

con TotalCostFactor (TCF) = costo servizio * n. servizi richiesti

ragionando su un costo unitario medio uguale indipendentemente dalla tipologia di servizi.

Il Δ è un valore minore o uguale ad 1 (mediamente tra 0.8 e 1) che diminuisce all’aumentare dei servizi richiesti e rappresenta lo sconto che tipicamente si chiede quando la quantità di servizi richiesti aumenta (giornate).
In realtà questa pia illusione di risparmio comincia ben presto a scontrarsi con diversi problemi:

  • Perdita del know-how;
  • Perdita della sinergia tra strategia e operatività;
  • Riduzione della capacità di reazione rispetto alle esigenze del mercato;
  • Scarsa evidenza dei rischi e delle problematiche tecnico/tecnologiche.

che formano un insieme che definiremo “Independent Debt”.

Il “Debito di Indipendenza” spesso inizialmente sfugge anche alle più attente valutazioni del management, diventando con il tempo un boomerang per l’organizzazione che può venirsi a trovare letteralmente in balia dell’outsourcer e quindi soggetta al rischio che il potere contrattuale passi proprio nelle mani di quest’ultimo.

In tale scenario, i costi, forse inizialmente più bassi perché il fornitore voleva entrare nelle “nostre grazie”, cominciano a crescere (per inteso: le richieste possono essere legittime, non dettate da pigra furbizia) e si sommano a quelli dovuti all’impatto negativo dell’insieme dei problemi di cui sopra.

outsourcing cost

Ciò trasforma la nostra equazione lineare in una equazione esponenziale in cui i costi cominciano a salire in modo rilevante senza che si abbiano più gli strumenti per contrastare il fenomeno.

outsourcing cost eq esponenziale

costi = e^TCF  

con TCF = (Δ aumento dei costi servizi * costo servizio * n. servizi richiesti) + costo del Debito di Indipendenza

Nel momento in cui il peso non sarà più sostenibile, all’azienda resterà una sola cosa da fare: riportare tutto l’IT all’interno e… ricominciare da capo!

Questo comporterà un investimento che sicuramente annullerà e supererà tutti i benefici eventualmente ottenuti con la politica di outsorcing estremo.

 

Stay tuned J