Come tutti gli esperti del settore sanno, quando si apre un libro che insegna un nuovo linguaggio di programmazione, è scontato trovarsi difronte al classico listato “Hello World”.

Ma Disciplined Agile Delivery (DAD) non è un linguaggio di programmazione, bensì un framework per la governance dei progetti IT. In questo caso possiamo assimilare il nostro “Hello World” alla più ovvia delle domande che possono essere poste: perché DAD?

Una risposta esauriente non può essere certo data in poche righe, anzi verrà fuori in modo completo e convincente (spero) nel corso dei post e delle discussioni che si susseguiranno in questo gruppo. Cerchiamo però, ora, di riassumere gli elementi essenziali che possono spingere ad interessarsi di DAD.

Di Agile (e nel caso in cui si ha la fortuna di lavorare in aziende particolarmente attente al proprio processo gestionale, di Lean) si parla da tempo, spesso identificando e confondendo i relativi Valori e i relativi Principi con metodologie specifiche come Scrum ed XP. Ma Agile è molto più: si tratta di un modo diverso di concepire la produzione di software (Servizi) e ciò, qualunque sia la metodologia scelta, richiede una governance dell’intero ciclo di vita: dall’Idea alla Dismissione.

Su questo fronte le metodologie Agili “pure” risultano spesso inadeguate e, paradossalmente, le metodologie Tradizionali (da Waterfall al modello a Spirale) sono strutturate in modo più robusto per accompagnare l’intero Application Lifecycle Management (ALM).

Le metodologie Agili si concentrano sulla produzione di Valore, ma tale termine viene spesso assimilato alla produzione di codice, che se da un lato è il vero risultato del lavoro di una tipica azienda IT, dall’altro non è detto che sia l’unico costrutto a produrre valore. Un esempio: se gli stakeholder (non il solo Cliente!) richiedono un documento che descriva l’Architettura, tale documento è di per se un Valore e non c’è nessun motivo per sottovalutarne l’importanza, tutt’altro.

Ecco, possiamo considerare DAD come un framework orientato alla produzione di Valore, nell’accezione nobile del termine. E’ fondamentale sottolineare, in modo esplicito, che che DAD non è una metodologia ma, appunto, un framework che armonizza una serie di strumenti per consentire di gestire l'ALM in modo efficace ed efficiente, sfruttando profondamente il mondo Agile/Lean.

A questo punto si potrebbe obiettare: ma anche con Scrum è possibile gestire la produzione di software. L’affermazione è corretta, ma la produzione è solo una parte dell’ALM e la cosa si accentua nel mondo Enterprise. Si pensi ad esempio alla fase di analisi del Rischio ed Opportunità legate ad una nuova idea progettuale: come gestire la cosa con Scrum? o con XP? Probabilmente molti risponderebbero in modo “tradizionale”, introducendo una fase di Analisi che si avvicina a quanto fatto, ad esempio, con Waterfall. La cosa è più comune di quanto si immagini e, un’indagine di Forrester dello scorso anno (vedasi il post WATER-SCRUM-FALL) evidenzia proprio come quasi il 70% delle aziende mondali utilizzi un approccio ibrido (Agile/Tradizionale) per la gestione dei progetti IT piuttosto che un approccio Agile/Lean puro.

Visti questi dati ed evidenziata la necessità di una serie di strumenti che permettano un Agile Lifecycle Management (ALM), possiamo rispondere alla domanda del “perché DAD” in modo semplice e chiaro:

DAD fornisce una serie di strumenti armonizzati tra loro (framework) utili ad una proficua gestione del Ciclo di Sviluppo del Software in chiave Agile.

In fin dei conti perché reinventare la ruota se Scott Ambler e Mark Lines, due Guru in ambito ALM, hanno fatto il lavoro per noi? Semplice, non c’è nessun motivo! Quindi avanti con DAD e con la sua applicazione nei contesti operativi che ci vedono impegnati.

E’ doveroso evidenziare come DAD non sia l’unico framework pensato per l’ALM. Possiamo, ad esempio, citare lo Scaled Agile Framework (SAFe) di Dean Leffingwell, che rappresenta una valida alternativa. Tuttavia DAD si adatta praticamente a progetti e contesti di tutte le dimensioni e supera alcune problematiche ostiche come la gestione di più Team che collaborano sullo stesso progetto: in tale frangete SAFe suggerisce di usare l’approccio Scum of Scrums, ma questo si è rilevato ostico e non particolarmente efficace.

Sperando di aver dato sufficienti elementi per lo Start del gruppo, chiudiamo questo primo post sul tema con la definizione che Lines dà di DAD:

“The Disciplined Agile Delivery (DAD) decision process framework  is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware.”