Eccoci al terzo appuntamento con il Manifesto Agile.
Scopriamo insieme il Terzo Valore, che nella forma originale cita:
Valore 3: LA COLLABORAZIONE COL CLIENTE più che la negoziazione dei contratti
mentre in DAD assume una forma che estende i destinatari della collaborazione:
Valore 3 (DAD review): LA COLLABORAZIONE CON GLI STAKEHODLER più che la negoziazione dei contratti
Questo terzo Valore è probabilmente quello più contorto e criptico da digerire, soprattutto per chi ha responsabilità di gestione.
Chiunque entra in un nuovo business si aspetta, con estrema naturalezza, di regolare il rapporto tra se e la controparte con un dettagliato contratto che metta in chiaro cosa spetti ad ognuno.
Nel mondo del Software la situazione è un po’ più complessa: gli stakeholder (e in particolare i key stakeholder) all’inizio non hanno ben chiaro cosa realmente vogliono, per cui, qualsiasi cosa si andrà a contrattualizzate, probabilmente, sarà ben lontano dal risultato finale. Ciò si traduce nell’impossibilità di stilare un contratto dettagliato poiché si sa già che, appunto, qualunque cosa vi verrà inserito non corrisponderà a quello che verrà consegnato.
La questione si focalizza, quindi, su come risolvere questo grattacapo.
Ebbene, la parolina magica è Collaborazione (Collaboration): bisogna coinvolgere gli stakeholder (DAD docet, non basta pensare al Cliente come singola entità) in modo che la percezione del prodotto finale cresca omogeneamente man mano che si procede nel suo sviluppo.
In pratica è come se si introducesse un “contratto dinamico” (dynamic contract) che si modifica grazie all’interazione continua con gli stakeholder.
Ok, tutto bello, ma quando gli stakeholder devono essere presenti?
Teoricamente sempre, praticamente è possibile identificare delle mailstone in base al tipo di ALCM adottato. Nel caso di DAD, sicuramente i key stakeholder devono essere presenti alla fine di ogni iterazione della fase di Construction, così come il loro apporto è fondamentale in quella di Inception. In realtà l’approccio è molto più elastico e il Team non deve avere “paura” e farsi prendere dal panico se uno o più stakeholder decidono di partecipare ad uno qualsiasi degli Accenti del 3C Rhythm, indipendente dall’elemento temporale a cui si applica (vedasi DAD, 3C Rhythm).
In sostanza il contratto si traduce in un concordato di intenti su quelli che sono i fattori chiave del sistema (Intentional Architecture, Agile Planning e Costing, Themi, ecc.) aggiungendo maggiori dettagli man mano essi diventano chiari e condivisi.
In fondo su qualcosa bisogna pur convenire, altrimenti è impossibile definire i confine (boundary) in cui ci si muove.
