Disciplined Agile 2.0: una nuova visione olistica del delivery
Lean, Agile e, più recentemente DevOps, sono approcci mirati alla creazione di una mentalità in grado di liberare le potenzialità della propria organizzazione dalle catene della burocrazia, consentendo di concentrarsi su ciò che realmente è utile al raggiungimento degli obiettivi complessivi di business.
Non si tratta di metodologie da “imparare ed applicare” meccanicamente, ma di valori, principi e pratiche che mettono al centro dell’azione la creazione di valore — per quanto quest’ultimo possa essere diverso nei vari contesti — e la soddisfazione degli stakeholder.
Scalare Lean/Agile ai diversi livelli
Non è quindi difficile intuire come l’adozione di Lean, Agile e DevOps sia estremamente pervasiva e attraversi tutti i livelli organizzativi tipici: dal team level, dove gli artefatti vengono “concretamente” realizzati, al top level, dove vengono prese le decisioni strategiche di mercato.
Per supportare tale adozione sono nati svariati “framework” spesso definiti di Scaling, proprio a indicare che, a differenza delle principali metodologie agili, si rivolgono non al singolo team di sviluppo, ma all’intera organizzazione aziendale: SAFe, DA2, LeSS, Nexus e altri sono tutti estremamente interessanti e con una specifica declinazione.
Da DAD a Disciplined Agile 2.0
In questa serie parleremo specificamente di Disciplined Agile 2.0, il framework sviluppato da Scott Ambler e Mark Lines, che è focalizzato sulla governance dei processi di realizzazione di soluzioni end-to-end complesse.
Il nostro viaggio comincia nel 2012, quando Scott Ambler e Mark Lines presentano ufficialmente DAD (Disciplined Agile Delivery) rendendo disponibile il testo ufficiale [1] e il blog di riferimento [2].
Entrambi gli autori non hanno bisogno di particolari presentazioni, soprattutto Ambler, già noto per la sua minuziosa attenzione all’Application Lifecycle Management e all’impatto delle scelte architetturali nella modellazione di soluzioni complesse. Ma DAD non nasce all’improvviso: c’è una lunga serie di esperienze che porta al suo concepimento.
Da Rational Unified Process ad Agile Unified Process…
DAD trova le proprie radici in Agile Unified Process, a sua volta nato come semplificazione di Rational Unified Process (RUP, Rational/IBM), ritenuto troppo strutturato e difficile da adottare. È interessante sottolineare come lo stesso Ambler avesse contribuito fortemente a RUP mettendo le basi per la versione enhanced comprendente la fase di produzione.
RUP contempla un approccio iterativo prevedendo che tutte le discipline tradizionalmente impiegate per la creazione di un prodotto software siano spalmante, con pesi differenti, durante 4 fasi primarie: inception, elaboration, construction e transition [3].
Si tratta di un deciso passo in avanti rispetto agli approcci tradizionali, waterfall in primis. Il RUP negli anni ha riscosso un discreto successo ma ha anche sofferto di un continuo aumento di complessità e di una aggravio di burocrazia dovuti alla volontà di estenderne continuamente il campo applicativo.
Inoltre, RUP nasce con quello che potremmo definire il “peccato originale” per un framework di sviluppo moderno: esso è infatti use-case driven e non goal-value driven, per cui resta fortemente legato a una gestione dei requisiti molto formale e concentrata nelle due fasi iniziali [4].
…a Disciplined Agile Delivery
Tornando a Disciplined Agile Delivery, è fondamentale sottolineare che esso si fonda sui valori e sui principi del Manifesto Agile, riprendendo l’organizzazione a fasi di RUP per supportare la realizzazione di un prodotto dal suo concepimento alla sua dismissione.
Ma perché “Disciplined”? Ebbene, i due co-autori pongono l’enfasi su tale termine per evidenziare e sottolineare come l’adozione dell’Agile sia un viaggio tortuoso e che la meta può essere raggiunta solo se si procede con estrema disciplina.
Le caratteristiche di Disciplined Agile Delivery
Presentato nel 2012, Disciplined Agile Delivery fa leva su princpi e valori tipicamente Lean/Agile, ma non scarta a priori alcune “conquiste” dei paradigmi strutturati precedenti. Vediamo una serie di caratteristiche di DAD.
Fasi/obiettivi
Il punto di forza di DAD è l’impostazione goal-driven, pensata per spingere il delivery team a essere concentrato su specifici e chiari obiettivi raggruppati in tre specifiche fasi (small-batch): Inception, Construction e Transition.
La fase di Elaboration, utilizzata in RUP per dettagliare i requisiti e testare l’architettura del sistema, scompare, non essendo proprio in linea con un approccio Agile o Lean che si voglia.
Viene così a crearsi una matrice fasi/obiettivi che consente di estendere il raggio di azione dell’Agile da quello legato esclusivamente agli aspetti di sviluppo, a quello relativo all’intera gestione dei processi di realizzazione di un prodotto. Ciò viene fatto combinando strategie e pratiche “prese in prestito” dalle metodologie più affermate, che connotano DAD come un hybrid-framework.
Lifecycle
Nella sostanza viene creata una “estensione virtuale” di Scrum (lifecycle basic), in modo da coprire i diversi aspetti metodologici spesso fonti di incertezza: si pensi alla famosa “Iteration 0” spesso introdotta per rispondere alla domanda: “Ma quando creo il Product Backlog?”.
Senza voler entrare per ora nel dettaglio, è doveroso evidenziare che DAD prevede 4 diversi lifecycle: Basic/Agile, Advanced/Lean, Lean Continuous Delivery ed Exploration, pensati per abbracciare diversi contesti e sui quali torneremo nei prossimi appuntamenti.
L’esplicita introduzione della fase di Inception e di Transition non deve far credere, però, che siamo difronte ad una sorta di water-scrum-fall [5], in quanto sono fasi di durata estremamente breve, i cui risultati sono costantemente ri-valutati e il cui scopo primario è quello di abbattere i rischi annessi, rispettivamente, all’avvio del progetto e al suo dispiegamento e manutenzione in produzione.
Milestone
Esattamente come le fasi, inoltre, può inizialmente far storcere il naso il fatto che vengano prescritte delle esplicite milestone: i prodotti complessi spesso vedono coinvolti molti team auto-organizzati e paralleli e risulta quindi normale individuare dei punti di allineamento in cui condividere il know-how al fine di creare una cultura condivisa a livello aziendale, sia metodologica che tecnico/tecnologica.
Questo è, appunto, l’obiettivo delle milestone di DAD, basti pensare, come esempio, alla presenza della milestone Proven Architecture all’interno della fase di Construction che fa propri alcuni aspetti della soppressa fase di Elaboration di RUP affidandoli direttamente ai team.
Extended Product Backlog
In ragione di tutto ciò, non sorprende, inoltre, come in DAD il concetto di Product Backlog sia “extended”, passando da strumento atto a elencare e priorizzare le funzionalità da realizzare, a strumento che consente di mettere in evidenza tutte le attività da gestire: si pensi alle azioni di riduzione del debito tecnico o a quelle di risoluzione dei bug.
Da DAD a Disciplined Agile 2.0
Quanto appena descritto rappresenta la struttura portante di DAD, ancora estremamente valido se si considerano singole iniziative specializzate all’interno della propria struttura.
Dal 2012 ad oggi, però, molte cose sono cambiate. In particolare, l’avanzata del movimento DevOps, unitamente ai Microservices e al Cloud come mainstream architetturale, ha portato Ambler e Lines a rivedere l’impostazione originale del loro hybrid-framework, rilasciando, ad agosto del 2015, Disciplined Agile 2.0 (DA2), che estende il campo di applicazione all’intera organizzazione sempre però con forte riferimento all’IT, oggi come non mai elemento essenziale di ogni iniziativa di business.
Disciplined Agile 2.0… senza Delivery?
In questa nuova forma, scompare il termine delivery dalla definizione, e resta solo Disciplined Agile. Questo non significa che in DA2 il delivery di un prodotto o di una soluzione non sia presente o importante, ma siccome si tratta di una sola parte del quadro generale, l’esplicito riferimento scompare dal nome del framework. Disciplined Agile 2.0 ora si caratterizza come: “A Process Solutions Framework for Enterprise IT”.
Tre macroaree: Disciplined Initiative, Disciplined DevOps, Disciplined Growth
La nuova versione dell’hybrid-framework propone tre macroaree di attenzione, strettamente correlate tra loro in modo inscindibile. Le vediao di seguito
- Disciplined Initiative, ossia tutta la parte organizzativa dell’IT che è a stretto contatto con le funzioni strategiche aziendali. L’obiettivo è quello di creare un legame diretto tra ogni singola iniziativa IT e un preciso obiettivo di business.
- Disciplined DevOps, è il cuore pulsante del framework in cui il delivery prende forma e la struttura si auto-organizza per rispondere il più rapidamente possibile ai nuovi obiettivi.
- Disciplined Growth, focalizzata sul management e sulla governance delle persone impegnate nell’IT.
È doveroso evidenziare che i termini “Disciplined Initiative” e “Disciplined Growth” non sono presenti in modo esplicito in DA2, ma sono un’astrazione qui utilizzata per semplificare la nostra trattazione.
DA2 evidenzia in modo efficace l’interrelazione tra tali aree, evidenziando come esse debbano lavorare con estremo sincronismo per poter ottenere benefici reali e miglioramenti tangibili.
Disciplined Initiative: la strategia
A livello strategico troviamo l’area Disciplined Initiative che mette un cappello a tutte quelle funzioni necessarie ad una integrazione tra le iniziative concrete di business e le attività della divisione IT.
Questo collante è fondamentale affinché ogni attività dell’IT sia direttamente e facilmente riconducibile ad un’azione di business (alias “di mercato”) in modo da poterne misurare il valore e il beneficio relativo. Se si fatica a trovare tale correlazione è necessario investigare sulla specifica iniziativa e capire perché la si sta attuando.
In questo scenario non sorprendono le attività di gestione inerenti al Portfolio Management, Product Management, Enterprise Architecture e Reuse Engineering legata al riutilizzo degli asset già presenti nella propria struttura.
Tutte e quattro queste attività di gestione sono strettamente legate tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche, in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile.
Disciplined DevOps: il braccio operativo
Il braccio operativo di DA2 trova posto nell’area Disciplined DevOps in cui la soluzione viene realizzata in allineamento agli specifici aspetti di delivery e deployment. Il tutto è supportato dalle funzioni di Program Management, Agile Delivery, Release Management, Data Management, Support e Operation.
Ritroviamo qui molto di quanto proposto già in DAD, ma con una nuova spinta verso il mondo DevOps, ossia verso un’integrazione e una collaborazione tra le varie aree interessate alla realizzazione della soluzione, supportate da un’automazione dei processi che sottendono il raggiungimento dell’obiettivo di un Continuous Delivery/Deployment in grado di reagire prontamente agli stimoli del mercato e alle mutevoli esigenze degli stakeholder.
Disciplined Growth: la governance del capitale umano
La terza area è Disciplined Growth e si rivolge agli aspetti di governance del proprio “capitale umano”. Se c’è una cosa che Agile e Lean hanno insegnato ai “burocrati” nel corso dell’ultimo decennio è che il successo di un’organizzazione dipende, prima di tutto, dalle persone che vi lavorano, per cui è fondamentale adottare le giuste azioni per favorire una cultura di crescita, collaborazione e continuous improvement.
Troviamo così le funzioni di IT Governance, Continuous Improvement e People Management, tutte orientate alla “cura” del nostro capitale umano.
Conclusioni
In questo primo articolo abbiamo cercato di capire il modo in cui Disciplined Agile 2.0 si è evoluto a partire da esperienze precedenti: dagli approcci iterativi e incrementali degli anni Novanta fino alla rivoluzione Lean/Agile di questi ultimi anni.
Come emerge da questa prima “spulciata” a DA2, molte delle novità sono state introdotte per creare maggiore sinergia aziendale (company’s awareness) e supportare lo sviluppo di soluzioni sempre più complesse con le più moderne soluzioni metodologiche e pratiche e con un time-to-market sempre più ridotto.
Nel prossimo appuntamento cominceremo ad entrare nel dettaglio del framework, concentrandoci sull’area qui denominata Disciplined Initiative, evidenziandone obiettivi, funzioni chiave e relazioni tra esse.
Nel frattempo vi invito a contattarmi per feedback e domande, tramite mail, Twitter o anche tramite il gruppo Agile@Scale Italy su LinkedIn.
Felice Pescatore è Innovation Manager e Microsoft MVP.
Nel suo lavoro, impiega quotidianamente approcci Lean/Agile per lo sviluppo di soluzioni software enterprise.
Nell’ultimo periodo si è dedicato particolarmente al mondo delle Startup con Lean Startup e all’ottimizzazione della Value Chain tramite DevOps, con uno sguardo sempre più ravvicinato al mondo della Internet of Things (IoT).