La finta illusione dell’escapologia organizzativa indotta nella “e” di Agile

Avviare una trasformazione profonda come quella che porta un’azienda a scoprire la propria Agilità, diventando un’organizzazione in grado di adattarsi continuamente ai cambiamenti, richiede un Programma di forte intensità che incide sull’essenza stessa dell’“io organizzativo”.

Non di rado capita che si decida di “testare con mano” gli effetti del cambiamento, creando l’arcinoto Progetto Pilotta. Se a molti sembra un passaggio ovvio e dovuto, bisogna evidenziare che il successo di un progetto pilota non implica automaticamente il successo nell’adozione sistemica di quanto sperimentato, anzi!

pilot project

Il problema è che spesso si cade nella trappola di “proteggere” tale progetto, creando un ambiente specifico dissociato da quello reale, non soggetto proprio alle dinamiche che invece si vorrebbero risolvere con il cambiamento ipotizzato. Si tratta di una vera e propria azione di escapologia organizzativa, ovvero la capacità di isolarsi dal contesto specifico, creando le condizioni ideali che ci portano ad un successo apparente, ma non replicabile in quello reale.

Partendo da questa premessa, diamo un sguardo ai fattori primari di cui dovremmo tener conto affinché un progetto pilota sia realmente significativo:

  • Contesto. In un progetto pilota tutti ne conoscono la natura e i diretti interessati, e sentendosi “osservati” possono comportarsi come atteso piuttosto che come farebbero normalmente, falsando completamente il risultato;
  • As-Is. L’outcome del progetto dovrà confrontarsi con i processi esistenti ed abbattere la tipica resistenza al cambiamento prima di poter essere assorbito come sistemico. Bisogna sempre tenere in considerazione, inoltre, che quanto valido a livello locale potrebbe non funzionare a livello globale;
  • Risorse. Tipicamente sono sufficienti solo per il progetto stesso e l’estensione dei risultati richiede un programma di investimento specifico;
  • Coinvolgimento. Chi resta fuori dal progetto pilota può sentirsi escluso e fare quanto in suo potere, in modo più o meno esplicito, per affossare il tutto;
  • Tempo. Non esiste una diretta correlazione tra il tempo impiegato per il progetto pilota e il tempo che sarà necessario per rendere i risultati organici a tutta l’azienda;
  • Coraggio. Bisogna avere persone “illuminate” che non temono il cambiamento e non si arenano sul “… tanto qui non cambia mai nulla!”.

Questi fattori, non esclusivi, sono sempre presenti e ci portano a riflettere su quanto possiamo fare per porci almeno nelle condizioni di avere un progetto pilota che possa avere successo. L’obiettivo è che tale progetto deve rappresentare un valore concreto per la nostra organizzazione, andando a toccare almeno i seguenti elementi chiave:

  • Massimizzare gli elementi positivi. Bisogna sempre selezionare i progetti più promettenti che consento di validare rapidamente i risultati, senza costi e rischi eccessivi;
  • È fondamentale individuare Persone energiche ed entusiaste, tipicamente prone all’innovazione e al cambiamento. Inoltre, si deve avere a bordo uno sponsor aziendale di alto livello che senta propria l’iniziativa, aiutando a trovare le risorse necessarie;
  • Benefici di business. Il progetto pilota dovrà evidenziare chiaramente i benefici aziendali ai diversi livelli, dimostrando come il relativo saldo con gli investimenti sia positivo. I vantaggi ottenuti devono sempre riguardare sia le singole Persone che il contesto organizzativo complessivo;
  • Oltre il perimetro. Al progetto vanno associati un ambito preciso e obiettivi ragionevoli, evitando di “volare alla cieca” e dando un senso alle diverse azioni di pivot che generalmente lo accompagnano. Resta comunque fondamentale che il tutto sia “estendibile” al contesto complessivo e che non abbia senso solo nello specifico;
  • Apprendimento. Il progetto pilota non ha successo se produce qualcosa (o almeno non solo): si ha successo se chi lo attua e l’organizzazione tutta è in grado di imparare da esso, anche in caso di fallimento. Ricordate: “fail often, fail fast”;
  • Training e Coaching. Nessun progetto pilota può avere successo se non è accompagnato da opportune azioni di training e coaching. Il tutto è tanto più evidente e rilevante quanto più l’innovazione introdotta è dirompente;
  • Visibilità. Rendere il progetto visibile anche a chi non è direttamente coinvolto è fondamentale per cominciare a disseminarne i risultati e rimuovere la presunzione di “proprietà” che, tipicamente, chi non è coinvolto tende ad associare al Team pilota.

Infine, ricordate sempre che se il progetto pilota non ha più senso di continuare, allora è meglio interromperlo subito, rivolgendo la nostra attenzione a qualcosa di più utile per la nostra organizzazione.

Stay tuned J

Agile@school – Parte il progetto all’IIS Viola/Marchesini. Rovigo

Grazie a Michele Ferracin, con cui ho stretto amicizia e collaborazione ormai da qualche mese, il progetto Agile@School ha aperto i battenti anche nel nord Italia, precisamente a Rovigo all’IIS Viola/Marchesini.

Michele, anch’esso membro gi getlatestversion.it, ha portato il nostro progetto in una nuova scuola, e vedremo col tempo che succederà, anche se sono certo che sarà un successo, visto quanto successo a Parma gli anni precedenti.
L’idea è quella di creare una community, e ricordo a tutti i potenziali interessati di leggere questo mio post, in cui sottolineo le caratteristiche del progetto e come fare per aderire.
La cronistoria inizia qui.
E siamo già alla seconda lezione.

Spero vivamente che la cosa appassioni sia gli studenti, sia le scuole, sia i tecnici, che come noi, vogliono proporre un nuovo modo di avvicinare i ragazzi al mondo del lavoro.

Stay Tuned! 

La Giraffa che sottende la “g” di Agile

Una cosa è fondamentale nella vita di ognuno di noi: la capacità di rispettare gli altri, avendo sempre un atteggiamento propositivo senza scadere nella tentazione di scaricare sugli altri le proprie frustrazione o lo stress accumulato.

Uno dei soft-skill più importanti del mondo Agile, ancora più caratterizzante se si è uno Scrum Master o un Coach, è la padronanza del linguaggio non violento, ovvero un modo di comunicare che vada al di là di quello ordinario, tipicamente incline a giudicare, interpretare, stabilire e incollare etichette al fine di pretendere di imporre la propria visione e la propria idea di “corretto”.

violent communication

Il linguaggio ordinario è stato etichettato dallo psicologo Marshall Rosenberg come linguaggio sciacallo per connotarne la propensione naturale ed esclusiva alla pretesa: “bisogna fare questo…”, “devi farlo, che ti piaccia o no”, “basta così!”. L’effetto diretto è la frustrazione di chi riceve il “comando” che si sente mero esecutore, sopprimendo progressivamente ogni scintilla di creatività.

Dualmente, Rosenberg caratterizza quello che definisce il linguaggio giraffa, incentrato sul chiedere con garbo laddove il linguaggio sciacallo pretende. Lo psicologo ha scelto di associare simbolicamente a tale linguaggio la Giraffa, essendo quest’ultima il mammifero con il più cuore grande, oltre a simboleggiare la capacità, grazie all’alto collo, di osservare il tutto con un orizzonte più ampio.

jackal vs giraffe

Troviamo così una comunicazione improntata sulla richiesta: “potresti fare questa attività?”,cosa ne pensi se modifichiamo questo?”, portando ogni singola Persona a sentirsi partecipe delle scelte e a proporre soluzioni innovative.

Il linguaggio giraffa si basa su quattro punti chiave:

  • Osservare e non giudicare: dire ciò che si osserva senza contaminare le affermazioni con giudizi o valutazioni proprie. Ad esempio: “tu mi fai generalmente annoiare” [sciacallo], diventa “in questa occasione le tue argomentazioni sono state più di una volta poco attrattive” [giraffa]
  • Esprimere i sentimenti: dire ciò che si sente fornendo informazioni esplicite sul nostro stato. Ad esempio: “io mi sento manipolato” [sciacallo], diventa “non mi sento particolarmente a mio agio” [giraffa];
  • Chiarire a sé stessi i bisogni che nascono dai sentimenti: si tratta di esprimersi in funzione di un bisogno, motivando i sentimenti che li accompagnano. Ad esempio: “il tuo comportamento mi ha deluso” [sciacallo], diventa “sono deluso dal fatto che tu mi abbia ignorato perché avevo bisogno di confidarmi con te” [giraffa];
  • Formulare richieste precise: chiedere in modo chiaro e diretto è il primo modo per ottenere una risposta/azione di valore. Quindi, piuttosto che: “Mi piacerebbe conoscerti meglio” [sciacallo], “Vorrei stringere un rapporto più stretto con te, andiamo a bere insieme qualcosa questa sera?” [giraffa]

I quattro punti chiave sono sorretti da altrettanti principi fondamentali:

  • Rispetto per ogni persona, sincero ed incondizionato;
  • Dire sempre la verità, altrimenti si costruisce un mondo finto in cui scatta la “violenza”;
  • Non accettare ingiustizie, se lo si fa si rischia di giustificare “linguaggi violenti”;
  • Combattere le piccole ingiustizie alla nostra portata, ricordandosi di essere pronti a gestire la “violenza” che cerca di contrapporsi alla “non-violenza”.

Il tutto permette di creare un ambiente in cui le Persone collaborano in modo propositivo, sentendosi utili (desideri intrinseci) e sperimentando nuove soluzioni alle problematiche riscontrate. Chiudiamo con alcuni suggerimenti che possono aiutare a incontrare la propria giraffa:

  • Non usare il verbo essere in modo valutativo e categorico
    • sei sempre distratto!” [sciacallo], “ieri durante la riunione non hai prestato la dovuta attenzione” [giraffa]
  • Sostituire i verbi che sottendono una valutazione
    • il tuo atteggiamento è stato superficiale” [sciacallo], ma “durante la riunione hai mostrato superficialità” [giraffa]
  • Non considerare le proprie valutazioni come le uniche possibili:
    • devi chiederti perché hai fatto questo” [sciacallo], “io mi porrei alcune domande, giusto per capire se si è sulla strada giusta” [giraffa]
  • Non usare avverbi che portano a generalizzare i concetti:
    • sei sempre negativo!” [sciacallo], “durante la riunione mi sei sembrato disfattista” [giraffa]

Stay tuned J

DevOpsHeroes, ci vediamo l’anno prossimo!

Dettagli dell’evento

DevOpsHeroes è stato un grande evento. Non ci aspettavamo così tante persone e, soprattutto, non potevamo immaginare dei feedback così positivi nel complesso. I numeri:

  • Iscritti: 150
  • Partecipanti: 93
  • drop: 38%

Provenienza dei presenti:

partecipanti-geografia.png

Soddisfazione dei partecipanti

Qui di seguito un grafico a radar che riassume il vostro gradimento in materia di data dell’evento, location, sessioni, speaker, ristorazione, accoglienza ed allestimento/kit di benvenuto:

soddisfazione

Un bel 4/5, molto alto nel complesso. Il tutto è rafforzato dalle risposte alle domande seguenti:

  • Tornerai?
    • Certamente, 26%
    • Molto probabilmente, 52%
    • Probabilmente sì, 20%
  • Suggerirai l’evento ai tuoi amici?
    • Certamente, 59%
    • Molto probabilmente sì, 32%
    • Probabilmente sì, 9%

E pensate che per l’87% dei partecipanti era la prima volta a DevOpsHeroes.

Altre considerazioni

Sappiamo che dovremo lavorare ancora e ancora per l’edizione del prossimo anno, sia in termini di organizzazione che di idee e di format. Tuttavia, possiamo dire di aver fatto molto bene. Un’ottima location ci ha aiutato a rendere il tutto molto professionale. 

Una nota positiva sono i feedback ricevuti. Il numero è praticamente identico a quello atteso (numero dei partecipanti x numero di sessioni seguite) e ciò ha dato a noi la possibilità di usare i risultati come “la vera sorgente” di ogni suggerimento.

Parlando di sessioni tecniche, includendo la stupenda speech di Martin Woodward, abbiamo ricevuto una serie di importantissimi suggerimenti. Lo sapevamo già prima, gli speaker sono di livello molto alto e hanno una passione al di fuori del comune. Ma, senza i sondaggi, come potremmo migliorarci? Ed è proprio qui che arriva il bello; le ultime due nottate le ho passate a sfogliare i bigliettini lasciati da voi, mentre il mio piccolo dormiva (per quel poco tempo, ecco). Ogni foglietto portava con sé le seguenti domande:

  • La sessione ha soddisfatto le tue aspettative?
  • Quanto era interessante?
  • Quanto è stata importante per te?
  • Come valuti la qualità della presentazione?
  • Com’è stato lo speaker? Divertente, Esperto, Insegnante, Motivatore, Oratore?

Ancora una volta un grafico a radar mostra i risultati.

screen-shot-2017-10-28-at-02-07-53-e1509149570123.png

Dai risultati, gli speaker italiani sembrano essere esperti, oratori e addirittura qualche volta divertenti.

Conslusioni:

Siamo molto orgogliosi della seconda edizione di DevOpsHeroes. Engage IT Services e Upgrade hanno fatto un bel lavoro insieme. Speriamo si possa proseguire nella collaborazione (grazie Riccardo Rolando e Andrea Cannilla). Un ringraziamento speciale va a Martin Woodward che ha “attraversato i sette mari” per raggiungerci a Parma, e al nostro sponsor HPE che ci ha consentito di organizzare l’evento per intero. Ancora un grazie va a Silvio Di Benedetto e Giuliano Latini, che hanno seguito la parte di registrazione e di interviste, che vedrete presto qui.

Non esitate a scaricare il materiale di DevOpsHeroes nella sezione dedicata sul sito.

Per ultime, ma non per importanza, le nostre community GetLatestVersion.it, DotDotNet.org e WindowServer.it grazie alle quali eventi come questo sono possibili in realtà come la nostra.

Che dire, ci vediamo l’anno prossimo e…

Stay Tuned! 

La declinazione oscura della “l” di Agile

Tutti siamo probabilmente d’accordo che spesso è difficile trovare una definizione diretta ed immediata di Agilità… ed è giusto così!

Ogni realtà è Agile a suo modo, e anche l’adozione di un framework o di una metodologia specifica è da intendersi come un riferimento da cui trarre ispirazione, applicandolo il più possibile nel suo insieme per poi “rompere le regole” e trovare la propria declinazione di agilità.

Ma nell’Agile si annida un virus potenzialmente letale che cerca di farsi strada man mano che si procede nel cambiamento e bussa alla porta ogni volta che si incontra un intoppo o un problema: si tratta del lassismo.

Stiamo parlando dell’atteggiamento che porta ad una mancanza di serietà e disciplina nelle proprie azioni, sfociando quasi sempre in un menefreghismo ed in una rassegnazione generica che porta a considerare ogni sforzo inutile poiché “tanto nulla cambia”.

lassismo

Tenere alta l’asticella dell’entusiasmo durante una fase di cambiamento è uno dei compiti più ardui per chi si occupa di supportare il cambiamento stesso, al di la del ruolo specifico. Creare la necessaria empatia e portare a bordo tutti gli attori indispensabili per partire nel modo giusto può essere più o meno facile, partendo da un’azione di lift-off che consente di allineare tutti sugli obiettivi e sulle motivazioni che spingono ad intraprendere il nuovo percorso (ne abbiamo parlato qui: l’ossimoro implicito dell’ortodossia innaturale nel cambiamento stagnante).
Se in questo percorso ci allontaniamo da un approccio empirico, non caratterizzando la nostra azione in chiave inspect-and-adapt, rischiamo di divergere rispetto alla realtà, chiudendoci nella nostra iron tower e provocando un lassismo generale: in pratica le persone “tollerano il cambiamento” perché imposto e spinto da qualcuno giornalmente, ma non vedono l’ora di tornare a dedicarsi alle cose che, a loro avviso, sono importanti. La regressione è praticamente dietro l’angolo.

Alcuni esempi concreti riguardano l’adozione di uno specifico framework. Si pensi ad esempio a Scrum, che, seppur un ottimo punto di partenza in moltissimi casi, potrebbe non essere idoneo a supportare alcuni contesto specifico: se non si ha un Product Backlog in quanto tale, e i work item sono comunicato durante l’iterazione o a ridosso dell’inizio di essa, non è forse meglio operare in modo diverso? Ha ancora senso stimare in tal caso a livello team? Possiamo utilizzare il tempo relativo per trovare una forma diversa di condivisione delle informazioni o per realizzare “cose”? Riflessioni, non suggerimenti… ma di stiame si può morire :-)

regret estimate

Se le diverse azioni restano un mero esercizio stilistico, le Persone cominceranno a farsi scivolare addosso quanto si sta provando ad applicare con fatica, andando a vanificare gli investimenti relativi, ma, soprattutto, perdendo un’occasione per rinvigorire la propria organizzazione e rispondere alle nuove sfide.

Il messaggio è quindi eloquente: concentrarsi sempre e comunque su quanto porta realmente Valore nell’azione di cambiamento, abbandonando stereotipi e i “verbi”, senza chiaramente dimenticare di far tesoro della propria esperienza unita ad un forte background relativo.

Stay tuned J

La fluttuazione della collaborazione nei dettagli

La collaborazione è il collante di ogni team che voglia definirsi tale.

Quando inizio un nuovo workshop o una nuova attività di coaching, pongo spesso la domanda: “sapete qual è il problema principale nel mondo del software?” domanda che scatena le risposte più disparate: dalla comprensione dei requisiti alla capacità di rispettare la pianificazione.

Ma il cuore del problema è un altro: il software (o meglio le soluzioni IT) è un artefatto complesso realizzato da un sistema adattivo complesso (CAS, Complex Adaptive System): NOI!

Un insieme di Persone che devono imparare a collaborare ed essere un team, non semplicemente stare sedute l’una affianco all’altra.

complexity

Ecco che quindi prende forma il cuore dell’agilità, improntato sul primo valore Gli individui e le Interazioni più che i processi e gli strumenti, su cui si concentra quel cambiamento Culturale che quasi sempre richiamiamo e che richiede una costante e continua attenzione ai dettagli.

Perché è proprio nei dettagli che si nasconde il diavolo: sono i piccoli gesti, i comportamenti, le smorfie, i silenzi, ad essere gli elementi spesso più indicativi di un malessere che mina la collaborazione e la capacità di fidarsi degli altri.

devil details

Ignorarli è come guardare una città dall’elicottero: tutto sembra bello e affascinate, ma quando poi si atterra e si guardano da vicino gli elementi urbani ci si accorge, purtroppo, che le cose sono ben diverse.

La collaborazione è una virtù, ovvero la capacità di non curare solo i propri interessi, ma di trovare il modo di fare quello di tutte le parti in gioco, anche senza ottenere il massimo per sé. Come ogni virtù, bisogna però coltivarla ed impegnarsi nel superamento dei problemi giornalieri, non ignorandoli o nascondendoli sotto il tappeto, ma rendendoli evidenti e affrontandoli con strumenti “sociali” che portino a un nuovo punto di equilibrio nella collaborazione interna del nostro sistema complesso.

Far finta che sia un problema del singolo e non del sistema è un errore madornale, poiché la stessa agilità si fonda sul concetto di team e di collaborazione tra le Persone: senza di essa è impossibile raggiungere risultati apprezzabili e ottenere “più della somma delle singole parti”. In tutto questo il ruolo del facilitatore/coach/scrum master/ecc.. è quanto mai fondamentale, andandone a connotare le caratteristiche specifiche: si tratta di una “bestia sociale” in grado di osservare, (cercare di) capire il singolo e il sistema nel suo insieme, intervenendo proprio sui dettagli di cui sopra, attraverso azioni che derivano dalla propria esperienza e da una profonda conoscenza delle pratiche annesse.

Insomma… la collaborazione è alla base di tutto, se questa è fluttuante, altrettanto lo diventa l’azione d’insieme nella produzione di Valore e la capacità di raggiungere obiettivi che consentano all’azienda di diventare rilevante nel Mercato.

 

Stay tuned J

La consapevolezza aurea del miglioramento oggettivo

Uno degli aspetti fondamentali che spesso finiscono in secondo piano quando si intraprende un percorso di cambiamento, è la capacità di misurare oggettivamente i progressi, individuando chiaramente gli obiettivi da perseguire: pochi, chiari e misurabili!

In tal modo, quando ci si chiede se si sono ottenuti effettivi vantaggi dal nostro “transformation journey”, possiamo rispondere con qualcosa di più interessante dell’inutile “mah… a naso… secondo me… siamo più bravi di prima”, affermazione che non significa un bel niente.

In Agile, Lean, e quindi in DevOps, il concetto di “misura”, l’individuazione delle metriche che contano (actionable metrics) e, soprattutto, delle azioni di improvement da settare per migliorarsi costantemente, sono elementi ben evidenziati e costantemente sottolineati.

Come tutte le cose, però, bisogna capire come individuare le “buone metriche”, ovvero quelle più adatte al proprio contesto e più significative per il percorso di miglioramento intrapreso. In generale, se si guarda al tutto in ottica Lean (ok… va bene anche DevOps J) è possibile caratterizzare le diverse metriche in funzione di tre elementi principali:

  • Persone (People). Le Persone sono al centro del cambiamento culturale e sono il motore della nostra organizzazione. Risulta quindi evidente come sia necessario avere delle metriche che consentano di capire costantemente dove ci si trova, confrontando l’attuale situazione con quella di riferimento;
  • Processi (Processes). Se si guarda al Value Stream, ovvero al flusso continuo di creazione di Valore, ci si accorge che esso è sempre basato su più processi che devono incastrarsi al meglio per generare il giusto ritmo operativo. Misurarne il grado di efficacia, efficienza e sinergia è sicuramente una delle azioni basilari;
  • Tecnologie (Technologies). Le tecnologie che utilizziamo nel nostro lavoro devono sempre essere di supporto e non devono mai gravare sul contesto complessivo solo per “puro tecnicismo”. Sapere se ci sono di aiuto o se rappresentano un ulteriore vincolo negativo permette di fare opportune considerazioni e scelte specifiche.

Bisogna evidenziare che, generalmente, tutti questi tre elementi sono presenti nelle diverse metriche. Tipicamente uno di essi è dominante mentre gli altri sono di supporto: si crea implicitamente una sorta di “proporzione naturale” che ricorda l’affascinate sezione aurea (anche nota come proporzione divina) spesso ricorrente in natura.

Ma quali sono le metriche più utilizzate e, generalmente, ritenute più significative? Proviamo ad elencarne alcune e ad osservarle più da vicino:

  • Deployment Frequency, è la frequenza di deployment della propria soluzione, organizzata possibilmente in chiave “small batch”. Più il rilascio è frequente, più si riescono ad ottenere feedback rapidi (the second way of devops) che permettono di riallineare le attività in funzione dei reali risultati ottenuti, misurabili in termini di Customer Satisfaction e di Solution Quality;
  • Lead Time, si tratta del tempo che intercorre da quando si accetta di realizzare qualcosa a quando la stessa diventa disponibile per gli utenti. Inutile dire che l’obbiettivo è quello di ridurre il lead time il più possibile, senza però sacrificare la giusta proporzione tra il lavoro e il tempo per la propria vita (sustainable developmen, ottavo principio agile);
  • Process Time (o Cycle Time), è una componente del Lead Time, in quanto misura il “solo” tempo di sviluppo annesso ad una nuova feature. Valgono considerazioni simili al Lead Time;

processtime

  • Failure Rate, è il trend di “fallimento” annesso all’azione di delivery (attenzione: non di deploy, ma di delivery!). L’obiettivo è quello di ridurlo al minimo e creare una valida cultura basata sul valore intrinseco della continuous delivery;
  • Mean Time To Recover (MTTR), è il tempo che intercorre tra un fallimento/problema e la sua risoluzione. Si tratta, in generale, di una metrica utile per capire la capacità del team di affrontare efficacemente una situazione inattesa;
  • Quality of the output (%c/a), è indicativa della qualità della soluzione. Un modo relativamente semplice, ma estremamente valido, di misurarne il valore è quello di chiedere ai propri utenti quante volte sono riusciti ad utilizzare le nuove funzionalità “as-is” senza ulteriori informazioni o aggiustamenti.

La generazione del trend delle diverse metriche è spesso supportata da tool che fanno gathering da più fonti, permettendo anche di fare overlapping per meglio comprendere il contesto complessivo.

La cosa indispensabile è che, indipendentemente da quali metriche che si decida di utilizzare, il trend relativo sia facilmente visibile e comprensibile a tutti i membri del team. Inoltre, è altrettanto fondamentale che esso sia utilizzato per guidare le azioni di improvement e non per controllare o valutare il team dall’esterno.

Ricordate: senza metriche è come volare alla cieca… questo è un fatto, non un’opinione!

flyingblind

Stay tuned J

DevOpsHeroes 2017 e SQL Saturday Parma 2017 alle porte

Settembre, un mese il cui inizio segna la partenza di tante cose. I bambini ricominciano la scuola, le aziende iniziano a riconsiderare investimenti, i progetti e gli eventi tornano a bussare alle nostre porte.

Come sapete, io amo veramente creare progetti ed organizzare eventi. Ma in questo post voglio focalizzarmi sui nostri due appuntamenti fissi e su quanto io sia veramente orgoglioso dei risultati degli ultimi quattro anni. Il tutto è stato possibile grazie alle community, agli sponsor, agli aiutanti presso le location, ai miei collaboratori. Ho organizzato per quattro anni i SQL Saturday di Parma, dal 2014 al 2016, trasformando la nostra piccola cittadina in una città firmata SQL Server. Chi l’avrebbe pensato possibile? Beh, a onor del vero, io ci speravo, ma un risultato come quello ottenuto nel tempo, no di certo. Il fallimento, quando si affrontano “missioni” come queste, è sempre dietro l’angolo. E invece, è partito come una “quest” da RPG per arrivare al SQL Saturday che conosciamo, che batte i record di presenza e che dimostra quanto Parma e i suoi cittadini siano vicini alla tecnologia e condividano la voglia di vivere una giornata di esperienze tecnologiche comuni. Una cosa di cui sicuramente andare fieri!

LocandinaSqlSaturdayParma2017

Tuttavia, due anni fa, ho sentito la necessità di creare un nuovo evento, che avesse la finalità di portare un nuovo modo di pensare l’IT ed i ruoli (almeno, all’epoca non andava tanto di moda in Italia, per quanto vedevo anche nelle mie esperienze professionali da consulente). Ed è stato proprio il periodo in cui il termine DevOps si è fatto sentire. Il problema era trasformare una buzzword ricca di rumori e di errati accostamenti concettuali in un termine che esprimesse profondamente una cultura, un modo di lavorare e di vivere in azienda, un approccio fondamentale non solo operativo. Combinando la mia passione per i Simpson (soprattutto per Homer) e DevOps, mi sono inventato DOH (esclamazione di Homer) ovvero DevOpsHeroes. E oggi, per il secondo anno consecutivo, le figure della parte Operation, i DBA, i PMO, i Developer verranno a Parma a condividere le proprie esperienze, relativamente a metodologie applicate, integrazione e cooperazione tra persone, al fine di rendere l’IT un’entità più produttiva ed efficiente, ma senza perdere di vista la qualità.

DOH_logo

Dopo l’introduzione, lasciatemi indicare i dettagli dei due eventi, dal più vicino al più distante nel tempo:

DevOpsHeroes 2017 – Parma (http://www.devops-heroes.net/)

Sql Saturday 2017 – Parma (http://www.sqlsaturday.com/675)

  • Data e Location: Saturday, 18th November @ Univeristy of Parma
  • Hashtag: #SQLSAT675
  • Costo di ingresso: free
  • Durata: dalle 8 (registrazione fino alle 9) alle 18.30
  • Registrazione: https://www.sqlsaturday.com/675/registernow.aspx
  • Durante la registrazione:
    • Utilizzerete SpeedPASS
    • Riceverete il lunch ticket
    • Riceverete il welcome kit
  • Lingue: ITA/ENG 

Cosa il futuro ci riserverà in materia di eventi a Parma? Potrei aggiungere un evento IoT, ad esempio, visto che giocando con Raspberry Pi3 e con i ragazzi di Agile@School, mi sono fatto un’idea di come il mondo si muoverà a breve (devo essere pronto anche col mio piccolo Giulio eh, io avevo i lego, lui chissà cosa avrà, oltre a quelli ovviamente  )

Oppure potremmo aggiungere un format, come un evento TED ad esempio. Chi lo sa! Tuttavia credo che avrò tutto l’aiuto possibile, così come quest’anno è successo. Sono partito praticamente da solo il primo anno e oggi siamo sei. Ancora una cosa di cui essere orgogliosi.

Stay tuned! 

Il primitivo istinto del modello perpetuo

… quindi siamo d’accordo: disegniamo il processo agile e poi attiviamo il coaching per farlo seguire!!!

Ecco una frase che negli ultimi tempi mi è capitata spesso, così come spesso, alla mia evidenza che tale approccio è tutt’altro che consono ad una trasformazione Agile, la stessa è stata rafforzata da affermazioni come: “… eh… ma noi non possiamo dire al management che sperimenteremo… abbiamo bisogno di certezze”.

Ovviamente, in tali condizioni è estremamente difficile riuscire a portare avanti la propria azione di coaching, perché i vincoli posti sono tali da trasformare l’Agilità in un modello definito su carta che poi viene “calato dall’alto” sui team.

Per quanto sia comprensibile che venga richiesto una sorta di blue print da seguire, quello che risulta assolutamente inconciliabile con una radicale Agilità è la miopia associata all’istinto di pensare che il modello sia lo scopo e non uno strumento che indirizza le azioni di ricamo di possibili scelte nel proprio contesto. Lo scopo, lo sottolineo, è quello di creare un’organizzazione in grado di adattarsi continuamente alle nuove esigenze di mercato, assecondando sempre i bisogni dell’utente e, se possibile, andando oltre le sue aspettative (the WOW moment!).

L’approccio orientato al modello porta ad un falso positivo, in cui l’azienda è convita di essere Agile perché… “…abbiamo adottato il modello Spotify” o ancora “…siamo in attesa che uno specialista DevOps ci disegni il flusso aziendale da seguire in modo da stare tranquilli!”, errori perpetui che affliggono soprattutto le grandi organizzazioni, andando a consumare risorse ingenti senza ottenere risultati apprezzabili.

Un coach, o comunque un consulente Agile, che, senza minimamente conoscere il contesto e senza confrontarsi con le Persone che lo caratterizzano, suggerisca a “freddo” un modello, un framework o una metodologia, dovrebbe riflettere sulla sua idea di Agilità, evitando di creare false sicurezze che spesso portano ad affermazioni del tipo: “mah.. questo Agile alla fine non si può fare” oppure “tutto sommato non è che sia cambiato molto”.

agile coach path

Certo, utilizzare modelli (o framework) per comunicare una visione è estremamente utile, ma l’attenzione deve essere nel creare un’organizzazione Agile partendo dall’essenza che la caratterizza e sfruttare gli strumenti e l’esperienza per individuare un plausibile percorso che dovrà sempre e comunque essere empiricamente validato.

Allora si, che possiamo parlare di Business Agility ed essere fiduciosi di vederne i risultati.

 

mrpoppo ba noelevator

stay tuned J

Il Verbo autoctono della conoscenza semantica

Il cambiamento è una necessità, non un’opzione.

Si tratta di un dato di fatto, che viene evidenziato giornalmente in tutti i contesti produttivi ed operativi. Ma la cosa più interessante è che affermazioni comuni come: “difficile che possiamo cambiare”, oppure “la nostra organizzazione è così imbrigliata dalla burocrazia che tutto questo è praticamente impossibile”, perdono completamente di significato nel momento stesso in cui vengono dette perché proprio chi lo sta dicendo sta cambiano contestualmente.

Eh si.. il cambiamento è continuo (anche mentre state leggendo questo post J), modificando implicitamente o esplicitamente i nostri comportamenti, la nostra percezione della realtà.

Quello che realmente è difficile, è trasformare questo “micro cambiamento” in azioni concerete che hanno un impatto significativo e duraturo nella nostra organizzazione: bisogna esserne fortemente convinti e avere un supporto pressoché totale.

Spesso a bloccare gli ingranaggi sono i Manager che dovrebbero trasformare le strategie di business in Programmi attuativi. Proprio in questo ambito si insidia la sfida più grande per chi è chiamato a supportare o trainare un’azione di cambiamento olistico.

Le aziende hanno bisogno sempre meno bisogno di Manager “tradizionali” e sempre più di Leader che creano un contesto “sicuro” in cui le persone sono spronate a sperimentare costantemente, serene di poter fallire per apprendere e dare, progressivamente, nuova linfa alla Cultura aziendale.

leader mindset

E questo vale in ugual misura per i Manager: un Manager che non sbaglia mai è un Manager che non contribuisce a costruire i nuovi pilastri competitivi dell’organizzazione per cui lavora, creando un “Cultural Debt” che l’organizzazione pagherà a caro prezzo.

Un Manager “illuminato”, meglio ancora un Leader, crea proprio la safety web per permettere ai suoi collaboratori (mai sottoposti!) di sperimentare velocemente, mentre un Manager “poco illuminato” ritiene che la conoscenza gli sia stata “affidata”, che il verbo sia autoctono e che, in fondo, se fino ad ora le cose hanno funzionato, in qualche modo, si può continuare in quella direzione senza preoccuparsi dei cambiamenti in atto.

I nuovi Manager (Leader) devono avere una mission diversa da quella di “tagliare i costi”, che deve invece diventare quella di “creare le condizioni per una sostenibilità del business e per una sua crescita”.

Le organizzazioni sono complesse, così come il Mercato è complesso, e questo non consente di sedersi dietro una scrivania e comportarsi come accadeva nella prima metà del secolo scorso crogiolandosi dietro la conoscenza semantica da manuale, ma bisogna valorizzare i propri punti di forza, accettando giornalmente la sfida del cambiamento.

 Genchi Genbutsu!