Author Archives: Felice Pescatore

I Grandi precursori dell’Agile: Giovanni Borghi e le visite al Gemba della sua Ignis

Lean, Agile, PMBok, attenzione alle Persone, socialità, Valori, sono il pane quotidiano di chi è professionalmente impegnato nello sviluppo di una organizzazione efficiente ed efficace, in grado di competere con le sfide odierne.

Eppure, troppo spesso ci dimentichiamo come tante delle pratiche che oggi diamo per innovative, risultano spesso tali solo perché dimenticate o affogante in una burocrazia che ha tentato negli anni di trasformare le persone in “macchine banali”, senza lontanamente riuscirci.

Rileggendo alcune delle biografie dei grandi pionieri dell’industria italiana, si scopre che i nostri Imprenditori (notare la “I” minuscola non causale) della metà del secolo scorso avrebbero tanto da insegnare a quanti oggi professano soluzioni miracolose provenienti da chissà dove.

Ho maturato la convinzione che può essere culturalmente interessante, se non anche stimolante, raccontare atteggiamenti o episodi dei grandi Imprenditori del passato nostrani che erano Agili prima dell’invenzione dell’Agile. 

Motivo per cui ho immaginato una serie di post, di cui questo è il primo, in cui racconterò delle pillole in merito.

Come primo grande Imprenditore del passato ho pensato a Giovanni Borghi, mr. Ignis, un personaggio probabilmente poco noto ai contemporanei, ma che è stato un esempio di come l’intuizione, la perseveranza e l’impegno costante siano in grado di creare realtà industriali capaci di conquistare primati a livello europeo ed oltre.

Rileggendone la biografia, mi è subito saltato all’occhio un comportamento che, in varie forme e declinazione, spesso, come coach, suggeriamo ai manager di attuare: recarsi negli ambiti operativi, ovvero essere presenti dove le cose prendono forma.

mister ignis

Borghi aveva questa sana abitudine: ogni giorno prendeva la sua bicicletta e si recava nello stabilimento produttivo di Comerio (Varese) dove venivano prodotti i famosi frigoriferi della casa del fuoco (significato di “Ignis”, nome adottato quando la società produceva esclusivamente fornelli elettrici, prima, e a gas, dopo). Il “Cummenda” osservava con attenzione le diverse fasi del processo produttivo, fino ad arrivare a contemplare il prodotto finito, cosa che gli procurava una forte soddisfazione per aver trasformato qualcosa di grezzo, inutile al consumatore finale, in qualcosa che stava diventando fondamentale nella vita di tutti i giorni.

Proprio grazie a questa oculata osservazione sul campo, mr. Ignis rifletteva continuamente su come migliorare i propri prodotti ed i processi annessi, pur essendo impegnato in una espansione quasi senza precedenti per un’azienda del nostro Paese.

Ecco il punto: coinvolgere attivamente i manager, o responsabili che si voglia, nelle attività concrete, fornendo loro una vista di contesto e non da manuale.

Proprio questa è l’essenza del Gemba Walk, in cui le “visite” avvengono regolarmente per osservare, ascoltare e ipotizzare nuove azioni di miglioramento in chiave Kaizen, concretizzando il pensiero Lean secondo cui al miglioramento non c’è mai fine e la perfezione assoluta non esiste.

gembawalking

Gemba Walk

Le origini del Gemba Walk si fanno risalire all’azione nota come Genchi Genbutsu, letteralmente “vai e guarda”, attuata dal papà del Toyota Production System, ovvero Taiichi Ohno.

Si racconta, quasi a mo’ di legenda, che Ohno girasse sempre con un gessetto nella fabbrica e quando qualcosa non gli tornava, disegnava a terra un cerchio e chiedeva al suo collaboratore afferente di entrarci, di osservare quanto stesse accadendo, di prendere appunti e di proporre dei miglioramenti. Ohno obbligava la persona a restare nel cerchio finché non era soddisfatto delle risposte.

Un approccio simile si sviluppa, in modo indipendente, negli anni ’70 in HP ed è noto con il nome di MBWA: Management by Walking About, ovvero management pratico fondato sul contatto diretto stretto con i dipendenti. 

L’acronimo nasce comunque anni dopo, nel 1982, grazie a Thomas J. Peters e Robert H. Waterman che ne parlano nel libro “In Search of Excellence: Lessons from America’s Best-Run Companies”, e sottolineano come, in perfetta sintonia con il Gemba Walk, non si tratti di un’azione di “controllo”, ma di un’azione al supporto del miglioramento continuo.

Ecco il punto: per migliorare realmente le cose bisogna essere in grado di capirne i meccanismi portanti e sporcarsi anche le mani se necessario.

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso – pt.3

Flex (Flow for Enterprise Transformation) è sicuramente una delle novità più corpose dell’evoluzione di Disciplined Agile.

Può essere visto come l’anima dinamica di DA, in quanto si concentra sullo sviluppo di un Value Streamricamato sulle necessità degli stakeholder, o cliente che sia, abbracciando un mindset chiaramente Lean che suggerisce di concentrati sulla gestione del flusso di lavoro e non su come gestire le persone o il lavoro.

da flex 2020

DA Flex

Flex parte dall’ovvia considerazione che una soluzione preconfezionata non può andar bene per tutti, e che la contestualizzazione è fondamentale per evitare brutte sorprese e resistenze continue: “Fit for purpose” is the greatest measure of “simple.” (la capacità di adattamento allo scopo è la più importante misura di semplicità).

Questo, però, non vuol dire partire ogni volta da zero perché, concettualmente, i passi essenziali per l’implementazione efficace di un Value Stream sono spesso molto simili tra loro, quello che cambia è come vengono implementati singolarmente.

Scopo di Flex è proprio quello di fornire un archetipo che consenta di procedere più speditamente, e sfruttare le forti doti di contestualizzazione di DA per consentire l’implementazione specifica dei vari passi contemplati.

Rispetto alla una prima fase di integrazione (o forse meglio dire annessione, che potete trovare descritta qui), oggi Flex è maggiormente integrato con i (nuovi) Blade di DA, il che lo rende uno strumento molto adatto a creare un’organizzazione “customer centric” che guarda al flusso complessivo di realizzazione di una o più iniziative di business.

Ogni “work center” del Value Stream è associato ad uno specifico Blade che, come abbiamo visto nei precedenti articoli, rappresenta un ecosistema coeso di azioni, relazioni, informazioni e process goal atti a supportare la guided continuous improvement.

Si parte dagli stakeholder per tornare agli stakeholder” è questa la vera anima di Flex.

Lungo il cammino troviamo:

  • Portfolio Management
  • Product Management
  • Program Management (se presenti più team da coordinare)
  • Disciplined Agile Delivery
  • Release Management
  • Business Operation

che non descriviamo di nuovo perché ne abbiamo già parlato, così come i Blade presenti al “centro dell’ellisse” che sono di supporto trasversale, a partire da quello, ovvio, di Continuous Improvement e di Governancepassato per Security, IT Operation e Support.

Una cosa interessante da osservare è l’attenzione posta sul concetto di MBI (Minimum Business Increment), ovvero la quantità minima di valore da costruiredistribuire ed utilizzare in modo che l’iniziativa abbia effettivamente senso dal punto di vista aziendale. 

In tale ottica, Flex spinge a guardare sempre la sostenibilità aziendale di un’iniziativa e non solo il valore intrinseco delle singole funzionalità da rilasciare, supportando un approccio strategico al rilascio continuo.

L’MBI è un concetto interessante e fondamentale per capire cosa mettere in sviluppo, e non va confuso con l’MVP (Minimum Viable Product) che viene inteso da Disciplined Agile nell’accezione originale (Lean Startup), ovvero come la quantità più piccola di lavoro da fare per validare una ipotesi e non l’insieme minimo di prodotto da distribuire.

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso – pt.3

Flex (Flow for Enterprise Transformation) è sicuramente una delle novità più corpose dell’evoluzione di Disciplined Agile.

Può essere visto come l’anima dinamica di DA, in quanto si concentra sullo sviluppo di un Value Streamricamato sulle necessità degli stakeholder, o cliente che sia, abbracciando un mindset chiaramente Lean che suggerisce di concentrati sulla gestione del flusso di lavoro e non su come gestire le persone o il lavoro.

da flex 2020

DA Flex

Flex parte dall’ovvia considerazione che una soluzione preconfezionata non può andar bene per tutti, e che la contestualizzazione è fondamentale per evitare brutte sorprese e resistenze continue: “Fit for purpose” is the greatest measure of “simple.” (la capacità di adattamento allo scopo è la più importante misura di semplicità).

Questo, però, non vuol dire partire ogni volta da zero perché, concettualmente, i passi essenziali per l’implementazione efficace di un Value Stream sono spesso molto simili tra loro, quello che cambia è come vengono implementati singolarmente.

Scopo di Flex è proprio quello di fornire un archetipo che consenta di procedere più speditamente, e sfruttare le forti doti di contestualizzazione di DA per consentire l’implementazione specifica dei vari passi contemplati.

Rispetto alla una prima fase di integrazione (o forse meglio dire annessione, che potete trovare descritta qui), oggi Flex è maggiormente integrato con i (nuovi) Blade di DA, il che lo rende uno strumento molto adatto a creare un’organizzazione “customer centric” che guarda al flusso complessivo di realizzazione di una o più iniziative di business.

Ogni “work center” del Value Stream è associato ad uno specifico Blade che, come abbiamo visto nei precedenti articoli, rappresenta un ecosistema coeso di azioni, relazioni, informazioni e process goal atti a supportare la guided continuous improvement.

Si parte dagli stakeholder per tornare agli stakeholder” è questa la vera anima di Flex.

Lungo il cammino troviamo:

  • Portfolio Management
  • Product Management
  • Program Management (se presenti più team da coordinare)
  • Disciplined Agile Delivery
  • Release Management
  • Business Operation

che non descriviamo di nuovo perché ne abbiamo già parlato, così come i Blade presenti al “centro dell’ellisse” che sono di supporto trasversale, a partire da quello, ovvio, di Continuous Improvement e di Governancepassato per Security, IT Operation e Support.

Una cosa interessante da osservare è l’attenzione posta sul concetto di MBI (Minimum Business Increment), ovvero la quantità minima di valore da costruiredistribuire ed utilizzare in modo che l’iniziativa abbia effettivamente senso dal punto di vista aziendale. 

In tale ottica, Flex spinge a guardare sempre la sostenibilità aziendale di un’iniziativa e non solo il valore intrinseco delle singole funzionalità da rilasciare, supportando un approccio strategico al rilascio continuo.

L’MBI è un concetto interessante e fondamentale per capire cosa mettere in sviluppo, e non va confuso con l’MVP (Minimum Viable Product) che viene inteso da Disciplined Agile nell’accezione originale (Lean Startup), ovvero come la quantità più piccola di lavoro da fare per validare una ipotesi e non l’insieme minimo di prodotto da distribuire.

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso – pt.2

Nel precedente post abbiamo cominciato a parlare di come Disciplined Agile si stia rapidamente evolvendo per rispondere sempre più adeguatamente alla sfida di sviluppare la Business Agility all’interno di contesti enterprise.

Dopo aver visto l’evoluzione del toolkit in termini di aree di riferimento, diamo uno sguardo a quelle che sono le novità rispetto ai Process Blade, ovvero i nuovi Blade introdotti e le modifiche apportate a quelli esistenti.

Ricordiamo che i “Blade” sono delle aree di operatività auto-consistenti che interessano azioni specifiche, come ad esempio IT ed HR. Il nome deriva dalla similitudine con i Blade Server (computer server) pensati per essere auto-contenuti e sostituibili all’occorrenza, in perfetta sintonia con il principio “Choice is Good”.

Partiamo dall’evoluzione dei Balde esistenti, sintetizzata dalla figura seguente:

da new blades1

Process Blades evolutions

Come avevamo già accennato nel precedente post, la modifica più evidente è rispetto a DAD che smette di essere un layer e diventa un Process Blade di Disciplined DevOps. La modifica è naturale e dovuta, in linea con l’evoluzione attuale dello sviluppo IT, chiarendo inoltre un punto ambiguo della rappresentazione precedente.

Le altre evoluzioni sono:

  • Governance, frutto della fusione tra IT Governane (leadership, strutture organizzative e semplificazione dei processi) e Control (collaborazione con le aziendali);
  • Information Technology, che raccoglie le specificità del precedente layer DAIT; 
  • Vendor Management, sostituisce e rende attuale le funzionalità di Procurement;
  • Program Management, non subisce modifiche di sostanza (per ora) ma viene spostato a livello di Value Stream, mentre prima era identificato come un lifecycle in DAD;
  • Asset Management, che estende le azioni di riuso a 360gradi, inglobando il precedente Reuse Engineering.

Per quando riguarda i nuovi Blade, abbiamo invece:

da new blades2

 New Process Baldes

  • Research & Development, dedicato alle attività di R&D e in gestazione da oltre un anno;
  • Strategy, basato su Brightlinee finalizzato a supportare gli executive nel colmare il divario tra pianificazione strategica e delivery;
  • Transformation, per il supporto al cambiamento organizzato e fusione dei relativi aspetti di DA, Flex e Brightline.

Come si può intuire molte cose sono in evoluzione e le chiariremo nelle settimane a venire, mentre nel prossimo post daremo uno sguardo all’evoluzione e combinazione di Flex con i diversi Process Blade.

 

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso

Come più volte ribadito, Il Disciplined Agile toolkit è in continua evoluzione e l’ingresso nella famiglia del PMI ha accelerato questo percorso.

Nel post precedente abbiamo raccontato il mindset con cui oggi esso viene presentato e che ne costituisce il cuore relazionale, grazie ai tre pillar di riferimento: PrincipiPromesse e Linee Guida.

Descriveremo ora come si sta trasformando il DA Poster che rappresenta, di pari passo, lo strumento per inquadrare le strategie di azione nelle diverse aree dell’organizzazione.

Fino ad ora il poster di riferimento è stato il seguente:

da poster

Previous DA Poster

Mentre da poco ne è stato resa pubblica la nuova versione che porta in dote profondi cambiamenti e migliorie:

da poster new

The Disciplined Agile Toolkit

Il perimetro dei diversi layer è stato ridisegnato per meglio descriverne l’animo enterprise di DA e la vocazione di “collante” che da sempre lo caratterizza rispetto all’ecosistema agile e lean in continua espansione.

I nuovi layer di riferimento (frutto di evoluzione, e non rivoluzione) si fondano tutti sul Foundation Layer, andando a mettere a fattore comune tutti quegli aspetti che sono il cuore pulsante del toolkit, allineandolo con il nuovo mindset di riferimento. Per meglio comprendere ciò, si pensi, ad esempio, ai Ruoli che precedentemente erano fortemente concentrati nel layer DAD e sparsi nei diversi Blade, mentre ora sono esplicitati in modo indipendente.

A sua volta DAD non è più un “layer”, ma diventa il Blade centrale del layer Disciplined DevOps, ottenendo due risultati rilevanti: si fa chiarezza sul fatto che i lifecycle non sono blade e si enfatizza che gli stessi non possono più essere considerati in modo separato rispetto all’azione complessiva di sviluppo e deploy.

Il precedente layer Disciplined Agile IT (DAIT) lascia il posto al Value Stream layer, frutto dell’integrazione profonda con FLEX.

da value stream

 DA Value Stream layer

L’obiettivo è quello di focalizzarsi in modo esplicito sul cliente, spostando l’attenzione ad una visione meno incentrata. 

Infine, implicitamente, anche il layer più esterno Disciplined Agile Enterprise evolve di conseguenza, arricchendosi comunque di alcuni nuovi blade e contando sull’evoluzione di alcuni già esistenti.

 

Nel prossimo appuntamento esploreremo proprio come si stanno evolvendo i blade preesistenti e i nuovi blade introdotti.

Stay tuned J

PMI Disciplined Agile: la promessa, la svolta e il prestigio

Non siamo neanche riusciti a terminato il percorso di descrizione di Disciplined Agile, che Ambler e Lines hanno dato vita ad un aggiornamento del toolkit. Come più volte detto, la cosa deve però solo stimolarci, non certo disturbarci, perché significa che il toolkit è vivo e vegeto e si evolve continuamene in chiave kaizen, a piccoli, ma significativi passi.

L’evoluzione è principalmente concentrata nella struttura del toolkit stesso, a partire dalla descrizione del mindset e dal poster. In questo post ci concentreremo sul mindset, dedicando il successivo al poster.

Devo dire che quando ho letto la parte del nuovo libro (libro) che descrive il mindset, mi è subito venuto in mente il film The Prestige, in cui, all’inizio, uno scenografo esperto di illusionismo pronuncia questa frase illuminante a proposito dei giochi di magia:

“Ogni numero di magia è composto da tre parti o atti. La prima parte è chiamata “la promessa”. L’illusionista vi mostra qualcosa di ordinario: un mazzo di carte, un uccellino o un uomo. Vi mostra questo oggetto. Magari vi chiede di ispezionarlo, di controllare che sia davvero reale… sì, inalterato, normale. Ma ovviamente… è probabile che non lo sia. […] Il secondo atto è chiamato “la svolta”. L’illusionista prende quel qualcosa di ordinario e lo trasforma in qualcosa di straordinario. Ora voi state cercando il segreto… ma non lo troverete, perché in realtà non state davvero guardando. Voi non volete saperlo. Voi volete essere ingannati. Ma ancora non applaudite. Perché far sparire qualcosa non è sufficiente; bisogna anche farla riapparire. Ecco perché ogni numero di magia ha un terzo atto, la parte più ardua, la parte che chiamiamo “il prestigio”

Questo, in particolare, per la presenza del pillar “Promises”, ovvero l’impegno concreto che prende un “Agilista Disciplinato” nei riguardi del proprio team e dell’intera organizzazione. Ma è interessane come il toolkit abbia un ruolo proprio come quello dello scenografo di cui sopra: rendere espliciti i “trucchi”, e sfatare il mito che un framework o una metodologia, o una pietra filosofale che si voglia, possa essere la soluzione per ogni problema. Lo ribadisco da sempre: “Persone ed Iterazioni, più che processi e tool”, le organizzazioni sono fatte di Persone e queste sono la vera ricchezza delle stesse.

Ma torniamo al Disciplined Agile Mindset:

da mindset

The Disciplined Agile Mindset

Il DA Mindset è strutturato in 3 pillar: PrincipiPromesse e Linee Guida:

“Ci piace dire che crediamo in questi otto principi, quindi promettiamo l’un l’altro che lavoreremo in modo disciplinato e che seguiremo un insieme di linee guida che ci consentiranno di essere efficaci”

Vediamoli nel dettaglio:

  • I Principi, che guidano le azioni di un Disciplined Agile: Delight customers, Be awesome, Context counts, Be pragmatic, Choice is good, Optimize flow, Organize around products/services, Enterprise awareness. Sui principi non ci soffermiamo, visto che ne abbiamo già parlato abbondantemente qui, tranne se non per evidenziare che sono diventati 8, avendo aggiunto Organize around products/services, che pone il focus sullo stream di lavoro annesso ad un prodotto/servizio e frutto dell’integrazione con FLEX.
  • Le Promesse, ovvero l’impego che i “Disciplined Agilist” si assumono nell’adottare comportamenti che consentono loro di lavorare in modo più efficace:

    • Create psychological safety and embrace diversity, avere la possibilità di esprimersi, non solo in senso lavorativo, senza la paura delle conseguenze negative sullo status, sulla carriera o sulla propria autostima: bisognerebbe sempre sentirsi a proprio agio nell’ambiente lavorativo.
    • Accelerate value realization, migliorarsi costantemente per accelerare la creazione di valore.
    • Collaborate proactively, l’impegno di un “Agilista Disciplinato” è quello di sforzarsi a creare valore aggiunto in ogni sua azione, non solo rispetto alle attività individuali o quelle del team di cui fa parte.
    • Make all work and workflow visible, tutto il lavoro è costamene e trasparentemente visibili a tutti, così come il way of workingdel team.
    • Improve predictability, i team si sforzano di migliorare la predicibilità delle proprie attività, per consentire la collaborazione e l’auto-organizzazione in modo più efficace. In tal modo si aumentano le possibilità di assumersi impegni sostenibili nei confronti degli stakeholder.
    • Keep workloads within capacity, le attività su cui il team si ingaggia sono sempre bilanciate in relazione alla sua reale capacità contestuale.
    • Improve continuously, un team DA si impegna costantemente a individuare e sperimentare nuovi modi per migliorare i processi e il proprio way of working.
  • Le Linee Guida, che suggeriscono azioni concrete da mettere in campo:

    • Validate our learnings, l’unico modo per diventare “fantastici” è sperimentare ed adottare, se la sperimentazione ha dato esiti interessati, nuovi modi di lavorare in sinergia.
    • Apply design thinking, entrare in empatia con il cliente, ovvero provare a capire il suo ambiente e le sue esigenze prima di sviluppare la soluzione. 
    • Attend to relationships through the value stream, le interazioni tra le persone coinvolte in tutta la filiera produttiva (e non solo) sono fondamentali, indipendentemente dal fatto che facciano parte o meno del team specifico.
    • Create effective environments that foster joy, una strategia chiave, per raggiungere un ambiente sereno e piacevole, è quella di consentire ai team di auto-organizzarsi, scegliendo il proprio WoW (e come farlo evolvere), la struttura organizzativa e gli ambienti di lavoro stessi.
    • Change culture by improving the system, per migliorare costantemente un sistema, è fondamentale far evolvere sia le sue componenti, sia in senso assoluto che nelle interazioni relative tra esse.
    • Create semi-autonomous, self-organizing teams, anche se i team autonomi sarebbero l’ideale, bisogna sempre ricordarsi che ci saranno sempre dipendenze da altri team, sia a monteche a valle.
    • Adopt measures to improve outcomes, per sapere se si sta migliorando è fondamentale che i team scelgano ed utilizzino metriche che consentano di fornire approfondimenti su come stanno andando le cose, fornendo visibilità del tutto.
    • Leverage and enhance organizational assets, i team devono essere liberi non solo di adottare risorse pre-scelte (tipo tools), ma anche di scoprire come migliorarle, per se stessi e per gli altri, e sperimentare di nuove.

Come si può intuire, il mindset Disciplined Agile fornisce un ecosistema di base da cui iniziare, evidenziando come sia fondamentale non solo “essere agili”, ma anche “fare agile”, ovvero avere gli strumenti che permettono di concretizzare quanto promesso già dal Manifesto Agile: 

è meraviglioso avere persone che vogliono lavorare in modo collaborativo e rispettoso, ma se poi non sanno come farlo, non faranno molta strada! 

Ricordo, per chi è interessato ad approfondire DA ed avviare anche un percorso di certificazione, che è ancora possibile iscriversi al prossimo virtual workshop del 6 e 7 maggio.

 

Stay tuned J

PMI Disciplined Agile: FLEX, Flow for Enterprise Transformation (pt.7)

Siamo giunti all’ultimo appuntamento di questa serie esplorativa di PMI Disciplined Agile, in cui abbiamo visto come il framework creato da Scott Ambler e Mark Lines può supportare pragmaticamente il percorso di Business Agility di una organizzazione.

La strategia del PMI in ambito Agile, oltre a contemplare l’acquisizione di Disciplined Agile, ha anche interessato il framework Flex e il Brightline Transformation Compass. Quest’ultimo va oltre il focus di questa serie, mentre Flex è attualmente in integrazione proprio con Disciplined Agile, per cui è importante capire cosa rappresenta nell’ecosistema DA.

In modo molto sintetico possiamo dire che se i process blade sono le fondamenta “statiche” di riferimento per la trasformazione Agile, Flex è il motore “dinamico” che permette di tracciare un flow, sia evolutivo che operativo, per sviluppare ed ottimizzare il Value Stream.

Abbiamo più volte citato il concetto di Value Stream, senza mai soffermarci su di esso: si tratta dell’insieme delle azioni necessarie per generare valore per il cliente, dalla richiesta iniziale fino alla sua concretizzazione. Il tutto inizia con il concept iniziale, attraversa varie fasi in cui sono coinvolti più team di lavoro (generalmente Agili/Lean) e prosegue fino alla consegna e al supporto finale.

Un Value Stream inizia e termina con un cliente.

da flex value stream

The Value Stream

DA FLEX ha proprio l’obiettivo di ottimizzare questo flusso, indipendentemente dalle dimensioni dell’organizzazione o se ad essere coinvolta è solo una parte di essa. Il framework, originariamente messo in bella copia da Al Shalloway, è sviluppato sulla base dei principi di Flow-ThinkingLean-Thinking, e la Theory of Constraints, trovando la sua essenza in gruppi di pattern che risolvono problemi ricorrenti nei diversi contesti. La filosofia di fondo si lega alle “leggi naturali dello sviluppo di un prodotto” (natural laws of product development), ovvero quegli aspetti capaci di influenzarci indipendentemente dal fatto che ci occupiamo o meno di loro. 

FLEX sviluppa il Value Stream sinergicamente con i process blades di DAD e Disciplined DevOps, in abbinamento ad alcuni di quelli specifici di DAIT e DAE, e si sviluppa come evidenziato dalla figura seguente:

da flex

FLEX

Visibilmente si individuano, quindi, esplicitamente le seguenti aree di impatto:

  • Strategic Planning e Lean Portfolio Management, ovvero l’area strategica in cui vengono convogliati i goal aziendali derivanti il più possibile dai clienti di riferimento. Qui vengono coinvolti i responsabili di alto livello (CxO) che si confrontano per dar vita alle Iniziativeda perseguire a medio/lungo termine, tipicamente quarter.
  • Lean Product Management, l’obiettivo è quello di declinare (decomporre) le Iniziative in una serie di obiettivi da poter rilasciare velocemente in modo incrementale. Vengono coinvolte le prime linee operative (PO, PM, BA, ecc..) al fine di ottenere, primariamente, un insieme di MBI(Minimum Business Increment) ed eventuali MVP(Minimum Viable Product).
  • Development Intake Process, viene individuato e selezionato un processo di gestione dello sviluppo ben definito, in modo che il lavoro si concentri sugli elementi a maggior valore.
  • Planning, Collaboration, and Dependency Management, orientata a definire lo sviluppo a breve termine e il relativo valore puntuale di riferimento, oltre ad individuare esplicitamente le dipendenze che possono metterne a rischio l’obiettivo.
  • Implementation and Integration, le attività sono in carico a team auto-organizzati, che lavorano secondo la cadenza più idonea e integrano costantemente il risultato delle attività.
  • Release and Realization, le attività tipiche di operationmarketingsupportsono essenziali per “trasferire” all’utente la qualità ed il valore di quanto realizzato.
  • Continuous Improvement, centrata sul ciclo PDSA (Plan, Do, Study, Act), spinge al miglioramento continuo basato sulle evidenze.

La parte di Implementation ed Integration può chiaramente scalare ed interessare più team paralleli, dedicati ad iniziative diverse (ma anche alla stessa), creando necessità di allineamento e gestione delle dipendenze.

da flex multiteam

FLEX multi-team

Interessante evidenziare che il flow mette implicitamente in evidenza la necessità di operare in chiave Disciplined DevOps, in modo da favorire una scorrevolezza nell’ultimo miglio una volta completati gli MBI su cui si è ingaggiati.

da flex devops

FLEX e DevOps

FLEX non ha, come tra l’altro l’intero toolkit DA, la pretesa di fornire una soluzione, ma piuttosto suggerisce un modo per esaminare i problemi e supportare la riduzione dei principali fattori di complessità:

  • Carico di lavoro relazionato all’effettiva capacità del team
  • Efficienza dei flussi
  • Batch Size
  • Livello di collaborazione
  • Ruolo del management
  • Gestione della pianificazione 
  • Qualità del prodotto

L’obiettivo è sviluppare la cosiddetta in’“Inherent simplicity”.

In particolare, uno degli elementi introdotti esplicitamente da FLEX è il già citato Minimum Business Increment(MBI), ovvero la quantità minima di valore, funzionale al business, che può essere costruitadistribuita e consumata in un intervallo di tempo ridotto. Lo scopo dell’MBI è quello di focalizzarsi sul valore “asciugato” del rilascio, in modo da poter consegnare prima ed efficientare la relazione con il cliente, raccogliendo feedback su quanto realizzato.

L’MBI si differenzia dall’MVP (Minimum Viable Product) perché quest’ultimo utilizza artefatti quick-and-dirty per validare rapidamente un’ipotesi, e generalmente, non è un prodotto ingegnerizzato, ma più una sorta di beta veloce per capire la direzione da prendere.

 

Concludiamo qui questa serie di articoli dedicati all’introduzione del nuovo ecosistema PMI DA. Restano, chiaramente, molti dettagli non esplorati a cui dedicheremo prossimamente articoli specifici, webinar e pillole di contesto.

Stay tuned J

PMI Disciplined Agile: Disciplined Agile Enterprise (pt.6)

Riprendiamo il nostro viaggio attraverso Disciplined Agile, andando ad esplorare l’anello più olistico del toolkit, ovvero: Disciplined Agile Enterprise (DAE).

da f1

Con i process blade di livello DAE, DA supporta lo sviluppo di una organizzazione in grado di abbracciare una Cultura Agile a tutti i livelli, adottando strumenti che le permettono di rispondere rapidamente ai cambiamenti del mercato.  È utile sottolineare, ulteriormente, che le diverse aree di DA vanno intese in senso evolutivo: i benefici tangibili e continuativi si ottengono se esse si sviluppano partendo dal centro (DAD) verso l’esterno (DAE) e non scegliendo solo quello che ci è “comodo”.

Una DAE, in particolare, affronta le sfide di mercato grazie ad una cultura che favorisce il l’apprendimento e l’evoluzione continua, in modo da adattarsi costantemente alle mutevoli esigenze del mercato di riferimento, spesso di tipo VUCA (Volatilità, Incertezza, Complessità e Ambiguità). In questo contesto, DAE si fonda su tre considerazioni primarie:

  • Ogni azienda è un’azienda di software. Tutte le attività produttive moderne sono basate sul software: anche se non si è una software house, senza software non è possibile fare business! Il dipartimento IT non può essere visto come un “centro di costo” da tagliare, emarginare ed esternalizzare, ma deve essere al centro dell’azione aziendale perché tale è il suo compito. Bisogna eccellere nell’IT se si vuole avere un’opportunità di emergere (e sopravvivere) nel proprio settore di riferimento.
  • Nessuno può ritenersi al sicuro. Non esistono più condizioni di monopoli, in nessun settore: da quello bancario a quello delle macchine industriali pesanti. Basta un nuovo competitor innovativo, che rivoluziona l’approccio al mercato o al prodotto, per condannare l’organizzazione all’estinzione. La domanda non è “quando accadrà anche a me”, perché sta già accadendo ora, la questione è decidere se si vuole essere leader o tentare di sopravvivere finché la fine (certa) non arrivi.
  • Le aziende Agili saranno le uniche a sopravvivere. Per rispondere alle sfide moderne, in un mondo complesso, è indispensabile essere adattivi/reattivi/empirici, costruendo la propria visione di agilità. Non esiste un settore dove queste caratteristiche non facciano la differenza, nemmeno uno. 

Nello specifico, quando si arriva a concentrarsi sulle sfide inerenti una DAE, vengono introdotti (come focus) i seguenti process blade:

da dae processblades

DAE Process Blades

ovvero:

  • Business Operations: focalizzato sulle attività necessarie per fornire servizi ai clienti e supportare i prodotti. Tra esse troviamo: l’help desk, i servizi finanziari(bancari e non), le attività di supporto tecnico, ecc. Come è intuibile, nell’ottica di “deliziare” il cliente, è necessaria una stretta collaborazione con le tue attività di vendita e marketing.
  • Control: i team operativi devono collaborare strettamente con le aree finanziarie e legali, in modo da avere consapevolezza delle risorse disponibili e dei vincoli di azione esistenti, mitigando gli ostacoli che si potrebbero incontrare.
  • Finance: la Disciplined Agile Financesi concentra su obiettivi concreti ed essenziali come garantire il flusso di cassaassicurarsi che il budget sia speso adeguatamenterispetto degli obblighi di tassazionetracciamentoe registrazione delle 
  • Legal: lo scopo primario è quello di garantire che l’organizzazione lavori entro il rispetto delle normative vigenti nel territorio in cui opera. Il legal teamlavora, inoltre, alla definizione di “contratti agili” che consentono di estendere l’agilità oltre il perimetro aziendale, in collaborazione con il people management, il marketing, il procurement, ecc. 
  • Marketing: il suo obiettivo è lo sviluppo di interazioni di successo tra l’organizzazione e il mondo esterno. Il marketing si muove “a due vie”: per i clienti, rappresenta l’organizzazione stessa e le sue offerte, per il resto dell’organizzazione, i (potenziali) clienti. In collaborazione con la gestione dei prodotti, il marketing è attivamente coinvolto nella visione a lungo termine delle offerte.
  • Procurement: il suo principale scopo è quello di efficientare il processo di approvvigionamento, aiutando ad ottenere, nei tempi adeguati, prodotti e servizi da organizzazioni terze. A tale scopo, il team relativo collaborerà con altre parti dell’organizzazione per comprendere le esigenze di approvvigionamento, identificare potenziali fornitori in grado di soddisfarle e collaborare con legalper sviluppare contratti adeguati. Da punto di vista organizzativo, il team di approvvigionamento è spesso parte del team legale o comunque strettamente correlato.
  • Sales: il suo obiettivo è tanto ovvio quanto fondamentale, ovvero vendere i prodotti/servizi ai clienti. Gli addetti alle vendite, lavorano a stretto contatto con il team di marketing, per assicurarsi di essere concentrati sulle vendite che riflettono la strategia generale dell’organizzazione, oltre che con l’IT, per garantire che ciò che sta vendendo sia disponibile o possa essere sviluppato rapidamente. Sales, a livello organizzativo, è spesso combinato con il marketing o ad altre aree aziendali.

Come abbiamo visto per le altre aree, anche DAE è interessato da un workflow esplicativo che mette in relazione tra loro i diversi process blade, non solo quelli specifici appena tracciati.

dae workflow

DAE Workflow

DAE espande quindi una filosofia agile a tutte le aree organizzative, anche quelle storicamente più burocratizzate ed ingessate, promuovendo la cultura dell’innovazione continua in relazione alle sfide che il mercato di oggi (e di domani) presenta ad ogni tipo di organizzazione.

Si conclude così il nostro sesto appuntamento dedicato a PMI DA. Nel prossimo approfondimento introdurremo PMI FLEX, il framework “dinamico” che evidenzia come gestire un value stream sfruttando quanto messo a disposizione dal toolkit DA.

Stay tuned J

PMI Disciplined Agile: Disciplined Agile IT (pt. 5)

In questo nuovo appuntamento dedicato a Disciplined Agile ci focalizzeremo su Disciplined Agile IT (DAIT).

da f1

DAIT fornisce un quadro d’insieme dei processi e delle azioni da implementare per ottenere una efficace integrazione tra le iniziative di business e le derivate azioni intraprese dall’IT, siano esse relative a nuovi prodotti o alla trasformazione di servizi in essere.

da dait workflow

DAIT Workflow

L’obiettivo è quello di consentire una governance chiara e trasparente delle diverse iniziative di un’organizzazione IT, consentendo di misurarne il valore e i benefici ottenuti.

Per raggiungere questo obiettivo, il toolkit introduce i seguenti Process Blade:

  • Continuous Improvement: si occupa di facilitare la condivisione della conoscenza all’interno dell’organizzazione, in modo da supportare il miglioramento continuo in modo sistematico. 
  • Enterprise Architecture: si concentra sulle dinamiche che caratterizzano lo sviluppo e l’evoluzione di una Disciplined Agile Enterprise Architecture (DA EA), ovvero su come rendere le strutture ed i processi aziendali flessibilifacilmente ampliabilifacilmente evolvibili. Il cuore della DA EA è l’esplorazione collaborativa ed evolutiva, realizzata in modo sensibile al contesto grazie alla collaborazione continua tra gli enterprise architecte i team di delivery.

Come gli altri process blade, anche l’Enterprise Architecture ha una fitta rete di relazioni e dipendenze con il resto degli elementi e processi dell’organizzazione.

da ea workflow

Enterprise Architecture Workflow

  • People Management: nota anche come gestione delle risorse umane(HR), gestione dei talenti,gestione del personale, ecc. Ha l’obiettivo fondamentale di gestione il percorso di crescita delle persone, attraendo e trattenendo talenti in grado di creare team fantastici
  • Portfolio Management: affronta il modo in cui un’organizzazione IT identificaassegnaleprioritàorganizza e governa le diverse attività. Discipline Agile Portfolio Management cerca di farlo nel modo più flessibile possibile supportando la creazione di valore sostenibile nel lungo periodo. Le attività IT, in genere, includono:
    • attività di delivery
    • team di sviluppo stabili
    • esperimenti di business (sulla falsariga di Lean Startup)
    • mantenimento efficace delle soluzioni esistent

Il flusso di relazione con gli altri process blade e i diversi aspetti organizzativi è riassunto nella figura seguente, che evidenzia come l’attività di Portfolio Management “attinge” e condivide informazioni con le diverse funzioni al fine di riallinearsi costantemente con lo stato reale delle attività grazie a quella che viene definita Development Intelligence.

da portfolio workflow

 Portfolio Management Workflow

  • Product Management: include le azioni di identificazioneed evoluzionedella Visione Aziendale della propria organizzazione. In sintesi si occupa di: 

    • identificare e dare la priorità ai potenziali prodotti/soluzioni
    • stabilire le priorità e allocare le funzionalità relative ai prodotti in fase di sviluppo
    • gestire le dipendenze funzionali tra prodotti
    • commercializzare i prodotti ai potenziali clienti

DA Product Management si fonda sulla gestione del prodotto in modo collaborativo ed evolutivo, riflettendo costantemente sul contesto organizzativo in essere.

  • (Lean) IT Governance: si occupa di sviluppare l’opportuna leadership, le opportune strutture organizzativesemplificare iprocessi al fine di consentire all’IT di lavorare come partner strategico al fine di massimizzare la capacità dell’organizzazione di produrre continuo valore per i clienti. 
  • Reuse Engineering: si concentra sulla creazione, la gestione, il supportoe la governancedelle risorse riutilizzabili. Il Reuse Engineering è spesso guidato dal team di enterprise architecture, anche se l’approdo più efficace è quello di disporre di un team specifico.

da dait process blades

DAIT Process Blade

Come visibile dal DAIT Workflow, questi process blade sono strettamente legati tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche e in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile. Nello specifico, gli archi relazionali evidenziano gli elementi di congiunzione, i manufatti se si vuole, che i diversi process blade si scambiano per allinearsi sugli aspetti che li condizionano in modo congiunto.

Disciplined Agile IT si occupa, quindi, della sovrastruttura minima indispensabile per garantire una efficace collaborazione e coordinamento tra tutte le anime che supportano la creazione di soluzioni (oltre il prodotto, quindi), pensate per deliziare i propri clienti.

Si conclude così il nostro quinto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile Enterprise.

Stay tuned J

PMI Disciplined Agile: Disciplined Agile DevOps (pt.4)

Continuiamo ad esplorare Disciplined Agile, concentrandoci sul livello immediatamente successivo a Disciplined Agile Delivery, ovvero Disciplined DevOps.

da f1

Disciplined DevOps è la concretizzazione disciplinata del principio della Continuous Delivery, ovvero un efficiente Value Stream in grado di portare continuamente nuovo valore nelle mani degli stakeholder. 

Ma cosa rende DevOps “disciplinato”?

La sintesi la si incontra nella specifica definizione data da DA:

“Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.”

da disciplined devops

Disciplined DevOps

Nella sostanza, non sono solo i Dev e gli Ops chiamati a collaborare per il successo di una iniziativa di business, ma lo è l’intero ecosistema a supporto di essa

Questo aspetto è fondamentale, anche in relazione alla crescente moltiplicazioni di acronimi come: DevSecOps, DevDataOps, DevXXXOps, ecc. Non ha alcun senso inventare nuovi acronimi… tutto deve essere oliato perfettamente, grazie a cultura/pratiche/automazioni adeguate, in modo da ridurre gli sprechi lungo il value stream ed avere un processo di delivery adeguato basato su un deploy efficiente.

Proprio l’efficienza è un aspetto fondamentale: ogni attività, progetto, elemento, deve essere sempre facilmente collegabile ad una specifica iniziativa di business! Se ciò non è possibile, allora bisogna fermarsi e riflettere se ciò che si sta realizzando non sia un “tecnoware”, ovvero un’attività fine a sé stessa.

Nella sostanza, DA suggerisce di estendere gradualmente l’approccio DevOps alle varie funzioni coinvolte, in modo da far maturare progressivamente nel proprio contesto la Cultura necessaria a tale cambiamento.

da disciplined devops evo

Estendere gradualmente DevOps

Sicuramente non sorprende come il primo passo sia quello di abbattere lo “storico” muro tra Dev e Ops, abbattendo i silos comunicativi ed operativi annessi, proprio come suggeriscono le “Three Ways” di DevOps: FlowFeedback & Experimentation and Learning.

Disciplined DevOps individua 5 process blade espliciti, oltre a “inglobare” Disciplined Agile Delivery descritto nel post precedente:

  • IT Operations, fornisce un ecosistema IT affidabile. Si tratta di garantire l’opportuno livello di Quality of Servicesai propri utenti, cosa che può risultare non banale nelle organizzazioni con molti sistemi legaci e alto debito tecnico annesso. 
  • Support, anche Help DeskEnd-User support, si concentra nell’aiutare gli utenti finali a lavorare con le soluzioni realizzate. Idealmente, le soluzioni dovrebbero essere utilizzate senza il bisogno di nessun supporto in merito, ma spesso ciò non accade e il “support” è “l’ultima linea di difesa” per Deliziare i Clienti con i propri sforzi.
  • Security, il relativo focus è quello di attivare le azioni necessarie a proteggere l’organizzazione da minacce informatiche, virtuali o fisiche che siano. Ciò include procedure come la governance della sicurezzae la gestione delle vulnerabilità. Il tutto impatta sulla capacità di ripristino di emergenza e continuità aziendale, e deve essere un aspetto fondamentale della cultura organizzativa.
  • Data Management, la gestione dei dati è “lo sviluppo, l’esecuzione e la supervisione di piani, politiche, programmi e pratiche che controllano, proteggono, forniscono e migliorano il valore dei dati e delle risorse informative” [Data Management Body of Knowledge]. Per raggiungere tale scopo, DA promuove un approccio pragmatico e semplificato alla gestione dei dati che si adatta al resto dei processi IT: ottimizzare l’intero flusso di lavoro, non sub-ottimizzando la strategia di gestione dei dati. Una gestione dei dati, agile e disciplinata, è una gestione evolutiva e collaborativa, grazie a strategie concrete che forniscono i dati giusti al momento giusto alle persone giuste.
  • Release Management, si occupa della gestione dei rilasci, grazie alla pianificazione, il coordinamentoe la verificadella distribuzione (deploy) delle soluzioni in produzione. Il versioning richiede la collaborazione tra Dev e Ops, cosa che l’approccio agile può portare ad essere anche un’unica entità grazie al concetto di “you build it, you run it

da disciplined devops process blade

DevOps Process Blades

Per concretizzare ed attuare i DevOps Process blade, raggiungendo la pienezza di Disciplined DevOps, DA suggerisce una serie di strategie che afferiscono ad essi:

  • General Strategies(Collaborative work, Automated dashboards, ecc)
  • Teaming Strategies(Production hand-off, Warranty period, ecc)
  • Development Strategies(Canary tests, Split tests, ecc)
  • Operations Strategies(Solution monitoring, Standard platforms, ecc)
  • Support (Help Desk) Strategies(Online information, Online discussion forums, ecc)
  • Release Management Strategies (Release windows, Release train, ecc)
  • Data Management Strategies(Data and information guidelines, Quality data sources, ecc)
  • Security Strategies(Build “rugged software, Automated separation of duties, ecc)
  • Enterprise Architecture Strategies(Reuse mindset, Technical-debt mindset, ecc)

Dovrebbe risultare a questo punto evidente come Disciplined DevOps sia un passo fondamentale nella creazione di una organizzazione agile, consentendo di portare efficacemente la soluzione a “casa” degli stakeholder, prediligendo rilasci brevi e feedback costanti.

Si conclude così il nostro quarto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile IT.

 

Stay tuned J