The value in splitting by value: a risk management perspective (IT)

Di Martina Gallo e Matteo Regazzi

(You can also read this article in English)

Quando si svolge la professione di Agile Coach per una società di consulenza è probabile che una delle ambizioni sia quella di aiutare un'azienda, una che si considera importante, ad adottare un modo di lavorare ispirato a quei 4 statement scritti 20 anni fa nel Manifesto for Agile Software Development.

Per far sì che quel modo di lavorare sedimenti, diventando soprattutto un modo di essere e di pensare, sappiamo da tempo che è necessario ma non sufficiente avere delle pratiche specifiche per la scrittura del software: bisogna valicare i confini del singolo team prima, e quelli della produzione software poi.

Agile è così diventato un termine con cui descrivere un modo di organizzare un'azienda, dai rapporti con i clienti a come si possono ideare nuovi prodotti: le due cose sono quasi sovrapposte ed in mezzo c'è tutto il resto, dalla gestione del budget alla codifica di un test. In questo complesso ambiente rischiamo di dimenticare che una gran parte del cambiamento del modo di lavorare deve avvenire proprio in come si sviluppa il software ed è cosa frequente incontrare team che scrivono codice basandosi su quanto hanno imparato leggendo codice scritto da chi, prima di loro, lavorava in modo tradizionale (la catena può essere più lunga, ma il senso è lo stesso).

In pratica prendiamo il Business, gli diamo le chiavi di una Ferrari e una pacca sulla spalla e quello, alla prima curva, tira dritto perché quando gira il volante si accorge che le ruote non fanno una piega. Un po' come quando si costruivano sistemi software in modo tradizionale usando quel processo che un certo Winston W. Royce poco più di 50 anni fa aveva detto che non funzionava (ma lo aveva detto a pagina 2 di una sua white paper [1]). Ma lì si inseriva intenzionalmente il bloccasterzo.

Come siamo arrivati all'attuale situazione ? Facciamo un balzo veloce alla fine del millennio scorso: i progetti informatici di successo (on time, on scope, on budget) erano rarità. A qualcuno è anche capitato di ritrovarsi a lavorare su un progetto dove non era chiaro nemmeno chi fosse il nostro utente, e toccava pure correre. Quale soluzione si stava implementando ? Ovvio, spendere più tempo nella fase di raccolta dei requisiti, e poi in quella di design, perché bisognava fare in modo di individuare in modo anticipatorio tutte le possibili direttrici di evoluzione e gestirle. E alé, tutti a produrre tovaglie di diagrammi UML (per lo più di tipo statico), nella speranza che nel frattempo uscisse qualche magico tool che facesse realmente diventare codice eseguibile quelle tovaglie.

Per fortuna è arrivato un gruppo di sviluppatori che ci ha fatto capire che quella curva del costo del cambiamento contro cui lottavamo poteva addirittura rivelarsi nostra alleata [2]. Ci abbiamo messo un po' a capirlo, all'inizio ero affascinante quell'immagine sul libro bianco di Extreme Programming dove si affermava che quella curva poteva appiattirsi rapidamente se si adottano particolari tecniche (pratiche) ma, soprattutto, se si segue un nuovo modo di gestire il rischio.

Lo spiega molto bene, in uno speech, J.B. Rainsberger [3]: se guardiamo solo il processo, la differenza evidente tra agile e il Waterfall "aggiustato" (quello con i link all'indietro, per capirci), è la lunghezza delle iterazioni. Ma ciò abilita un modo completamente diverso di gestire l'esposizione di un progetto al rischio fallimento.

Il rischio è definito come l’eventualità di subire un danno, economicamente una perdita, connessa a circostanze più o meno prevedibili [Treccani]

Quindi il cambiamento, che rappresenta un costo nel momento in cui si verifica e non è facilmente prevedibile, lo possiamo trattare come un rischio.

Ragionare in modo predittivo attraverso l’analisi dei rischi permette di mitigare possibili minacce, ma l’esito di questa analisi sarà verificabile solo nelle fasi finali della catena del processo.

La gestione del rischio, qualunque sia l’approccio, può essere influenzata fin da subito a partire dalla fase di pianificazione del lavoro, che ne determina il livello di esposizione. Negli ambiti dove le variazioni sono molto probabili, come quello dello sviluppo software, avviare una lunga pianificazione, molto dettagliata con l’obiettivo di attenersi ad essa il più possibile lungo tutta la fase di produzione, può rappresentare un fattore determinante per l’aumento del rischio.

Impostare le attività con l’obiettivo di avere continui riscontri che possano ridurre l’incertezza, fattore di misurazione del rischio, diminuisce quindi la probabilità di prendere una direzione potenzialmente errata. Inoltre, suddividere il lavoro distribuendo il rischio e gestendolo a piccole dosi, consente di agire tempestivamente ed arginare possibili minacce. Istituiamo quindi momenti finalizzati alla raccolta dei feedback, considerando questi come necessari per acquisire conoscenza e ridurne l’incertezza, accelerando il processo di apprendimento e di adattamento.

Come fa notare sempre J.B. Rainsberger, assumendo che per calcolare l’esposizione al rischio si moltiplichi la probabilità che ogni rischio ha di diventare un problema per il costo del singolo potenziale problema, per ridurre tale esposizione possiamo intervenire sui due fattori. Nel caso di un modello Waterfall si fa di tutto per abbattere la probabilità (lunghe fasi di raccolta dei requisiti, applicazione ossessiva del design anticipatorio) mentre in Agile si lavora per abbatterne il costo.

Vedere questo come la somma di più costi, permette di effettuare una ripartizione che ne riduce il rischio complessivo, non solo perché non viene sostenuto una tantum, ma anche perché permette di agire nel momento in cui ve n’è l'effettiva necessità.

Se il risk management fa del rischio l’elemento da considerare, valutare e mitigare, l’agile considera il rischio parte integrante del cambiamento. Possiamo affermare che il risk management sta al rischio come l’agile sta al cambiamento. Impostare quindi un lavoro che sia “value driven”, la cui bontà non sia direttamente proporzionale alla rispondenza del requisito iniziale, ma che piuttosto sia misurata sulla soddisfazione dell’utente finale, presuppone necessariamente un nuovo mindset, più duttile, che accettati il fatto che siamo in un mondo VUCA dove il cambiamento è l'unica certezza.

In pratica le cose diventano difficili e questo fa la fortuna degli agile coach che hanno lavoro garantito, almeno per un po'. Dobbiamo deliberatamente mettere in moto un ciclo continuo di miglioramento con il focus sul learning. Un modello su cui basarsi è quello dell'Emergent Learning [4] dove team e cliente, insieme, continuamente formulano ipotesi, le mettono in discussione attraverso esperimenti, accumulano esperienza, si adattano e formulano nuove ipotesi.

Più alta sarà la velocità e la precisione che vorremo o dovremo avere, maggiore dovrà essere la frequenza di questo ciclo di learning. Possiamo anche leggere il feedback direttamente dalla faccia dell’utente come quando si testano dei prototipi di UX. Questo è il riscontro che maggiormente ci interessa: un team che è in grado di far "provare" frequentemente ad un utente il frutto del proprio lavoro potrà effettuare scelte migliori.

Come per il pair programming, potremmo paragonare questo continuo confronto con il lavoro che fanno, nei rally, il pilota ed il navigatore. Una organizzazione moderna non può che orientarsi ad avere team che possano velocemente generare valore, riducendo il più possibile lo spazio-tempo che esiste tra la ricezione di una nuova esigenza e il feedback ottenuto offrendo una possibile soluzione, o Customer Lead Time.

Il primo passo sarà avere dei team che siano in grado di portare a termine, dall'ideazione alla consegna, la produzione di una funzionalità sufficientemente importante da poter essere apprezzata / valutata da un utente. Team che non siano semplicemente inter-funzionali, ma che siano dei veri e propri Feature Team [5], o dei team end to end. Per perseguire questo tipo di organizzazione uno strumento indispensabile è quello del Value Stream Mapping. Organizzazioni che lavorano su sistemi (deliberatamente o necessariamente) molto complessi, frutto dell'integrazione di diversi sottosistemi a loro volta complessi, possono faticare molto a raggiungere una configurazione che permetta a dei team composti da un numero ragionevole di membri (ragionevole dal punto di vista del learning) di consegnare valore alla fine di ogni breve iterazione, per cui una strategia di revisione dell'organizzazione non può prescindere dalla revisione delle architetture.

Il secondo passo, individuati i team, vuole che le esigenze utente che si vanno a soddisfare non dovranno più essere tagliate per componenti ma dovranno essere mantenute consistenti per valore utente. Se non sono INVEST [6] le esigenze, come possiamo poi pretendere che i team scrivano e lavorino user story che invece lo sono ?

Il terzo passo è quello di ricercare continuamente i feedback necessari per proseguire nella evoluzione del sistema. Un backlog esistente è utile come traccia, ma solo quando il nostro ciclo evolutivo vi impatterà direttamente allora rispetterà la modalità di risk management basata sulla riduzione dei costi di cambiamento.

Questi tre passi sono più lunghi di qualsiasi gamba, per poterli compiere dobbiamo ridurli di dimensioni e ripeterli, magari adottando un approccio miglioramento continuo, come per esempio Lean Change Management [7], che ci consenta di mantenere una visione sistemica della trasformazione che non sarà più un punto di arrivo bensì uno stato persistente.

Riferimenti

• [1] Managing the development of large software systems (Winston W. Royce)
• [2] Extreme Programming Explained: Embrace Change (Kent Beck)
• [3] The most effective thing that programmers learn from me isn't about programming (J. B. Rainsberger)
• [4] Emergent Learning: taking "learning from experience" to a new level (Marilyn Darling, Charles Parry)
• [5] Feature Teams Primer (Craig Larman and Bass Vodde)
• [6] INVEST in Good Stories, and SMART Tasks (Bill Wake)
• [7] Lean Change Management (Jason Little)