Category Archives: TFS

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!

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

Agile@School – Questa è la fine, per quest’anno

Tutte le buone cose hanno una fine, giusto? Il progetto Agile@School 2017 non fa eccezione. Ma nessun problema, abbiamo una grande notizia! Fra poco diventerò papà, e non posso sapere quanto tempo potrò investire in progetti come questi (anche se, di certo, non mi fermerò) ma, a partire dall’anno scolastico 2017/2018, molto probabilmente, avremo nell’equipaggio anche Michele Ferracin, un amico anch’esso membro di GetLatestVersion.it. Michele sta prendendo contatti con le scuole nel comune di Rovigo per portare Agile@School nel nord Italia. Abbiamo raggiunto l’obbiettivo “Portare il progetto in almeno due città” 
Ma le buone notizie non sono finite. Infatti, quest’anno posso dire di aver seguito ragazzi con una passione infinita per l’informatica e le nuove tecnologie. Ma questo lo sapete già, come descritto nel precedente post.
Gli esami di maturità stanno terminando, ma poco prima della fatidica data, gli studenti erano pronti e sul pezzo. Ed ecco cosa è stato presentato:

Software e Tecnologia

Il team Messinesi (Amanda e Alex) hanno preparato una presentazione in Prezi il cui obbiettivo è quello di mostrare gli strumenti coinvolti nello sviluppo della loro chat. In aggiunta, con l’ausilio di più dispositivi (si parla di portatili), la commissione ha potuto provare la loro applicazione real time.


Intelligenza Artificiale e Bot

Il team Random (Thomas e Luca) ed il team The Scrubs (Enea e Sebastiano) hanno creato tre mini pitch video per presentare il loro lavoro, con:

– un’introduzione a mo’ di presentazione (via Prezi e Power point)
– una spiegazione semplice per descrivere le tecnologie usate “dietro le quinte”
– un paio di interviste fatte a sè stessi

IoT

Il team Domotic (Nicodemo e Mattia) e il team Bar Santa (Simone e Mirko) hanno mostrato il funzionamento della loro Smart House e della loro automobile radiocomandata, anche con l’ausilio di questi video:


Cognitive Services

Il team Human Recognizers (Marco e Francesco) ha presentato un mini sito web ed un video di funzionamento dell’applicazione di riconoscimento facciale. Dimostrano come una webcam riconosce l’umore e le facce, partendo anche da una foto. Il tutto con un’applicazione mobile.


Questa è la loro presentazione Prezi.

Come avete potuto constatare, tutti hanno lavorato veramente bene. E questo è il diploma di quest’anno, come attestato della fine del progetto:


Quest’anno abbiamo raggiunto degli ottimi risultati e noi “coach” siamo veramente fieri del lavoro svolto insieme. Abbiamo anche chiesto un sondaggio, per carpire il gradimento del progetto:


Ed ora, un grosso “in bocca al lupo” a tutti i ragazzi, perchè l’esame passato è solo il primo che affronteranno! 

Stay tuned 

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