I Quattro Valori dell’Agile Manifesto: quarto valore

Oggi concludiamo questa mini serie di quattro post dedicati all’analisi degli altrettanti Valori dell’Agile e della relativa trasposizione in DAD. Vediamo allora com’è e come viene definito il Quarto Valore:

Valore 4: RISPONDERE AL CAMBIAMENTO più che seguire un piano

fatto proprio, nell’identica forma, anche da DAD.

Questo Valore rappresenta, con molta probabilità, il silver bullet per una prima adozione di Agile in un nuovo contesto aziendale.

Spesso, infatti, l’Agile si tira fuori dal cilindro quando ci si trova difronte a questioni del tipo:

“Come faccio a sviluppare il sistema con questi requisiti così fumosi (smoky)?”, “Possibile che debba aspettare che l’esperto di dominio abbia prodotto l’analisi esaustiva e definitiva prima di produrre qualcosa da mostrare agli stakeholder?”

Ebbene, qui l’Agile mostra i muscoli e mette nero su bianco la comprovata impossibilità di definire in modo puntale i requisiti all’inizio del progetto, abbandonando la presunzione del modello waterfall puro. Chiaramente esistono eccezioni (si pensi a sistemi mission critical), ma nel 98% dei casi è effettivamente così.

Come si reagisce a questa incertezza? Abbiamo ormai imparato che non esiste una strada predefinita per l’adozione di Agile, infatti ogni Team trova la propria, affidandosi all’ esperienza maturata e derivata dall’applicazione disciplinata della metodologia (o del framework) che più ritiene congeniale.

Attenzione: l’Agile non è “buon senso”, tutt’altro. Esso implica disciplina e rigore, ma, soprattutto, un forte cambiamento culturale.

Sicuramente l’adozione di un framework @scale come DAD dà un supporto per imparare a governare l’incertezza di cui sopra. Ciò avviene, soprattutto, gestendo appropriatamente la fase di Inception: si pensi, ad esempio, all’introduzione di opportuni sweet spot (o anche hot spot) nell’Intentional Architecture, consentendo così di apportare cambiamenti mirati e sostenibili laddove, durante le iterazioni (Construction phase), ci si accorga che l’Architettura debba essere modificata per supportare adeguatamente gli scenari contemplati. Un ulteriore suggerimento può essere quello di definire una user story attraverso 3 step (Concept, Review, Finalize) prima di inserirla all’interno di una iterazione.

La necessità di cambiamento non avviene, però, solo perché un requisito non è chiaro, ma anche perché esso è del tutto sconosciuto, visto che il key stakeholder ne ignora l’esistenza finché non comincia a “toccare con mano” la soluzione e si rende conto che ha bisogno di altro… qualcosa di cui si era “semplicemente” dimenticato!

Governare l’incertezza richiede: lavoro in stretta sinergia del Team (valore 1), coinvolgimento attivo degli stakeholder (valore 3), maggiore conoscenza del dominio di riferimento, raggiungibile tramite lo sviluppo di soluzioni incrementali e funzionali (valore 2) e…. chiaramente abbracciare il cambiamento (valore 4). Il cerchio si chiude!

Termina qui la nostra parentesi su quello che l’amico Fabio Armani definirebbe Back to Agile!, con un pizzico di DAD, ricordando che: se anche uno solo di questi Valori non è presente nel nostro lavoro (o nelle metodologie che applichiamo) non stiamo operando in un contesto Agile, per quanto dinamico esso sia.