Author Archives: Felice Pescatore

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

PMI Disciplined Agile: Disciplined Agile Delivery (pt.3)

Come visto nel precedente post della serie, Disciplined Agile ha al centro della propria azione Disciplined Agile Delivery (DAD) ovvero la capacità di realizzare soluzioni in modo disciplinato con team che fanno propri i Valori, i Principi e le Pratiche più consolidate del mondo Agile e Lean.

da f1

DAD è anche storicamente la prima area di Disciplined Agile ad essere stata formalizzata e, come già accennato nel post precedente, consiste in un approccio hybrid-agile allo sviluppo di soluzioni IT, in cui le Persone coinvolte fanno propria una cultura basata sull’apprendimento costante. 

DAD si basa su 8 principi portanti:

  • People-first, sono le persone a condizionare i processi e non viceversa
  • Goal-­driven, focus su goal chiari
  • Hybrid agile, scegliere le pratiche opportune da diversi framework/metodologie
  • Learning-­oriented, apprendimento continuo
  • Full delivery lifecycles, dall’idea alla consegna
  • Solution focused, soluzioni consumabili, non solo “finite”
  • Risk-­value lifecycle, gestione esplicita e profonda del rischio
  • Enterprise aware, consapevolezza aziendale

e affronta in modo esplicito tutti gli aspetti della realizzazione di un nuovo prodotto, attraverso tre fasi esplicite:

  • Inception, la fase di inizializzazione del progetto, in cui gli elementi fondamentali per la sua riuscita prendono corpo e si valutano aspetti come il Rischioe la Sostenibilità;
  • Construction, la fase di realizzazione, ovvero dove la soluzione viene concretamente implementata;
  • Transition, la fase che si occupa degli aspetti di Deployment.

dad phases

Fasi di DAD

Se l’utilizzo di fasi può sembrare qualcosa di “strano” all’interno di un framework Agile, bisogna evidenziare come esse non siano da intendersi alla waterfall, bensì come “contenitori di scopo” che non limitano alcuna review delle decisioni prese. Il loro obiettivo è quello di focalizzarsi, nei diversi momenti, su ciò che è tipicamente richiesto dalla lavorazione di un prodotto, così come esplicitato dagli specifici process goal annessi ad ogni singola fase.

dad goals

 The process goals of Disciplined Agile Delivery (DAD)

Nella figura precedente sono anche visibili dei goal raggruppati in una “virtual phase” chiamata Ongoing: si tratta di obiettivi trasversali che accompagnano il team nell’intera realizzazione del prodotto.

Nel rispetto del principio portate “choice is good” (si veda il primo articolo della serie), e della continua evoluzione organizzativa, le fasi prendono forma e si specializzano in 4 lifecycle specifici: Agile/Basic, Lean/Advanced, Continuous Delivery (Agile/Basic) e Continuous Delivery (Lean/Advanced).

dad lifecycles

DAD Lifecycles

Ad essi se ne aggiunge un quinto, Exploratory (Lean Startup) in cui le fasi precedenti non sono presenti, avendo uno scopo diverso e specifico: supportare le organizzazioni nella fase di customer delivery. Esempio tipico sono le “vere” startup.

Diamo ora uno sguardo più di dettaglio ai diversi lifecycle.

Agile/Basic Lifecycle (Extending Scrum): si tratta del lifecycle pensato per i team nuovi al mondo Agile o a quelli che già lavorano con Scrum e hanno la necessità di scalare le proprie attività. 

dad lifecycles basic

Agile/Basic Lifecycle

È indicato quando è possibile identificareprioritizzare e stimare le diverse funzionalità da realizzare, caratterizzandosi per:

  • Iteration Based, esattamente come Scrum la soluzione è sviluppata con un approccio time-boxed e ogni intervallo di sviluppo è definito Iteration
  • Non-Scrum Terminology, di base la terminologia Scrum è sostituita con una duale più generica (es: Iterationvs Sprint), anche se ciò non è un must
  • Inputs from outside the delivery lifecycle, vengono evidenziati gli elementi esterni primari in grado di condizionare la soluzione e generare cambiamenti durate la sua realizzazione
  • Work item list, not Product Backlog, DAD preferisce il concetto di Work Item a quello di Product Backlog. Questo per evidenziare che nello stack non sono presenti solo User StoryFeatureda realizzare, ma anche requisiti, difetti, aspetti non funzionali, ecc…. In pratica il Product Backlog contiene tutto quanto necessario al successo della soluzione (e non allo sviluppo del prodotto/progetto), comunque ordinato secondo diversi criteri
  • Explicit milestones, sono previste milestone esplicite che consentono una governance efficace delle attività, e rappresentano spesso il momento di Deployment concordato con il cliente.

Advanced/Lean DAD Lifecycle: si tratta del lifecycle pensato per team che lavorano in chiave di Value Stream, rilasciando gli Incrementi quando sono pronti, senza avere una finestra specifica di riferimento, e sforzandosi di ridurre al minimo il tempo che intercorre tra due rilasci. 

dad lifecycles advanced

Lean/Advanced Lifecycle

È indicato quando è possibile suddividere le attività in unità minimali di lavoro ed è difficile fare previsioni su di esse, caratterizzandosi per:

  • Continuous flow of delivery, la delivery avviene ogni volta che è disponibile un nuovo Incrementsignificativo, senza vincolarsi ad alcuna Iterazione. Le nuove attività sono “tirate” dal team nel flusso di lavoro appena si ha la capacità per farle e non “spinte” in funzione di una pianificazione time-boxed (pull vs push)
  • Practices are on their own cadences, i vari eventi (retrospettive, refinement, ecc…) vengono eseguiti quando ha senso farle e non secondo una cadenza pre-stabilita
  • Work item pool, non tutti i work-item sono uguali. Alcuni sono risk-value driven, altri value-drivene altri ancora data-driven(si pensi ai vincoli normative). Per questo motivo un Work Item pool ha molto più senso che uno stack ordinato per priorità generica.

Continuous Delivery Lifecycle (Agile/Basic): si tratta della naturale evoluzione del lifecycle Agile/Basic, con iterazioni di una settimana o meno. 

dad lifecycles cd basic

Continuous Delivery (Agile/Basic)

La differenza primaria è che la fase di Inception viene completamente assorbita da quella di Construction e anche la fase di Transition si riduce al minimo. Inoltre, rispetto all’Agile/Basic il rilascio avviene concretamente al massimo alla fine di ogni iterazione, e quindi almeno ogni settimana. Le sue caratteristiche sono:

  • Iteration Based(al massimo di 1 settimana)
  • Non-Scrum Terminology
  • Inputs from outside the delivery lifecycle
  • Work item list, not Product Backlog
  • Explicit milestones

Continuous Delivery Lifecycle (Lean/Advanced): si tratta della naturale evoluzione del lifecycle Lean/Avanced in cui il tempo di delivery è ridotto al minimo necessario, anche con frequenza di più volte al giorno, sfruttando strumenti di automazione (deploy) e processi standardizzati nel tempo. 

dad lifecycles cd advanced

Continuous Delivery (Lean/Advanced)

Per la fase di Inception e Transition vale quanto già detto per il Continuous Delivery Lifecycle Agile/Basic, mentre le caratteristiche rilevanti sono:

  • Continuous flow of delivery
  • Practices are on their own cadences
  • Work item pool

Exploratory (Lean Startup) Lifecycle: è il lifecycle ispirato a Lean Startup, pensato per le startup o le nuove iniziative, che devono prima di tutto validare la sostenibilità della propria idea, andando a scoprire il mercato con una serie di Minimum Viable Product (MVP) e una specifica implementazione del ciclo Build-Measure-Learn. 

dad lifecycles exploratory

Exploratory (Lean Startup) Lifecycle

L’obiettivo è quello di ridurre al minimo gli investimenti iniziali, favorendo, attraverso piccoli esperimenti, azioni testate sul mercato e misurate con metriche significative. Si caratterizza per:

  • Envision, si tratta di esplorare la nuova idea e formulare le ipotesi in relazione alla possibile idea che potrebbe attrare i potenziali clienti
  • Build a Little, sviluppare velocemente quanto necessario per validare le proprie ipotesi: Minimum Viable Product (MVP).Non è importante concentrarsi sulla qualità tecnica, bensì essere estremamente veloci e capaci di evidenziare le caratteristiche peculiari
  • Deploy, l’MVP deve essere reso velocemente fruibile agli early-adopter in modo da poterne testare l’interesse
  • Observe & mesure, una volta in erogazione, è necessario monitorare il comportamento degli early-adopter “instrumentando” l’MVP. In tal modo è possibile rendersi conto se quanto realizzato è sulla direzione giusta o è necessario eseguire un pivot
  • Cancel, dopo aver testato le idee portanti e sfruttato i pivot, potrebbe essere necessario decidere di abortire lo sviluppo della soluzione perché non è di interesse per i potenziali clienti. Se ciò deve avvenire, meglio che avvenga in un tempo ristretto limitando le risorse impiegate e massimizzando il know-how acquisito
  • Productize, se il prodotto trova il proprio spazio, la fase di Customer Deliverypuò ritenersi conclusa ed è opportuno passare alla fase di ingegnerizzazione, preferibilmente, tramite uno degli altri modelli di sviluppo presentati

Una caratteristica che abbiamo osservato è quella che prevede la graduale scomparsa (o assottigliamento delle fasi), pian piano che si evolve nell’adozione dei diversi lifecycle.

dad phases disappear

Phases Disappearing

Non bisogna però pensare che, in generale, una fase sia migliore dell’altra, ma lavorare su quella più adatta al contesto temporale e valutare possibili evoluzioni, anche come suggerito da DAD stesso nel tipico percorso di adozione relativo.

dad lifecycles adoptions

Typical Adoption Paths

Dal percorso resta ovviamente escluso l’Exploratory (Lean Startup) Lifecycle che ha un compito specifico e temporalmente limitato e che, una volta completato, viene sostituito con uno degli altri quattro.

 

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

Stay tuned J

PMI Disciplined Agile: Disciplined Agile Toolkit (pt.2)

Riprendiamo il nostro viaggio alla scoperta di PMI Disciplined Agile (qui il primo post), presentandone il poster o, come ufficialmente chiamato dal DA Consortium: il Disciplined Agile Toolkit.

da poster

Il toolkit fornisce una visualizzazione d’insieme delle 4 aree d’azione di DA, suddividendole in 25 process blade specifici. 

Ma cosa sono i process blade?

Si tratta, in sintesi, di una raccolta coerente di opzioni (in particolar modo pratiche e strategie) relative ad un processo che dovrebbero essere scelte ed applicate in relazione al contesto specifico. Ogni process blade affronta un ambito “atomico”, come, ad esempio: Data ManagementContinuous Delivery, o Portfolio Management. La scelta del termine “blade” è legata concettualmente all’omologo dei “server blade” per evidenziare la possibilità di aggiornarlo, cambiarlo, o addirittura sostituirlo, con estrema agilità, in relazione all’evoluzione del contesto in cui si sta operando.

La visione d’insieme delle diverse aree rappresenta la visione ad evoluzione progressiva di Disciplined Agile, in cui il livello N-esimo ingloba quello N-1, come viene sinteticamente descritto dalla metafora della Formula 1:

da f1

dove: Disciplined Agile Delivery è il motore, Disciplined DevOps la vettura, Disciplined Agile IT la squadra e Disciplined Agile Enterprise l’intero circus.

Proviamo ora ad andare maggiormente nel dettaglio delle diverse aree, abbinando gli specifici process blade:

  • Disciplined Agile Enterprise (DAE), è il livello complessivo, che guarda ad una organizzazione in grado di reagire rapidamente ai cambiamenti del mercato. Una DAE si basa su una Cultura e una Struttura Organizzativa che facilita il cambiamento nel contesto delle diverse situazioni che si trova ad affrontare.  A questo livello vengono aggiunti process blade che guardano all’intera organizzazione: BusinessOperationsMarketingSalesFinanceLegalProcurement e Control.
  • Disciplined Agile Information Technology (DAIT) estende Disciplined DevOps nell’ottica di ottenere un’area IT collaborativa e propositiva. I nuovi process blade introdotti sono: People Management (o Agile HR), Product ManagementPortfolio ManagementEnterprise ArchitectureReuse EngineeringIT Governance e Continuous Improvement.
  • Disciplined DevOpssupporta l’applicazione di strategie Agili a tutti gli aspetti dell’IT. Ciò include attività come quella della Security e del Data Management, utili a fornire soluzioni efficaci ed efficienti in relazione agli obiettivi e gli impegni aziendali.  I 5 process blade aggiunti da questo livelli sono: Release ManagementIT OperationsSupport,Security e Data Management.
  • Disciplined Agile Delivery (DAD) è l’approccio hybrid-agile alle soluzioni IT che si basa su persone (people-first) che fanno propria una cultura basata sull’apprendimento costante. DAD affronta tutti gli aspetti della delivery, includendo: modellizzazionepianificazione inizialeformazione del teamgaranzia dei finanziamentiarchitettura continuatest continuisviluppo iterativo/incrementalegovernance durante tutto il ciclo di vita. DAD supporta più lifecycle, esplicitando la gestione del rischio e focalizzandosi su obiettivi specifici nell’ambito aziendale, consentendo di scalare in funzione delle esigenze.  I process blade a questo livello sono i 5 diversi lifecycle suggeriti: AgileLeanContinuous Delivery: AgileContinuous Delivery: Lean ed Exploratory/Lean Startup, più, il blade Program Management per il coordinamento di team di delivery ampi o più team. 

Come abbiamo più volte accennato, l’approccio Goal-Based è fondante per DA. 

Si tratta, in pratica, di avere sempre visibilità del goal specifico su cui concentrarsi (ovviamente i goal viaggiano in parallelo e non in sequenza), andando a contestualizzare le azioni in relazione all’ambiente e al progetto specifico (valori: Context Count e Choice is good). Lo schema generale adottato per descrivere un goal è rappresentato nella figura seguente:

da gola generale

In pratica, per ogni Process Goal abbiamo dei Decision Point, ovvero delle “decisioni da prendere” obbligatoriamente e non demandabili, ed una serie di Opzioni, ordinate o meno. Queste opzioni sono quelle “suggerite” da DA e rispecchiano l’esperienza quasi decennale di applicazione del framework.

Un esempio concreto di Process Goal è quello riportato di seguito, nello specifico: “Explore Initial Scope”, appartenente alla fase di Inception di DAD (di cui parleremo in seguito).

da goal initial scope

Il nostro secondo appuntamento con la serie dedicata a PMI DA termina qui. Nel prossimo approfondimento guarderemo più da vicino DAD e i relativi process blade.

 

Stay tuned J

PMI Disciplined Agile: il Manifesto (pt.1)

da pmi logoCon l’acquisizione di Disciplined Agile (DA) da parte del PMI, il procress framework creato da Scott Ambler e Mark Lines entra in una nuova dimensione che lo proietta in un contesto dove l’Agilità è stata per molto tempo vista con diffidenza, ma che da alcuni anni ha ormai intrapreso in percorso di convergenza senza però tradire i propri fondamenti.

Non potrebbe essere altrimenti, visto che la “contaminazione” è una ricchezza e, come più volte ribadito, l’Agilità è un mindset che non deve contrapporsi ad altri metodi, ma che aiuta a trovare una dimensione unitaria, utile all’organizzazione per muoversi nell’ambito di problematiche complesse, trasformandole in opportunità.

Come molti sanno, sono da anni coinvolto attivamente nell’evoluzione di DA e con questo primo post, inizierò a creare una guida introduttiva relativa, in modo da aiutare a capirne l’essenza e guardarlo da una prospettiva pragmatica.

Disciplined Agile Manifesto

Disciplined Agile è fortemente radicato sul Manifesto Agile, proponendone una rivisitazione per ampliarne lo “scope” in relazione alla modernità delle sfide moderne:

Individui e interazioni più che i processi e gli strumenti
Soluzioni consumabili più che la documentazione esaustiva
Collaborazione con gli stakeholder più che negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Nonostante l’indiscusso valore degli elementi a destra (non in grassetto), i “disciplined agilist” danno un peso predominante a quelli di sinistra (in grassetto).”

Come si vede da quanto evidenziato in rosso, DA guarda in modo esplicito alle soluzioni consumabili e non solo al software funzionante. Può sembrare una cosa di poco conto, ma rendere una soluzione “consumabile” vuol dire essere pronti affinché i nostri stakeholder possano usufruire in pieno dei relativi vantaggi. Pensiamo, ad esempio, ad una soluzione cloud b2c: in questo caso avremmo sicuramente bisogno di un customer careche supporta gli utenti nel suo utilizzo. È una questione di “working software”? No, ma è vitale per rendere la soluzione utilizzabile.

I principi annessi al Disciplined Agile Manifesto

Insieme ai Valori, il DA Manifesto definisce anche 15 principi, 3 in più di quelli definiti dal Manifesto Agile, sui cui si basa, e che rivede nella stessa misura fatta per il Valori (in particolare da “clienti” a “stakeholder”) 

  1. La nostra massima priorità è soddisfare gli stakeholder rilasciando soluzioni di valore, fin da subito e in maniera continua.
  2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
  3. Consegniamo frequentemente soluzioni consumabili, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  4. Stakeholder e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
  5. Fondiamo i team su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
  6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
  7. Le soluzioni consumabili sono il principale metro di misura di progresso.
  8. I processi agili promuovono un approccio al rilascio sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
  10. La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
  11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
  12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
  13. Sfruttare e contribuire a far evolvere le risorse organizzative disponibili all’interno del proprio ecosistema aziendale, e collaborare con le persone responsabili di ciò.
  14. Avere sempre chiaro il flusso di lavoro in modo da riuscire a sviluppare un flusso costante di rilasci che aiuta a ridurre le attività in corso al minimo.
  15. L’ecosistema organizzativo deve evolvere per riflettere e migliorare le attività dei team agili, ma al contempo essere sufficientemente flessibile da supportare gli eventuali team non-agili o ibridi.

I 3 principi aggiuntivi, dal 13 al 15, guardano all’enterprise, ovvero a come supportare l’Agilità a livello complessivo dell’organizzazione, che è implicitamente contaminata in relazione al cambiamento dei team che, a loro volta, ne vengono condizionati.

Durante l’evoluzione stessa di DA (in particolare dall’estensione di Disciplined Agile Delivery a Disciplined Agile), i 15 principi del Manifesto sono stati condensanti focalizzandoli sulle Persone, ottenendo i seguenti 7 principi portanti:

da principles

  • Delight Customers: non siamo focalizzati solo sul soddisfare le esigenze e le aspettative dei nostri stakeholder, ma siamo concentrati sul superarle per stupirli (ottica Lean)
  • Be Awesome: team fantastici sono costruiti intorno a persone motivate che operano in un ambiente arricchito del supporto necessario per raggiungere gli obiettivi individuali e complessivi
  • Pragmatism: cerchiamo di essere il più efficaci possibile, superando la semplice applicazione dell’agilità
  • Context Counts: ogni persona, ogni team ed ogni organizzazione è unica. Individuiamo e facciamo evolvere una strategia efficace data la situazione specifica che stiamo affrontando
  • Choice is Good: contesti diversi richiedono strategie diverse. I team devono essere in grado padroneggiare i propri processi e sperimentarli in relazione alla situazione specifica che devono affrontare. Avere opzioni tra cui scegliere, e individuarne i compromessi, abilita alla generazione di opzioni plausibili
  • Optimize Flow: ogni organizzazione è un Sistema Adattivo Complesso (CAS) di team e gruppi che interagiscono ed evolvono, sia individualmente che influenzandosi a vicenda. Per avere successo è necessario assicurarne un allineamento costante ed ottimale
  • Enterprise Awareness: quando le persone sono consapevoli dell’organizzazione in cui operano, sono motivate a prendere in considerazione le esigenze generali, e non solo quelle locali, in modo da assicurarsi che siano in linea con gli obiettivi complessivi

L’evoluzione dei principi è stata fortemente influenzata da Modern Agile di Joshua Kerievsky e Heart of Agile di Alistair Cockburn, rispecchiando l’attuale wave evolutiva del mondo agile.

 

Per ora è tutto, l’appuntamento è al prossimo post con il DA Poster.

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 4 – Retrospettiva finale

Eccoci giunti al quarto ed ultimo post della serie dedicata all’Agile nel mondo della Robotic Process Automation (RPA).

Abbiamo visto insieme come si sono svolte le diverse Iterazioni, cosa è stato introdotto come miglioramento progressivo ed evidenziato le lesson learned che riportiamo per avere un quadro d’insieme del tutto:

  1. Essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito
  2. La priorità delle Technical Story (TS) è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!
  3. La review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner(come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato
  4. L’uso di un Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati

I Valori ed i Principi Agili si sono dimostrati, ancora una volta, assolutamente adatti nell’ambito complesso, soprattutto per aiutare il team promiscuo a trovare armonia interna.

A questo punto facciamo una considerazione sul risultato finale in funzione degli obiettivi ipotizzati.

L’intera azione di sviluppo prevedeva inizialmente l’obiettivo di realizzare 6 Robot, ovvero di automatizzare 6 flow che precedentemente venivano eseguiti manualmente con il coinvolgimento di diverse risorse e Persone, aziendali e non.

Come abbiamo descritto nel primo post, all’inizio del percorso sono stati utilizzati una serie di strumenti (Product Canvas, Elevator Pitch, ecc) per allineare tutto il team intorno a quello che è risultato essere il cuore di tutto il discorso: “creare sistemi in grado di mimare il comportamento umano“.

Quello a cui non abbiamo minimamente accennato sono stati eventuali aspetti di pianificazione annessi. Ebbene, nessuna azione di stima o previsione è stata necessaria perché l’iniziativa era di per sé completamente allineata con il ben noto Iron Triangle rovesciato:

iron triangle planning

Nel dettaglio, si avevano a disposizione 8 mesi di tempo e un budget determinato dal costo delle Persone coinvolte e pochi elementi variabili di incidenza tollerabile. L’approccio è stato quindi quello di iniziare lo sviluppo, capire la velocity (non tanto in termini di una metrica specifica, ma di quanto il team realisticamente fosse in grado di realizzare) e tarare di volta in volta gli obiettivi.

Dopo le prime 3 iterazioni è parso subito chiaro che l’obiettivo dei 6 processi non era raggiungibile, per cui il PO ha cominciato ad esercitare le giuste leve verso gli stakeholder per riallineare le attese, mentre tutto il team (PO compreso, nel ruolo di Process Owner) ha fatto dei ragionamenti per capire come ottimizzare lo sviluppo.

E qui è nata una soluzione interessante: guardando i processi restanti nel loro insieme, è risultato evidente che una parte degli step costituenti relativi era praticamente comune per 4 dei 5 flow rimanenti.

Questo elemento è stato illuminante per rivedere tre elementi strategici:

  • Pianificazione, si è deciso di ri-pianificare il contenuto del portfolio backlog, non più in funzione della sola importanza (valore relativo) del processo, ma adottando un approccio value-reuse driven, in cui si è dato precedenza ai processi che avrebbero consentito di sviluppare per primi i componenti comuni, abbattendo di conseguenza anche i rischi dello sviluppo relativo
  • Metriche di Effort, per supportare una migliore stima dell’effort necessario per le Techincal Story, si sono stabilite una serie di TS campione (5 nello specifico) rispetto alle quali effettuare una stima massiva (Affinity Grouping) di quanto ipotizzato per le iterazioni a seguire. Le TS di riferimento erano caratterizzate da:
    • Numero di oggetti in ingresso
    • Numero di fonti dati sottese
    • Numero di sistemi terzi interrogati
    • Numero di oggetti in uscita 
  • Deep Analysis, il Process Owner ha modifica il suo approccio al refinement, non limitandosi alla sola rappresentazione tramite Flow Chart Mapping (FCM)del processo ma passando ad una vera e propria reingegnerizzazione. Infatti, il PO ha analizzato quali aspetti del processo consentissero allo stesso di superare la soglia del 90% degli impatti positivi, rimuovendo gli step relativi al resto.

Questi tre elementi hanno consentito di avere una visione più chiara di quanto stesse succedendo, rendendo inoltre possibile diminuire lo scope, del singolo processo e complessivamente, in modo da raggiungere un obiettivo finale realistico in chiave iterativa: ovvero, di quello che resta fuori ce ne occupiamo in seguito se serve!

Si chiude qui questa serie di post dedicati ad una esperienza pratica di adozione di un approccio Agile scrum-like nell’ambito della Robotic Process Automation.

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 3 – Flow Chart Mapping

Ci eravamo aggiornati lasciando in sospeso la discussione sul risultato del primo Sprint. 

Ebbene vediamo com’è andata.

Il team ha lavorato molto bene, sviluppando una prima timida sinergia che, anche in relazione alla composizione dello stesso (che vi ricordo era fatta di Persone afferenti a 4 player diversi), di per sé è già un buon risultato che merita dei kudo.

Se veniamo invece alle Technical Story (TS), la situazione si è rilevata un po’ più difficile da comprendere: infatti, se è vero che la maggior parte delle TS sono state completate, è anche vero che è risultato abbastanza difficile rappresentare il valore reale di quanto realizzato. Questo perché le Storie sono subito apparse come “isolate” e, rappresentando tasselli di un flow di esecuzione automatizzato, non è stato possibile valutare nessuna esse in senso atomico e da un punto di vista esplicitamente funzionale.

[Terza Considerazione] Abbiamo quindi appreso una nuova lezione: la review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner (come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato.

Quello invece che è risultato interessante è stata la visualizzazione del data-set ottenuto dall’esecuzione del primo flow parziale realizzato. In pratica si è costruita una semplice vista che, evidenziando di volta in volta il passaggio completato, metteva a confronto lo stato in ingresso con quello in uscita, consentendo al PO di valutare la correttezza del risultato e ponendo le basi per una successiva validazione automatizzata (un RPA dell’RPA J).

A questo punto si è tenuta la prima retrospettiva (classico Strafish) e la problematica primaria affrontata è stata quella di capire come rappresentare in modo più efficace la visione d’insieme e le diverse specializzazioni verticali. In pratica, come riuscire a sfruttare un tool tipo User Story mapping, che però risultava poco efficace rispetto alle più volte sottolineate caratteristiche delle Tecnical Story. La soluzione individuata è stata quella di ricorre ad una rappresentazione grafica del processo, attraverso uno dei più classici strumenti che si conosca: un flow chart.

flow chart mapping

Questo strumento è stato introdotto nel planning dello Sprint 2, consentendo al team di discutere visivamente del processo e andare a esplicitare i 5 elementi di riferimento di ogni Technical Story: Sottosistemi coinvolti, Dati in ingresso attesi (tipologia e set campione per il test), Dati in uscita attesi (tipologia e set campione per il test), Gate di ingresso e Gate di uscita.

 [Quarta Considerazione] Alcuni strumenti comunemente utilizzati per il mapping delle Storie, vanno opportunamente rivisti, considerando gli aspetti tecnici delle storie. In particolare, l’uso del Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati.

L’FCM ha permesso al nostro speciale PO, Process Owner, di descrivere il sotto-flow atteso per lo sprint, in funzione dei dati di input di start e quelli di output in end. A questo punto il team si è rituffato nello sviluppo!

Nel prossimo post, che chiuderà la serie, vedremo come sono andati gli sprint successivi e faremo una serie di considerazioni finali.

 

 

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 2 – Il ruolo del PO

Ed eccoci arrivati allo start del primo Sprint!

Dopo aver dedicato alcuni incontri a parlare di Agilità, soffermandoci sui Valori e sui Principi, e aver illustrato il framework Scrum (come detto scelto a livello Corp), il team è pronto per iniziare a sperimentare sul campo e costruire il primo draft di Product Backlog.

Bisogna dire che l’obiettivo complessivo era quello di automatizzare tramite RPA 6 processi con diversi livelli di complessità e che, mediamente, essi interessavano almeno 3 sistemi di gestione differenti. Il grande vantaggio nella fase di Inception è stato quello di avere un neo-PO estremamente esperto di ogni singolo processo, in grado di descrivere in modo minuzioso ogni step relativo e il set di dati fondamentali.

[Prima Considerazione] Ecco quindi una prima considerazione rispetto al tradizionale ruolo di PO: essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito.

po role reponsability

La validazione di quanto realizzato può essere fatta confrontando i risultati di ogni step con quelli analoghi fatti da un operatore umano (subFlow), o valutando l’intero flow.

Il PO, in questo scenario, non si occupa di formalizzare needs funzionali (sotto forma di Storie o altro), ma, più che altro, è un esperto di processo/dominio/data in grado di descrivere una sorta di flow chart (activity diagram) che consente di suddividere adeguatamente i passi costituente del processo.

Potremmo dire che è più un Process Owner che un Product Owner.

po rpa

Tornando al nostro Product Backlog, è stato deciso di identificare ogni processo da automatizzare come “prodotto” differente, dotato quindi di uno specifico Product Backlog. Per ogni prodotto sono state create una serie di Technical Story (lo so, qualcuno storcerà il naso, ma noi abbiamo ritenuto giusto così) in relazione agli step di avanzamento del processo, individuandone gli aspetti caratterizzanti primari:

  • Sottosistemi coinvolti
  • Dati in ingresso attesi (tipologia e set campione per il test)
  • Dati in uscita attesi (tipologia e set campione per il test)
  • Gate di ingresso 
  • Gate di uscita

Quando la prima versione del Product Backlog è stata completata, il team si è trovato difronte alla necessità di scegliere su quali Tech Story ingaggiarsi nel primo Sprint. In questo caso, non avendo una “storia passata”, si è optato per lasciare allo stesso la scelta di un numero di storie che ritenevano “aggredibili”, senza impiegare tempo in stime o pesi che non potevano avvalersi di alcuna esperienza pregressa e rimandando la “prima pesatura” a consuntivo.

Ogni Tech Story è stata suddivisa, durante il successivo Sprint Plannig, in Task di dettaglio, in cui sono state esplicitate le attività di implementazione e le differenti aree di sviluppo tecniche interessate. Quest’ultimo aspetto è stato fondamentale per gestire la pluralità del team (come descritto nel primo post della serie) e calibrare la loro permanenza in-house, non necessariamente di 5gg a settimana.

Completato il tutto, il team ha cominciato a lavorare sulle singole Technical Stories, adottando la strategia Serial-and-Parallel: il team avvia la prima Storia e lavora in parallelo sui Task di dettaglio e solo in caso qualcuno sia scarico si avvia la successiva Storia, altrimenti ci si concentra sul finirne una alla volta. In tal modo si riduce sensibilmente il rischio di avere troppe Storie avviate e finite solo parzialmente a fine Sprint.

Anche qui è stato riscontrato subito un punto dolente: il rispetto delle priorità indicate dal Product Owner (e implicitamente dal processo). I membri del team hanno ritenuto opportuno rivederle più volte per sbloccare situazioni di stallo dovuto a condizioni tecniche abilitati.

[Seconda Considerazione] Da qui una seconda considerazione operativa: la priorità delle Technical Story è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!

Detto questo, il team ha utilizzato le canoniche due settimane, allineandosi giornalmente nel classico Daily, per completare quante più Technical Story possibili, con una presenza attiva del PO per rispondere a problematiche di processo/sistema/dati.

Volete sapere com’è andata? Beh.. non vi resta che attendere il prossimo post della serie.

Stay tuned J