Contratti Lean Agile

I parte: Una nuova frontiera per clienti e fornitoridi

Con questa nuova serie affrontiamo una tematica molto particolare e importante: in che modo si possono stipulare, gestire ed eseguire contratti in un contesto Lean/Agile? L'adozione di tali metodologie in aziende più o meno grandi, infatti, comporta anche un'adeguato aggiustamento per quel che riguarda i contratti.

Introduzione

Con il crescere dell'adozione delle metodologie Lean Agile in contesti e aziende sempre più grandi, il tema della gestione ed esecuzione dei contratti nel mondo Lean Agile sta diventando sempre più attuale. Ciò non vuol dire che in aziende più piccole la problematica sia meno sentita, dato che i contratti sono una realtà per molti sviluppatori e molte imprese.

Anche nella mia esperienza di consulenza e coaching Lean Agile una domanda che mi viene posta frequentemente è la seguente: "È possibile stilare contratti in ambito Agile?" La mia risposta è sinceramente positiva, ma è importante capirne le motivazioni.

Per quanto detto, ritengo sia utile raccogliere in una serie di articoli un insieme di fondamenti teorici e di considerazioni alla base dei contratti Lean Agili e contemporaneamente elencare, descrivendole brevemente, le principali varietà di contratti possibili quando si utilizzano tali metodologie.

Di cosa parleremo nella serie

La struttura della serie prevede un primo articolo in cui si descriveranno le motivazioni e le basi concettuali su cui fondare tutti i ragionamenti inerenti questa tematica: parliamo dei solidi fondamenti teorici che giustificano la realizzazione di nuovi tipi di contratto rispetto a quelli cui la tradizionale prassi aziendale ci ha abituato.

La seconda parte della serie affronterà dieci problematiche da tenere presenti nel momento in cui si vogliono realizzare dei contratti che siano idonei alle metodologie agili.

Infine, la terza parte concluderà la serie illustrando un insieme di diverse tipologie di contratti agili. Per ciascuna di esse verranno discusse caratteristiche, applicabilità, punti di forza e debolezza.

Partirò dunque con il rendere evidente una falsa dicotomia concernente un'ipotetica contrapposizione tra gestione dei contratti e rapporto con i clienti.

Falsa dicotomia

A mio avviso il più importante elemento per identificare una metodologia come agile è la sua aderenza ai valori contenuti nel Manifesto Agile [1]. Tra i quattro principi fondamentali presentati nel Manifesto, uno è relativo proprio al tema qui trattato:

"La collaborazione col cliente più che la negoziazione dei contratti".

Questa frase evidenzia una falsa dicotomia: la possibilità di collaborare con il cliente sembrerebbe contrapporsi, a una prima osservazione, alla stesura e negoziazione dei contratti. Nulla di più falso, come cercherò di dimostrare in quest'articolo, nel quale esporrò le ragioni per cui è possibile far convivere la collaborazione con il cliente con la negoziazione dei contratti. Se leggiamo il Manifesto vediamo come i suoi diciassette firmatari dichiarano che anche gli elementi sulla destra di ogni frase devono essere valutati positivamente, quindi se la collaborazione con il cliente va favorita rispetto alla negoziazione dei contratti, questo non implica che le metodologie agili neghino la possibilità di utilizzare dei contratti nei rapporti con i nostri clienti.

Il parere di molti è che ci si possa spingere oltre e affermare la tesi, che emergerà anche in questa serie, in cui si afferma che la collaborazione con il cliente dovrebbe essere la base su cui stilare e gestire i contratti stessi. Il termine "collaborazione" rappresenta la chiave di volta dell'intero discorso, quello su cui soffermare la nostra attenzione.

Collaborazione e adattamento

A tal proposito mi pare giusto ricordare la frase di Charles Darwin che afferma il seguente concetto:

"Nella lunga storia del genere umano (e delle specie animali, anche) coloro che hanno imparato a collaborare e improvvisare più efficacemente hanno prevalso."

Nella citazione è presente oltre al termine "collaborazione" anche "improvvisazione" che nel contesto delle metodologie Lean Agile assume la valenza di processo iterativo e incrementale, basato sulla creatività, sulla capacità di controllo e adattamento di team auto-organizzati, che portano a realizzare prodotti di valore just in time, con i minori sprechi e la massima qualità possibili.

Partendo da queste considerazioni, passo a esaminare alcuni concetti che rappresentano a mio parere le fondamenta dell'intera tematica.

Scopo dei contratti

Qual è lo scopo primario dei contratti? Quali sono le motivazioni che spingono le due parti coinvolte a scrivere dei contratti? Possiamo affermare, senza ombra di dubbio, che le risposte sono essenzialmente date dalla difesa degli interessi di ciascuna parte e dalla gestione di eventuali rischi o comportamenti lesivi da parte dei due attori. In pratica le parti si contrappongono in un rapporto che non si basa sulla fiducia o sulla collaborazione, ma piuttosto sull'ipotesi che, in assenza di una difesa offerta appunto dal contratto, la controparte finirà con il danneggiarci.

Ovviamente i contratti sono quasi sempre stilati da avvocati e nella loro categoria le considerazioni appena effettuate rappresentano proprio il fondamento della disciplina. Questo ci porta a ricordare il famoso "dilemma del prigioniero", proposto negli anni cinquanta del XX secolo da Albert Tucker come problema di teoria dei giochi, e nel quale si dimostra come la logica convenzionale, che vede i due prigionieri scegliere alla fine una soluzione non ottimale, sia basata sul fatto che alla base del loro rapporto non c'è fiducia e trasparenza.

Una soluzione più favorevole a questo paradosso potrebbe trovarsi solo a livello sistemico, abbandonando la prospettiva egoistica per scegliere un'opzione che si fondi sulla fiducia nell'altro. In pratica su quella che Stephen R. Covey chiama una logica "win-win" (vedere "I sette pilastri del successo").

 

 

Figura 1 - Le quattro possibili soluzioni del dilemma basato sui concetti di vantaggio e svantaggio.

 

Strategie "perdenti"

Basando la loro logica sulla saggezza convenzionale, le aziende inevitabilmente sono attente esclusivamente ai propri interessi. Il pensiero tradizionale su cui è basata tutta l'industrializzazione fonda i propri principi sulla contrapposizione delle parti e su un'equazione degli interessi reciproci in cui si ipotizza che il risultato finale possa essere, nella maggior parte dei casi, negativo (la somma di vincita e perdita delle due parti porta a un risultato negativo) o alla meglio a somma zero: uno vince tanto quanto l'altro perde.

Nella figura 1 vengono mostrate le quattro possibili soluzioni del dilemma.  Nell'approccio tradizionale le due parti, cliente e fornitore, finiranno per ricadere nella soluzione di perdita reciproca ("lose-lose") o, alla meglio, nella possibilità di avere una parte che vince e l'altra che perde ("lose-win" o "win-lose"). Potrei anche azzardare che, utilizzando metodologie tradizionali le possibilità di ricadere nella prima casistica, in cui entrambe le parti si ritrovano ad aver perso qualcosa, è piuttosto forte.

I contratti tradizionali sono quindi necessari per limitare comportamenti opportunistici. Non a caso sono pieni di clausole e vincoli inseriti appositamente per limitare i rischi e per punire la parte che non rispetterà le condizioni negoziate. Inoltre, questa caratteristica rende necessaria la definizione chiara e univoca di tutti gli elementi che sono oggetto del contratto stesso: siano essi la realizzazione di un prodotto (software) o l'offerta di servizi. Questo in pratica favorisce l'impiego di metodologie tradizionali, come il waterfall,  nelle quali vengono definiti ambito (insieme delle funzionalità di un sistema), costo e tempo in maniera quanto più rigorosa e fissa durante le primissime fasi di progetto e possibilmente prima della stesura del contratto stesso.

Approccio agile

Nell'approccio agile si suppone che l'altra parte agirà in buona fede e che quindi avremo bisogno di minori difese per proteggerci dall'altro. La collaborazione diviene il veicolo di rapporto principale ed è utilizzata come strumento per far sì che la contrapposizione si trasformi in opportunità per entrambe le parti.

So che molti lettori penseranno a questo punto che il discorso da me fatto è utopistico e non attuabile concretamente. Mi sento di dissentire da tale affermazione dicendo che invece oramai esistono molti e comprovati casi di successo nell'impiego di questa filosofia, anche in grandi e giganteschi progetti come avrò di argomentare più avanti.

 

 

Figura 2 - Non si pensi che l'idea dei contratti agili sia solo un'utopia o un sogno innocente. Esiste oramai una casistica di situazioni di successo che sembrano dimostrare l'attuabilità.

 

Alcune tra le chiavi del successo di quest'approccio sono le seguenti due: da un lato lasciare che sia la relazione a limitare l'opportunismo, dall'altro utilizzare il contratto per introdurre incentivi.

La relazione limita l'opportunismo

Nel primo caso, la relazione basata sulla fiducia e sulla collaborazione, in cui tutte le scelte e le attività sono pensate per portare del beneficio a entrambe le parti, diventa un mezzo per limitare l'opportunismo da parte di uno dei due attori coinvolti: cliente o fornitore. Questo innesca un circolo virtuoso dato dal fatto che il contratto potrà essere meno vincolante e quindi in grado di migliorare la relazione favorendo la cooperazione (vedere a questo proposito le Review di prodotto al termine di ogni iterazione proprio di Scrum o di molte altre metodologie iterative e incrementali quali ad esempio eXtreme Programming); al contempo, si ottiene la libertà dal dover definire in modo fisso e vincolante tutte le variabili di progetto (ambito, costi e tempi). Questo consente di gestire in modo efficace i possibili cambiamenti, favorendo entrambi nel corso della realizzazione.

La possibilità di effettuare validazioni e verifiche di quanto realizzato da parte del cliente con cicli brevi (dell'ordine di una o di poche settimane) consente al fornitore di modificare le funzionalità o il prodotto stesso allo scopo di massimizzarne il valore a beneficio del cliente. Più brevi saranno i cicli di feedback, maggiori le opportunità di "cambiare rotta" allo scopo di essere più competitivi sul mercato o di poter evitare di realizzare funzionalità ridondanti e inutili che rappresentano uno spreco (come spesso accade utilizzando metodologie tradizionali).

Sprechi inutili

Se una funzionalità di un prodotto non viene mai utilizzata, si tratta ovviamente di uno spreco. Uno dei principi del pensiero Lean è proprio quello di evitare con ogni mezzo gli sprechi di qualunque tipo. Quello relativo a funzionalità inutili, è a mio avviso uno dei più pericolosi sprechi possibili. Innanzi tutto perche' utilizzando le metodologie tradizionali scopriremo di essere incorsi in questa situazione troppo tardi, ossia dopo che il sistema o il prodotto è stato realizzato e rilasciato ai clienti finali che ne riscontreranno le mancanze o le ridondanze.

Inoltre ricordiamo lo studio dello Standish Study Group, riportato da Jim Johnson (chairman) a XP2002, che mostra come ben il 45% delle funzionalità di sistemi software (in gran parte realizzate con metodologia waterfall) non venga mai utilizzato dagli utenti finali.

 

 

Figura 3 - Quanto vengono utilizzate le funzionalità dei sistemi software? "Mai" per ben il 45% di tutte le funzionalità dei sistemi realizzati con metodologie waterfall: uno spreco enorme, che va eliminato.

 

In pratica si lavora per realizzare un prodotto di circa il doppio delle funzionalità rispetto a quelle realmente utilizzate. A peggiorare la situazione, il rapporto tra funzionalità realizzate e complessità del sistema non è lineare ma piuttosto esponenziale. Questo porta a costi ben più alti del 45% e a una mole di lavoro maggiore, alla quale spesso si accompagna una qualità di prodotto incrementalmente più scadente.

Contratto rigido: un rischio per le reali esigenze del cliente

Una delle peggiori situazioni in cui ci si può venire a trovare è data dall'aver realizzato bene un sistema o un prodotto non valido: il sistema è funzionante e ben fatto… ma non era ciò che serviva, ossia non risponde alle esigenze dei suoi utenti finali.

Quest'evenienza è piuttosto probabile nel momento in cui fissiamo tramite un contratto, all'inizio del progetto, tutte le variabili (in particolare l'insieme dei requisiti) e come fornitori cerchiamo con tutti i mezzi di rispettare tali vincoli, perche' il contratto lo richiede e il cliente sarà pronto a rivalersi di quanto scritto in esso. Sul versante opposto, quella del cliente in questo caso è una "vittoria di Pirro" in quanto è proprio la rigidità del contratto a imporre di non poter giungere al risultato sperato. L'unico risultato che il cliente potrà ottenere è quello di scaricare le colpe di un eventuale fallimento sul fornitore e di averlo inchiodato a realizzare esattamente quanto pensato mesi, se non anni, prima. Peccato che il contesto, le esigenze e il mercato cambino (sic).

Ricordiamo a questo punto il principio Lean del "defer commitment" ossia la possibilità di poter prendere le nostre decisioni più tardi possibile, in quello che viene chiamato "l'ultimo momento responsabile", avendo quindi il tempo per massimizzare la quantità di informazioni su cui basarsi. Quest'opportunità ci viene offerta dall'impiego di alcune pratiche quali:

  • lasciare sempre più opzioni e quindi ritardare la necessità di dover scegliere anticipatamente;
  • rendere il sistema aperto al cambiamento;
  • quando sia necessario prendere una decisione, aspettare l'ultimo momento oltre il quale sarebbe inutile effettuare una scelta.

Un contratto per indurre incentivi

La seconda chiave di successo dell'approccio è relativa alla possibilità di utilizzare nuove formule di contratto meno legate al concetto di limitare possibili rischi e di vincolare in modo rigido l'operatività delle due parti, e più aperte alla possibilità di indurre degli incentivi. Nelle varie tipologie di contratto, di cui parleremo nella terza parte della serie, vedremo come possano esistere forme contrattuali nelle quali la cooperazione tra le parti sia incoraggiata da una serie di incentivi economici o di altra natura, fino a promuovere un processo di cooperazione reciproca sempre più proficua tale da far stringere tra clienti e fornitori delle vere e proprie partnership. Esempi di questo tipo di contratto possono essere dati dalla forma contrattuale proposta da Robert C. Martin in cui il meccanismo d'incentivazione economica è esplicito, o dal contratto "change for free, pay for nothing" ideato da Jeff Sutherland. Queste e altre tipologie di contratto simili dal punto di vista dei presupposti, saranno descritte in dettaglio più avanti nella terza parte della serie.

Un esempio dal mondo reale

Un esempio su vasta scala di quanto detto finora è esterno al dominio IT e riguarda la realizzazione, iniziata nel 2002, del nuovo Terminal 5 (T5) nell'aeroporto Heathrow di Londra, il più congestionato in Europa.  Il costo stimato del progetto, che a quel tempo rappresentava il più grande programma di costruzione mai realizzato in Europa, era di circa 3.8 miliardi di sterline.

Questo programma è stato caratterizzato da parecchie differenze rispetto all'abituale modo di conduzione di tali opere. In primo luogo la British Airports Authority (BAA), che è una delle più grandi società di gestione aereoportuale britanniche, si era impegnata pubblicamente ad aprire la prima fase del T5 il 30 marzo 2008. Inoltre, diversamente dalla maggior parte dei gestori di infrastrutture, BAA ha scelto di eseguire il programma direttamente, insistendo sul fatto che un outsourcing sarebbe costato di più, non meno.

 

 

Figura 4 - Il T5 dell'aeroporto londinese di Heathrow rappresenta un caso di applicazione di nuove formule contrattuali a grandi opere, esternamente al dominio IT.

 

Verso la fine del 2004, Tony Douglas (amministratore delegato di T5) e Andrew Wolstenholme (direttore di costruzione), assieme al loro team di leadership, hanno avuto la necessità di prendere un'importante decisione riguardo l'amministrazione e la strategia degli acquisti da adottare per le fasi successive del progetto. Il fondamento della strategia di gestione del progetto di BAA è stato il T5 Agreement (l'accordo T5): un contratto che gestiva la relazione tra BAA e tutti i fornitori di primo livello di T5 e che si discostava notevolmente dai concetti tradizionali di un contratto di costruzione.

Dalle clausole agli incentivi

Invece di enunciare una serie di clausole, accettando che le cose sarebbero potute andar male e cercando di passare la colpa e recuperare i soldi dai fornitori, l'accordo T5 era volto a creare incentivi per i comportamenti positivi di "problem-solving" che in primo luogo non avrebbero permesso alle cose di andar male. BAA considerava tale atteggiamento fondamentale per la creazione di un team di progetto totalmente integrato con i fornitori, consentendo a questi ultimi di raggiungere prestazioni eccezionali. L'etica di fondo è ben espressa dalla affermazioni del direttore commerciale di T5:

"Abbiamo dovuto accettare che BAA avesse tutti i rischi per T5. Era qualcosa che non potevamo passare ad altri. Il vantaggio è che accettando che tutti i rischi fossero i nostri, la negatività può essere tolta dalla relazione, lasciando spazio all'innovazione e creando l'opportunità per le persone coinvolte di operare a livelli che prima non era possibile raggiungere (...). Potete quindi chiedere alle persone di perdere il loro forte legame con l'azienda d'appartenenza, e invece di pensare al progetto come al loro amore primario" .

L'attuazione dell'accordo T5 era legata a una politica commerciale simile a quella di un contratto a spese rimborsabili con una serie di obiettivi d'incentivazione.

Per dovere di onestà il T5 Agreement non è stato soltanto una storia di successo, ma anche una storia di fallimenti a partire dal 2008, dovuti però a cause estranee alla natura dell'accordo che invece è servito anche nei momenti più critici a dare il supporto necessario a tutte le parti (BAA e fornitori) per poter raggiungere alla fine la meta prefissata.

Ho voluto fare questa lunga digressione in un mondo diverso da quello dell'IT, per far comprendere come anche opere enormi possano avvalersi di una filosofia contrattuale e di una gestione delle forniture volta a creare relazioni di successo reciproco, basandosi sul fatto che il contratto può indurre degli incentivi e che la relazione stessa possa contrapporsi all'opportunismo di una delle parti in causa.

Approccio predittivo verso empirico

Da un punto di vista concettuale, i due modelli ("tradizione" e "agile") si contrappongono, non solo per quanto detto e per la natura iterativa e incrementale delle metodologie agili, che si differenzia nettamente da quella monolitica basata su fasi successive e a cascata di quelle tradizionali, ma anche per le fondamenta filosofiche su cui si basano.

Le metodologie tradizionali adottano un approccio prettamente predittivo o meglio deterministico, mentre quelle agili un approccio empirico. Vediamo quindi di comprendere meglio cosa questo implichi cercando di andare un po' più a fondo nella questione partendo dalla definizione dei due termini.

Determinismo

Parlando di approccio deterministico leggiamo com'è descritto su Wikipedia:

"Escludendo qualsiasi forma di casualità nelle cose, il determinismo individua una spiegazione di tipo fisico per tutti i fenomeni, riconducendola alla catena delle relazioni causa-effetto ovvero al principio di causalità. La principale conseguenza è che date delle condizioni iniziali tutto quel che accadrà nel futuro è predeterminato in modo univoco dalle leggi fisiche dell'Universo."

Dunque la chiave di volta è data dall'esclusione della casualità e dal convincimento che se determiniamo in modo quanto più possibile esatto quali sono le leggi che regolano dall'inizio alla fine il comportamento di ciascun elemento di un sistema, saremo in grado di conoscerne l'evoluzione a qualsiasi istante.

Questa logica è proprio ciò che sta alla base tanto del pensiero di management scientifico ideato da Taylor e del Fordismo, ossia della produzione di massa, quanto delle metodologie di project management tradizionali. Il modello a cascata è quindi una perfetta espressione di questo pensiero filosofico. Ecco perche', utilizzando l'approccio deterministico o predittivo ha senso fissare sin dall'inizio le variabili di sistema (ambito, tempo e costi) e quindi seguirne l'evoluzione mediante strumenti di gestione come il Gantt e il Pert.

Non tutto il determinismo vien per nuocere…

Ovviamente esistono degli ambiti in cui l'utilizzo di quest'approccio ha assolutamente senso. Questi sono essenzialmente legati a contesti e sistemi semplici o al più complicati; in campo edile o nell'ingegneria delle costruzioni è ragionevole utilizzare una metodologia tradizionale: ad esempio per costruire un edificio o un ponte ci aspettiamo una successione di fasi di lavoro simili a quella di un processo "stage and gate" o a quella del waterfall prevedendo quindi la successione di una fase di raccolta requisiti, una di analisi, poi la progettazione, la realizzazione ed in infine la verifica e il collaudo dello opera realizzata.

Tutto questo ha un senso perche' un edificio, una volta realizzato, non dovrà essere modificato se non dopo un periodo piuttosto lungo per rispondere alle esigenze dei suoi abitanti o piuttosto per contrastare il deterioramento con il tempo della sua conformazione, ad esempio la facciata o, in casi più gravi, parti della sua struttura).

I contratti convenzionali possono e devono proteggere questa linea di pensiero offrendo quindi strumenti legali e clausole che vincolino essenzialmente il fornitore a realizzare quanto definito nel contratto. Da parte sua il fornitore cercherà di proteggersi chiedendo al cliente di determinare in maniera univoca l'insieme dei requisiti sin dalle prime fasi di progetto e immettendo clausole che impediscano o riducano il numero di possibili cambiamenti alle specifiche concordate: ciò porta alle famose "change request". "Se vuoi apportare una modifica a quanto concordato dovrai pagarmi una somma in più". Tale richiesta da parte del fornitore serve a proteggerlo dal fatto che, oltre ad avere gran parte delle clausole contrattuali a suo svantaggio, il cliente possa continuamente cambiare idea e quindi costringerlo a continue rilavorazioni non retribuite sul prodotto che possono ulteriormente allungare i tempi di sviluppo oltre che ritardare la data prestabilita.

Questo circolo vizioso porta alla proliferazione di funzionalità inutili richieste e poi realizzate che appunto determina il 45% di feature mai utilizzate dagli utenti finali. Come vediamo non è colpa diretta di nessuna delle due parti se si giunge a tale disfunzione: è di fatto illusorio predire "up front" ("anticipatamente") quali devono essere tutte le funzionalità presenti nel sistema ma, contrariamente a quanto potrebbe rappresentare un successo e un reciproco vantaggio per entrambi, il contratto richiede di fissarle e determinarle in modo rigido, spesso assieme a tempistiche e costi. Questi contratti, molto utilizzati nel mondo IT tradizionale, si chiamano "fix time, fix price" (costi e tempi fissi) e verranno trattati nella seconda parte della serie.

Il triangolo di ferro

Tali contratti sono basati sulla mancanza di fiducia reciproca e favoriscono comportamenti di non trasparenza. Per non rimanere troppo in astratto, cerco di fare un esempio concreto: il fornitore si trova ingabbiato dal fatto che tre delle quattro variabili di progetto (per completare l'insieme manca la qualità) sono fissate costituendo quello che viene chiamato il triangolo di ferro. Dato che una serie di cambiamenti saranno ovviamente richiesti, che nella realizzazione del prodotto o servizio potranno esserci problemi non previsti e che esistono molto probabilmente delle penali relative alla consegna oltre i tempi prestabiliti, una possibilità per il fornitore è quella di gonfiare il preventivo aumentando il numero di giornate previste o il numero di risorse allocate.

Come vediamo, l'intero rapporto si basa su una serie di comportamenti difensivi se non eticamente riprovevoli. Se a questo punto pensate che stia esagerando, v'invito a osservare ciò che realmente accade in molti rapporti tra clienti e fornitori. A mio avviso non è molto difficile trovare questo tipo di comportamento in parecchi casi concreti.

La crisi del determinismo

Tornando al determinismo, va detto che in realtà anche in ambiti come l'edilizia o l'ingegneria le più recenti soluzioni sono sempre meno basate su principi predittivi, specialmente nella realizzazione di opere uniche (vedere teatro di Sindney, …) o di altre realizzazioni all'avanguardia. Inoltre a partire dagli anni Venti del secolo scorso il pensiero deterministico è stato scosso dalle sue fondamenta perdendo il suo principio fondamentale. È stato proprio il principio d'indeterminazione scoperto da Heisenberg che ha fatto venir meno lo stesso presupposto teorico della causalità e far nascere l'idea che "è necessario tenere conto che fenomeni basilari della realtà sono descrivibili solo in termini probabilistici".

Tale crisi non si è riflessa immediatamente nelle scienze e dottrine apparentemente più lontane (come possono essere architettura o legge) e quindi meno direttamente coinvolte nella crisi del determinismo. In molti casi durante il secolo scorso (almeno nella prima metà) molte discipline hanno continuato a fondarsi su principi deterministici e ad adottare un approccio di tale tipo. Questo si è riflesso anche nella nascente informatica che, per decenni, ha inseguito la chimera di poter essere considerata unicamente come una disciplina ingegneristica cercando in questo modo di riscattarsi dalla propria gioventù e spesso dal pionierismo degli anni Cinquanta del XX secolo.

Ecco perche', a mio avviso, sono state utilizzate metodologie tradizionali come il waterfall in un ambito che ha invece caratteristiche molto diverse da quelle di sistemi semplici o complicati, essendo sostanzialmente complesso. Basti considerare che un sistema software, anche una volta realizzato e rilasciato, per sua stessa natura deve evolvere e trasformarsi fino a quando non diventa obsoleto. Da un punto di vista pratico anche nelle sue fasi d'ideazione e realizzazione, in base a quello che il cliente, il mercato e il contesto esterno richiedono, un sistema software deve essere modificato piuttosto spesso fino a raggiungere il suo primo rilascio in produzione. Le metodologie agili e il pensiero lean ben si sposano con questa necessità, basti ricordare l'ultimo dei quattro valori del Manifesto agile:

"Rispondere al cambiamento più che seguire un piano"

L'approccio Agile è quindi lontano dal tentativo di evitare modifiche al piano prestabilito, come previsto dal project management tradizionale mediante il concetto di "change request". Il cliente può infatti richiedere cambiamenti nei requisiti del sistema a ogni iterazione mentre questo viene realizzato. A ogni Sprint (se utilizziamo Scrum) il sistema evolve incrementalmente portando in produzione tutto ciò che è stato già realizzato; ciò consente al cliente di testare sul campo la validità del prodotto o servizio mediante dei rilasci magari a utenti alfa o beta. In pratica quello che viene seguito è un approccio empirico alla realizzazione del software.

Empirismo

Vediamo la definizione dell'empirismo che possiamo trovare su wikipedia:

"L'empirismo (dal greco ‘empeiria', ‘esperienza') è la corrente filosofica, nata nella seconda metà del Seicento in Inghilterra, secondo cui la conoscenza umana deriva esclusivamente dai sensi o dall'esperienza (…). Secondo gli empiristi, si considera alla base del metodo scientifico l'idea che le nostre teorie dovrebbero essere fondate sull'osservazione del mondo piuttosto che sull'intuito o sulla fede (…). In senso lato, oggi per empirismo si intende un approccio sperimentale alla conoscenza, basato sulla ricerca e su un modo di procedere a posteriori, preferiti alla pura logica deduttiva".

Riporto la definizione che Ken Schwaber, uno dei due creatori assieme a Jeff Sutherland, dà del framework metodologico Scrum per mostrare quanto sia evidente che le metodologie agili si basino fortemente sui principi dell'empirismo oltre che rispondere a molte delle istanze del pensiero lean.

"Scrum (n): Un framework che consente alle persone di risolvere problemi complessi di tipo adattivo e, al tempo stesso, di creare e rilasciare prodotti in modo efficace e creativo dal più alto valore possibile (…). Scrum si basa sulla teoria del controllo empirico dei processi, o empirismo (…). Scrum utilizza un metodo iterativo e un approccio incrementale per ottimizzare la prevedibilità e il controllo del rischio. I pilastri che sostengono ogni implementazione del controllo empirico di processo sono: trasparenza, ispezione e adattamento."

Proprio i tre pilastri di Scrum (trasparenza, ispezione e adattamento) possono offrire le fondamenta concettuali su cui edificare i contratti agili.

Trasparenza

Trasparenza nel rapporto tra le due parti che cooperano sulla base della fiducia reciproca al fine di realizzare prodotti dal più alto valore possibile.

Ispezione

Ispezione e controllo continui di quanto viene realizzato (vedere le Review a termine Sprint o la fase di measure del ciclo della metodologia Lean Startup ideata da Eric Reis) consentono di stilare dei contratti suddivisi in fasi, lunghe addirittura solo un'iterazione.

Adattamento

Un adattamento sulla base di quanto appreso e rilevato durante la fase d'ispezione (vedere la fase di learn di Lean Startup) offre l'opportunità di avere contratti parzialmente aperti e modificabili.

 

 

Figura 5 - Una schematizzazione del ciclo della metodologia di Lean Startup.

 

La mappa non è il territorio

La citazione di Alfred Korzibsky "la mappa non è il territorio" ci ricorda che qualsiasi tentativo di comprendere la realtà potrà al più realizzarne un modello che possiamo validare solo con l'esperienza diretta. Quindi resta un'illusione pensare di definire a priori tutte le caratteristiche (ossia funzionalità e requisiti non funzionali) di un sistema e sulla base di queste redigere dei contratti.

Se quanto detto finora ancora non vi convince, v'invito a esplorare assieme un paio di modelli sistemici, allo scopo di mostrare che i contratti tradizionali sono adatti solo a certi contesti o domini; e, sfortunatamente per noi, tipicamente non si tratta quelli di pertinenza dell'IT:

  • il Cynefin framework
  • la Matrice di Stacey

Cynefin framework

Il Cynefin framework fornisce una tipologia di quattro domini che ci guida verso il tipo di spiegazioni o di soluzioni che potrebbero essere applicate in ciascuno di essi. Ne abbiamo già parlato sulle pagina di MokaByte [2] e vediamo qui di seguito in cosa ci può venire incontro per la nostra trattazione sui contratti.

 

 

Figura 6 - Una schematizzazione del modello interpretativo Cynefin.

 

I contratti così come le metodologie tradizionali ben si sposano con le caratteristiche del primo e del secondo quadrante del framework: semplice e complicato. Dato che in questi domini possono essere applicate "best practice" e "good practice" è legittimo stilare contratti che si basino su di esse e quindi definire in modo predittivo le caratteristiche di un artefatto (prodotto o servizio) nel momento in cui questo appartiene alla sfera dei sistemi semplici o complicati. Un pericolo è dato dalla possibilità di effettuare una transizione improvvisa e non prevista dal primo al quarto dominio portando inaspettatamente la sicurezza data dall'esecuzione e controllo, che seguono un piano preordinato e inflessibile, alla catastrofe e al fallimento.

Software come attività complessa

Lo sviluppo software, essendo però un'attività complessa, appartiene al terzo dominio del Cynefin framework: ecco una ragione in più per cui non ha senso applicare la tipologia dei contratti tradizionali. Il contratto che dovremmo utilizzare dovrà avere caratteristiche che ben si sposino con il dominio della complessità in cui è possibile conoscere un sistema solo a posteriori identificando aree in cui si sono verificati meccanismi di causa ed effetto, che di solito non possono essere ripetuti.

Sulla base di quanto si è appreso in maniera interattiva (con feedback quanto più possibile frequenti) è possibile far evolvere in maniera creativa un prodotto fino ad ottenerne uno a più alto valore possibile. Perciò i contratti non possono essere rigidi, ma devono consentire questo meccanismo di esplorazione che porterà entrambe le parti ad avere successo.

Matrice di Stacey

Un'altro modello utile per muoversi tra i concetti inerenti il campo della complessità è la matrice di Stacey  ("The Stacey Matrix") ideata da Ralph D. Stacey, che verrà descritta in maniera dettagliata in un prossimo articolo sulla complessità e le metodologie Lean Agili.

 

 

Figura 7 - La matrice di Stacey.

 

Questo modello può offrirci una guida, fornendo un metodo per selezionare le azioni manageriali più appropriate, in un sistema adattativo complesso, basate sul grado di certezza (sulle ordinate) e il livello d'accordo (sulle ascisse) che si ha sul tema in questione.

Una matrice per i contratti

Focalizzando il discorso sul tema dei contratti, è indiscutibile che uno strumento come la matrice di Stacey, mediante le sue cinque zone di accordo e certezza, può rappresentare un notevole ausilio atto a guidare la scelta di una tipologia contrattuale in base all'area della matrice specifica al contesto nel quale ci si viene a trovare. Quindi non ha più senso utilizzare un'unica forma contrattuale per tutti i contesti, che porterebbe ovviamente a notevoli problematiche, ma diventa sensato avvalersi di una serie di forme contrattuali che meglio si adattano alle caratteristiche dei domini del Cynefin framework e alle aree della matrice di Stacey.

Dalla descrizione delle cinque aree presenti nella matrice di Stacey emerge come i contratti tradizionali, "fix time, fix price" e talvolta anche "fix scope" (a tempo e costi fissi e talvolta anche con ambito dei requisiti fissato), ben si adattino alla prima area o al più possono essere utilizzati, con qualche rischio o una serie di attività di negoziato a supporto, anche nella seconda area.

Le varie forme di contratto agile invece possono essere utilizzate per gestire in maniera creativa l'innovazione e l'incertezza della zona della complessità fino a spingersi verso la quinta area ("the edge of chaos") e ben si adattano anche alla seconda e terza. In queste due ultime aree, per ragioni diverse, un processo iterativo e incrementale è il più adatto:

  • nell'area del processo decisionale "politico" l'approccio iterativo può aiutare a raggiungere una visione condivisa.
  • nell'area del processo decisionale "basato sul giudizio", i metodi lean e agili sono estremamente utili a esplorare lo spazio delle possibili soluzioni fino a raggiungere il risultato condiviso.

Contratti agili

Possiamo concludere questa primo articolo della serie affermando che i metodi agili forniscono una grande flessibilità e consentono requisiti e priorità variabili. Quindi le diverse forme contrattuali, che andremo a descrivere più avanti, dovranno favorire, e non contrastare con la loro rigidità (esistente nei contratti tradizionali), l'esplorazione di nuove possibilità, la creatività e l'innovazione.

D'altra parte quest'adattabilità e flessibilità dell'ambito di progetto o prodotto possono creare dei problemi quando si definiscono i criteri di accettazione per contratti e lavori in outsourcing. A questa tematica dedicheremo dello spazio di discussione in merito ad alcuni contratti agili che possono essere utilizzati in maniera efficace.

È importante comprendere che la problematica contrattuale esiste sin dalla nascita delle metodologie agili, per cui alcune tipologie di contratti sono state concepite sin dall'inizio e su questo importante tema sono stati spesi sforzi notevoli.

Nel 1994, la prima edizione del Manuale di DSDM (una delle prime metodologie agili) presentava il modello del "triangolo invertito". La concezione fortemente non tradizionale dell'interazione tra le quattro variabili fondamentali della gestione dei progetti offerta dal modello ha aperto le porte a molte delle metodologie agili che sarebbero nate successivamente e ha offerto nuove prospettive per quanto riguarda i contratti utilizzabili in ambito Lean Agile.

La figura 8 mostra le due versioni del triangolo che lega funzionalità, costo e tempo.

 

 

Figura 8 - Il triangolo che lega funzionalità, costo e tempo può essere interpretato in maniera tradizionale o con un approccio agile.

 

Vediamo in cosa consistono le differenze.

Tradizionale

L'insieme delle funzionalità è fissato, mentre tempo e costo sono calcolati partendo dall'ambito. In questa versione del modello è difficile garantire la qualità, specialmente nel momento in cui tutte e tre le variabili sono fissate formando quello che viene chiamato lo Iron Triangle (triangolo di ferro). I contratti tradizionali redatti su queste basi sono decisamente rischiosi e spesso hanno concorso al fallimento di progetti e prodotti.

Agile

In questo caso vengono fissati tempi e risorse (costi, effort…) mentre viene concessa la variazione dell'ambito delle funzionalità diminuendo i rischi per il fornitore e al contempo offrendo al cliente di poter variare i requisiti del proprio prodotto allo scopo di ottenerne il massimo valore. In questo caso la qualità può essere massimizzata in quanto non viene costretta dal rigido rapporto tra le altre tre variabili. Diverse forme contrattuali possono essere concepite su tali basi per soddisfare una moltitudine di contesti diversi.

Conclusioni

Con questa breve dissertazione sul triangolo Agile si conclude il primo articolo della serie. La discussione proseguirà nella seconda parte per illustrare le dieci principali "tematiche" che vanno tenute in considerazione nella realizzazione di contratti agili; infine, nel terzo articolo verranno esplicitamente descritte varie forme contrattuali agili.

Riferimenti

[1] Manifesto per lo Sviluppo Agile di Software

http://agilemanifesto.org/iso/it/

 

[2] Giovanni Puliti, "Management dal semplice al complesso - II parte: Classificare i sistemi con Cynefin framework", MokaByte 184, maggio 2013

http://www2.mokabyte.it/cms/article.run?articleId=Y9O-LBZ-XBG-OCZ_7f000001_26089272_a0f7ef9c

 

 

 

Condividi

Pubblicato nel numero
192 febbraio 2014
Lauerato in Astrofisica, lavora nel settore IT da oltre 25 anni, sia come ricercatore senior che come manager.
Articoli nella stessa serie
Ti potrebbe interessare anche