Agile Contracting, questo sconosciuto!

Quando si parla di progetti Agile uno dei principali scogli da superare riguarda la contrattualizzazione del proprio lavoro con l’ufficio acquisti del buyer. Per farla semplice, il procurement di qualsiasi società che sta acquistando un servizio da un fornitore esterno vuole avere la certezza che si ottengano tutti i risultati richiesti (scope) ad un costo prestabilito (cost) entro tempi definiti (time). Ma come si accorda questo con l’approccio Agile, in cui proprio lo scope non è un constraint (vincolo, ossia qualcosa di predeterminato)? Vediamo tre possibili opzioni: Time&Material, Graduated Fixed-Price e Time-boxed Fixed-Price.

L’Iron Triangle

Facciamo una breve digressione, molto introduttiva, in merito al famoso (ok, famigerato!) Iron Triangle. Nella gestione “pesante” dei progetti sono presenti tre vincoli che devono essere rispettati affinché l’esito finale possa definirsi positivo:

• Scope: il risultato atteso, ossia quello che il cliente si aspetta di avere alla fine del progetto a livello di funzionalità, che dovrebbe essere stato esplicitato e adeguatamente dettagliato in fase di requisitazione iniziale.
• Cost: quanto il cliente si aspetta di investire in termini economici per ottenere quanto descritto nello scope. Valore che è spesso definito dai reparti Sales/Procurement in fase di contrattazione.
• Schedule/Time: le tempistiche necessarie per svolgere le attività necessarie a traguardare lo scope, all’interno del cost concordato. In questo caso è chi si occupa della sviluppo vero e proprio che fornisce delle tempistiche che vengono poi “riviste” dal cliente.

Questi sono i tre vertici dell’Iron Triangle e la Quality del lavoro svolto dipende da come si bilanciano i tre vincoli (proprio in questo sta la bravura del Project Manager). Comunemente, dopo la contrattazione tra cliente e fornitore, si giunge ad un accordo formalmente contrattualizzato, in cui si esprimono nel dettaglio i tre vincoli di cui sopra (grazie ad un SoW -Statement of Work- e ad un planning preciso). Eventuali modifiche o aggiunte rispetto a  quanto previsto all’interno del contratto divengono Change Request che, una volta analizzate e valutate da un punto di vista economico e di tempistiche, saranno contrattualizzate come estensione.

L’ultima nota in merito all’Iron Triangle è la regola di interdipendenza tra i vincoli: se uno dei vincoli richiede di essere modificato allora anche almeno uno degli altri due dovrà adattarsi di conseguenza. Ossia, se voglio abbassare i costi bassi dovrò variare scope e/o tempi, se voglio consegnare in meno tempo aumenteranno i costi e/o diminuirà lo scope, se voglio aggiungere funzionalità aumenteranno i costi e/o aumenterà il tempo.

Stiamo parlando del cosiddetto modello contrattuale Fixed-Price, che sicuramente tutela entrambe le parti ma d’altro canto irrigidisce notevolmente il processo di realizzazione del progetto e la proposizione di reale valore per l’utente finale.

Abbracciare il cambiamento

Ora, ricordiamo cosa dice l’Agile Manifesto:

Customer collaboration
over
contract negotiation

e ancora:

Responding to change
over
following a plan

Potete quindi immaginare dove sia quello “scoglio da superare” di cui dicevo all’inizio: nella versione Agile del triangolo lo Scope NON è un vincolo, anzi, la sua variabilità è la base su cui si poggia l’offerta di reale valore al cliente.

Grazie a concetti quali Minimum Viable Product, Continuous Improvement, Value-Driven Delivery, Fail sooner – succeed faster, Immediate feedback, Iterative Development, etc… l’obiettivo degli approcci Agile è quello di fornire al cliente il maggior reale valore collaudato nel minor tempo possibile ad un costo variabile condiviso. Questo vuol dire che sarà il cliente stesso a definire le funzionalità a priorità maggiore che dovranno essere prodotte nella successiva iterazione e che dovranno essere complete secondo il significato di “completato” (Done) stabilito all’inizio del progetto. Embrace change è un’altro dei mantra che sentirete spesso nell’ambito Agile!

Agile Contracting, le opzioni a disposizione

Bene, adesso che abbiamo capito come l’Agile riesca a far fronte allo Scope non come vincolo bensì come produzione di reale valore, dobbiamo trovare l’accordo con il procurement del cliente nel quale non sarà definito a priori l’elenco di funzionalità finali del progetto ad un costo e tempo prefissato. Vediamo quali sono le nostre possibilità nell’Agile Contracting.

1. Time & Material

Questo modello contrattuale prevede una definizione a priori dei costi orari delle varie risorse del fornitore coinvolte nel progetto, oltre a quelli dei materiali utilizzati. In base ad una preventiva analisi dei requisiti il fornitore espone una stima di massima delle risorse e dei tempi necessari per la realizzazione del progetto, dalla quale il cliente può quindi desumere il costo finale. Chiaramente se nel corso della realizzazione del progetto dovessero arrivare nuove richieste o modifiche ai requisiti il fornitore e il cliente si metterebbero d’accordo indicando quali funzionalità a priorità maggiore devono essere inserite negli sviluppi, in che tempi andrebbero realizzate e con che costi. In questo modo il cliente ha una visione in tempo reale dell’avanzamento del progetto (scope), dei tempi necessari per il completamente delle singole funzionalità (time) e dei costi in base alle risorse coinvolte e dei materiali in uso (cost). Quindi avremo ciò che effettivamente di vuole ottenere ad un costo e nei tempi stabili insieme in corso d’opera. Situazione ideale, ma che si porta un problema proprio nella frase “in corso d’opera”: i procurement delle grandi aziende difficilmente avvalleranno un contratto nel quale non c’è conoscenza a priori dei costi! E figuriamoci se non sono presenti neppure tempi e scope definiti.

Andiamo per gradi. Nell’approccio Agile si vuole fornire al cliente reale valore nel minimo tempo possibile, quindi mi aspetto che già alla prima iterazione o al massimo alla fine della seconda il progetto stia realmente producendo valore secondo quanto stabilito con il cliente. Quindi lo scope è qualcosa che incrementa nel tempo e che offre i sui primi benefici sin da subito. Meglio che aspettare mesi e avere poi un prodotto differente da quanto ci si aspetta. Per mantenere un controllo sui costi a monte è possibile stabilire una forchetta di budget all’interno della quale il progetto dovrà attenersi. Nel contratto andranno quindi inserite le funzionalità a livello di Epiche – termine Agile per identificare le macro funzionalità di un sistema -, il numero totale di iterazioni che si prevedono di avere, le tipologie di risorse e materiali per iterazione e i costi per tipologia risorsa/materiale, nonché la forchetta di budget.

2. Graduated Fixed-Price

In questo modello si stabiliscono tre (o più) livelli di compenso per le rate card delle risorse del fornitore, in base alle tempistiche di rilascio. L’idea è che, stabilendo sempre con il cliente la priorità delle funzionalità e le iterazioni previste, se il fornitore rilascia la funzionalità prima di quando pianificato allora sarà applicato il livello più alto di rate card, se il fornitore rilascia rispettando quanto previsto sarà applicato il costo standard e nel caso in cui il rilascio dovesse essere in ritardo allora si applicherà il livello più basso di rate card. In questo caso sia il cliente sia il fornitore si assumono parte del rischio di progetto. La cosa importante è che questi livelli di rate card non devono essere visti come premi o penali a scapito della produzione di effettivo valore del progetto (quindi la sua qualità). Così il fornitore non farà in modo di consegnare software scadente per fare prima e il cliente non interverrà all’interno di una iterazione chiedendo modifiche in modo da rallentarne il rilascio. Anche in questo caso il contratto vedrà le funzionalità espresse sotto forma di Epiche, il numero di iterazioni previste, il budget di progetto e i costi del fornitore espressi secondo i livelli di compenso.

3. Time-boxed Fixed-Price

L’idea alla base di questo modello è di quantificare al cliente un costo di tutto il team di progetto per ogni iterazione, indipendentemente dall’effettiva composizione del team che lavorerà per la singola iterazione. Come sappiamo l’iterazione è un evento time-boxed quindi dato un costo del team di progetto per iterazione e dato il numero di iterazioni stimate avremo un costo complessivo di progetto inseribile nel contratto. Il rischio in questo caso è più a carico del fornitore che dovrà essere in grado di proporre un costo complessivo del team di progetto e dei materiali consono all’entità e tipologia di prodotto/servizio da fornire. D’altro canto il cliente ha la possibilità di modificare e prioritizzare le funzionalità del prodotto in base alle proprio esigenze, sapendo che se una nuova Epica richiede due iterazioni per essere sviluppata avrà un costo già definito a priori. Quest’ultima soluzione si differenza dal Time&Material poiché non richiede una stima puntuale delle risorse necessarie per ogni attività, riuscendo così a mantenere ancora più snello il processo di stima. Contrattualmente si dovranno definire i costi per team invece che per singola risorsa, andando a descrivere le risorse che faranno parte del team di progetto.

In conclusione è sempre una questione di fiducia

Tutte le tre le opzioni esposte hanno una base comune: la fiducia tra cliente e fornitore (ho parlato del concetto di fiducia all’interno dei progetti Agile in questo post su Linkedin). Se all’inizio del progetto non c’è una corrispondenza di fiducia tra le parti e non v’è chiarezza comune su cosa significa avere un approccio Agile allora non ci sarà tipologia di contratto che tenga, perché il progetto sarà, con buona probabilità, destinato a fallire.

I contratti Fixed-Price, tendenzialmente, funzionano anche in assenza di fiducia, proprio perché vincolano entrambe le parti con una definizione a priori chiara e dettagliata di cosa produrre, per quanto ed entro quando. Purtroppo negli ambiti odierni, che si tratti di una Digital Transformation o dello sviluppo di una start-up con nuovi modelli di business o ancora della revisione di un prodotto esistente, è impensabile prescindere da “abbracciare il cambiamento” anche se in fase avanzata di realizzazione: pena la produzione di qualcosa che non è ciò che l’utente finale desidera, ma solo quello che si pensava desiderasse all’inizio del progetto stesso.

Oltre alla fiducia, è altrettanto fondamentale avere non solo una profonda comprensione dell’Agile Mindset ma anche saper applicare questo mindset quotidianamente. Scegliete le persone che faranno parte del team con estrema attenzione e, ancor di più, individuate il giusto Agile Coach che possa essere da guida in questo cambiamento culturale. “Don’t do Agile, Be Agile”!