Lean Agile Contracts - iad 2012

iad2012 #iad12 | @fabioarmani

Fabio Armani •  CEO di OpenWare •  [email protected] •  @fabioarmani

Chi sono

Una domanda che mi viene posta frequentemente è la seguente:

“E’ possibile stilare contratti in ambito Agile?”

Collaborazione col cliente più che negoziazione dei contratti

#iad12| @fabioarmani

“Nella lunga storia del genere umano (e delle specie animali, anche) coloro che hanno imparato a collaborare e

improvvisare più efficacemente hanno prevalso.“

Charles Darwin

Il dilemma del prigioniero


Il dilemma del prigioniero vantaggio

svantaggio

vantaggio svantaggio

Cliente

Fornito

re

Il dilemma del prigioniero

lose-‐win

vantaggio

svantaggio

vantaggio svantaggio

Cliente

Fornito

re

Saggezza convenzionale

Saggezza convenzionale

•  Le aziende inevitabilmente sono attente ai propri interessi

•  I contratti sono necessari per limitare comportamenti opportunistici

Approccio agile

Approccio agile

•  Si suppone che l’altra parte agirà in buona fede

•  Lasciare che sia la relazione a limitare l'opportunismo

•  Utilizzare il contratto per introdurre incentivi

T5 Agreement


Predi>vo


Empirico


“la mappa non è il territorio“

Alfred Korzibsky

Cynefin

Lean Agile Contracts

Contratti agili

•  I metodi agili forniscono una grande flessibilità e consentono requisiti e priorità variabili

•  Questa adattabilità e flessibilità dello scope possono creare problemi quando si definiscono i criteri di accettazione per contratti e lavori in outsourcing

Contratti agili

•  Questi problemi esistono sin dalla nascita delle metodologie agili

•  Su questo importante tema sono stati spesi sforzi notevoli

•  Nel 1994, la prima edizione del Manuale di DSDM presentava il modello del triangolo invertito

Functionality

Time Cost

Traditional

Functionality

Time Cost

Traditional

Functionality

Resources Time

Agile

fixed

vary

Ciclo di rilascio

•  Al termine di ogni iterazione time-boxed, viene consegnato incrementalmente un sistema deployabile con funzionalità utilizzabili

Ciclo di rilascio

•  Aspetti nuovi per i legali – Doneness and deployability : il rilascio ad ogni

iterazione è done, sviluppato, testato … ovvero in teoria consegnabile

– Durata : minore, generalmente due settimane – Time-boxing : tempo fisso ed ambito variabile

Ambito del progetto

•  Nei contratti agili lo scope non viene definito in maniera esatta e non modificabile

•  Nei diversi contratti esistono possibili variazioni nel grado di specifica dell’ambito e della sua variabilità

•  Queste variazioni sono in genere collegate ai differenti schemi di pagamento

Ambito del progetto

•  Contratti Target-cost –  Scope e dettagli vengono identificati quanto

meglio possibile all’inizio del progetto, allo scopo di calcolare il target cost iniziale

– Consentono meccanismi di modifica dello scope

•  Contratti Progessivi –  In cui lo scope non viene definito oltre l’orizzonte

di una singola iterazione

Vision di progetto

•  Definire una chiara Vision di prodotto •  Utilizzare la tecnica dell’Elevator Pitch in

modo collaborativo (partecipano anche i legali)

Moore, “Crosing the Chasm”

•  Inserire il modello di contratto

Elevator Pitch It’s a technique for distilling the product value proposition


Modello di contratto

•  Esempio: – questo è un contratto di tipo “target-cost” –  La base è un prezzo di delivery dell’ordine di €

XXXX –  Il fornitore rilascerà e verrà pagato su base

incrementale al termine di ogni iterazione di due settimane

Gestione del cambiamento

•  Legata alla filosofia che è alla base delle metodologie agili stesse

Gestione del cambiamento

•  Gestione delle priorità nel Backlog •  Pianificazione adattativa ed iterativa •  Non viene utilizzato un pesante (tradizionale)

processo di change management o di change request

•  E’ fondamentale che i legali comprendano questo punto – Non vengano inseriti termini contrattualistici che

violerebbero l’essenza dell’agilità

Fine progetto

•  Legata al meccanismo di controllo dei cambiamenti

•  In ambito agile il cambiamento può essere così radicale da portare all’interruzione del contratto

“fermando ogni attività al termine di una determinata iterazione”

Fine progetto

•  Un’interruzione precoce dovrebbe essere vista come un evento positivo e desiderabile – Non comporta necessariamente un fallimento – Vuol dire che i risultati sono stati ottenuti prima

•  Consente al cliente di interrompere il contratto, senza penali, al termine di qualsiasi iterazione

•  Variazioni nelle clausole di terminazione proteggono il fornitore

Fine progetto

•  Queste clausole possono essere particolarmente difficili in ogni contratto

•  Fattori di mitigazione in agile: – Al termine di ogni iterazione il cliente ha un

sistema funzionante – Entrambe le parti hanno sempre una chiara e

trasparente vista dello stato dei deliverable

•  E’ fondamentale che i legali comprendano questi concetti

Value capture vs delivery

Features delivered

CumulaFve Value

Captured


Usual AssumpFon

50%

50%

Features delivered

CumulaFve Value

Captured


Usual AssumpFon

Actual DistribuFon

50%

50%

90%

Features delivered

CumulaFve Value

Captured

Approvazione

•  Non ci devono esser ambiguità circa: – Doneness – Acceptance – Correction

•  Particolare cura nella negoziazione di questi aspetti favorendo la collaborazione

Approvazione

•  Approvazione semplificata grazie al delivery iterativo allo sviluppo incrementale del prodotto

•  Automazione degli acceptance test riduce l’effort manuale nella validazione

•  L’accettazione finale è la composizione di una serie di fasi precedenti

Limiti di responsabilità

•  Queste clausole rappresentano probabilmente l’aspetto di negoziazione più difficile

•  Vanno in ogni caso inserite nel contratto •  In agile il processo iterativo ed incrementale

limita i pericoli di una scoperta di gravi anomalie del sistema “big bang”

•  Le conseguenze negative vengono scoperte prima

Garanzia

•  Similmente alle responsabilità, anche questi aspetti vengono mitigati da un approccio agile

•  Ogni accettazione graduale ne ha mitigato il rischio

•  Utilizzando Accetance test automatici si ha un ulteriore diminuzione del rischio

Garanzia

•  Esplicitare l’aspetto incrementale nel contratto

•  Le garanzia devono essere legate ai rilasci incrementali ed iterativi

•  Può ovviamente esistere una garanzia generale sul prodotto finale

Documentazione

•  Evitare quanto più possibile uno “statement of work” o “quality plan” – ovvero una lista dettagliata e fissa di

“deliverable” e di come avvenga l’accettazione di tali artefatti

Documentazione

•  Perché? – Genera attività inutili e sprechi piuttosto che la

focalizzazione sulla produzione di “working software”

– Vi è una falsa presunzione di sapere quali siano gli artifact realmente utili

– Troppe energie spese in negoziazione e conformità al “quality plan” piuttosto che cooperazione nella creazione di software utile

–  Falsa linearizzazione di un processo non lineare

Tempistiche di pagamento

•  Il pagamento avviene al termine di ogni iterazione

•  Dipende in parte dal modello di contratto •  Nei casi più semplici viene pagato il 100%

del prezzo d’iterazione pattuito •  In casi più complessi possono essere utilizzati

altri meccanismi …


Time

Paym

ent

3 18

3x5K = 15K

18x5K = 90K

5K per iteration (100%)


Time

Paym

ent

3 18

3x4K = 12K

18x4K = 72K


72k +18k = 90K


Time

Paym

ent

6 18 12

6x4k + 6k = 30k

12x4k + 6k + 6k = 60k


72k +12k + 6k = 90k

10 Pagamento e fatturazione, compresi eventuali clausole di

bonus e penali

Pagamento

•  Time & materials •  Fixed price per iteration (per unit of time) •  Fixed price per unit of work (UoW) •  Hybrid shared pain/gain •  Fixed price per project and target-cost

pricing

Time & Materials

•  Estremamente valido per progetti agili: semplice e diretto

•  Raccomandato •  Può applicarsi sia a: –  Fixed scope – Variable scope

Time & Materials

•  Variazioni limitano l’esposizione ai pericoli per il cliente e bilanciano pene/guadagni

•  Esempi di variazioni: –  Capped (“non eccedere la soglia”) T&M per iterazione –  Capped T&M per progetto e/o rilascio –  Capped T&M per iterazione con aggiustamenti e possibili

incentivi per il fornitore

Fixed Price per iteration

•  Virtù data da semplicità e predicibilità •  Viene utilizzato in agile outsourcing •  Vi sono due tipologie:

1.  Requisiti definiti e concordati all’inizio dell’iterazione

2.  Altamente flessibile o senza requisiti predefiniti

Fixed Price per UoW

•  In agile una UoW è rappresentata dal settimo principio:

“il software funzionante è la reale misura del progresso”

•  Quindi una UoW è legata a “running, tested software feature”

Fixed Price per UoW

•  Possono essere utilizzati vari sistemi di stima delle UoW: – Price per story point – Price per function point – Price per feature point

•  Questo modello è congruente con i temi agile e lean del – Delivery-oriented – Value-oriented

Shared pain/gain

•  Esistono numerosi schemi di pagamento ibrido

•  Uno degli schemi è quello proposto da Robert Martin – Discounted fixed price per unit of work, plus

discounted T&M

Shared pain/gain : esempio

project estimate average velocity

(140 people, 2 weeks iteration)

original person-day

estimate

payment if €500 per

person per day

100.000 points 4000 points 35.000 €17.500.000


•  Viene offerto un costo giornaliero ridotto, più un complementare costo per UoW

•  Esempio: –  Supponendo un costo di €500 al giorno –  Il fornitore richiede un prezzo scontato a persona di €150

+ un price per point di €125,50


actual person-days actual customer

payment

Change in

estimate-to-actual

effort

Change in

estimate-to-actual

payment

effective person-

day rate

35.000 €17.500.000

0 0 €500



payment

Change in

estimate-to-actual

effort

Change in

estimate-to-actual

payment

effective person-

day rate

30.000 €16.750.000 -14% -4% €558

35.000 €17.500.000

0 0 €500



payment

Change in

estimate-to-actual

effort

Change in

estimate-to-actual

payment

effective person-

day rate

30.000 €16.750.000 -14% -4% €558

35.000 €17.500.000

0 0 €500

40.000 €18.250.000

14% +4% €456

Shared pain/gain

•  Se l’effort reale è uguale a quello stimato, il cliente pagherà con un semplice schema di tipo T&M

•  Nel caso il cui tale effort vari, il pagamento da parte del cliente varierà meno

•  Come nel meccanismo del target-cost sia fornitore sia cliente condividono i rischi

Sydney Opera House

•  Iniziato come progetto a prezzo fisso e data fissa

•  Sfortunatamente non era assolutamente un progetto standard

•  Come risultato …

Sydney Opera House

•  Ci sono voluti 13 anni e 102 milioni di dollari australiani per costruirla al posto dei 3 anni e 7 milioni di dollari stimati –  330 % del tempo –  1350 % dei costi

Sviluppo soMware

•  Lo sviluppo del software consiste quasi sempre (in larga misura) nella creazione di qualcosa di nuovo, che nessuno ha realizzato in precedenza

•  Pertanto i contratti a prezzo-fisso e data-fissa per lo sviluppo del software sono noti per essere imprecisi ed erronei

Soluzioni agili

•  Una soluzione agile per situazioni basate sul prezzo fisso sarebbe quella di svincolare l'angolo di pianificazione del triangolo tempo-costo-qualità

Soluzioni agili

•  Ciò in genere implica che si istituisca sia una forma di contratto ‘time & materials’ sia un finanziamento a fasi (gated)

•  Nel caso di contratti a tempo e materiali il cliente paga ogni mese per il mese di sviluppo, oppure iterazione dopo iterazione

Soluzioni agili

•  Di solito il cliente ha il diritto di sospendere la collaborazione dopo ogni iterazione, possibilmente con un dato premio

Fixed Scope O

utpu

t

Time

Fixed Scope

Fixed Time

Fixed Time

Time

Out

put

Time & Materials

profit

$$$

Effort

T&M : variazioni di scope

•  Lo scope non è fissato a priori •  Prima o poi, il cliente non vorrà continuare a

pagare, dunque il progetto volgerà al termine

T&M : rischi

•  100% a carico del cliente •  Il fornitore ha pochi incentivi a contenere i

costi •  Lo sforzo necessario per garantire che solo il

lavoro e le spese legittimi vengano fatturati può essere notevole

•  Questo sforzo di tracciamento rappresenta uno spreco!

Time & Materials

profit

$$$

Effort

Time & Materials

profit

Effort

$$$ with Fixed Scope and Cost Ceiling

Work stops when all requirements have been met

Time & Materials

profit

Effort

$$$

Work stops latest at Point of Maximum revenues

with Variable Scope and Cost Ceiling

Modelli di contratto

Fixed Price / Fixed Scope

revenue

$$$

Revenue is constants regardless effort applied or delivery date

Effort

FP/FS : struttura

•  Concordare gli elementi da fornire •  Consegnarli •  Inviare fattura •  I clienti amano i progetti a prezzo fisso,

perché dà loro sicurezza (almeno così credono)(o almeno la pensano così).

FP/FS : variazioni di scope

•  Nulla: è evidente già nel nome del tipo di contratto : fixed scope

•  Il processo di change request ha lo scopo di limitare le modifiche dell’ambito (scope)

•  Questo processo è costoso, e le modifiche di solito non sono prevenibili

FP/FS : variazioni di scope

•  Dal momento che il cliente per definizione richiede aumenti dello scope, terminare un progetto può essere piuttosto difficile

•  D’altra parte il fornitore vuole che il cliente sia soddisfatto, quindi in genere cede

•  I requisiti di un contratto di questo tipo devono essere definiti in modo molto stringente e rigoroso

FP/FS : rischi

•  Il rischio è molto sbilanciato a sfavore del fornitore

•  Se le stime sono sbagliate, il progetto perderà soldi

•  Porta ad un lose-lose situation •  Introduzione di alto debito tecnico •  Il cliente paga più del dovuto e spesso non

ottiene ciò di cui ha realmente bisogno

FP/FS : rischi

•  Se vengono anche introdotte clausole di “fixed time” il rischio di progetto aumenta

•  Il cliente viene penalizzato anche a lungo termine a causa dell’introduzione di debito tecnico – Aumento dei costi di manutenzione – Aumento dei costi per le evoluzioni

FP/FS : contromisure

•  Definire i requisiti mediante user story e MMF

•  Gestire le priorità degli elementi del backlog –  Scambiare requisiti esistenti con altri di uguale effort –  Cambiare l’ordine di esecuzione dei requisiti fissi –  Migliorare la “definition of done” ad ogni iterazione

•  Aumentare i margini del prezzo di contratto per riflettere i rischi inerenti allo sviluppo FPFS

FP/FS : contromisure

•  Proposte di Ken Schwaber: –  Il cliente può richiedere altre release in ogni

momento, pagate a T&M –  Il cliente può terminare prima se soddisfatto,

pagando al fornitore il 20% del valore rimanente non fatturato

FP/FS : waterfall o agile?

“La cosa peggiore che possiate fare con un progetto FPFS è rendere le cose ancora

peggiori adottando un approccio tradizionale di tipo sequenziale”

Craig Larman & Bas Vodde

FP/FS : perché no

•  Scope definito troppo presto (per proteggere il fornitore)

•  Scope troppo esteso (per proteggere il cliente)

Variable-price variable-scope progressive contracts

Progressive : struttura

•  Implicano uno scope totalmente flessibile che viene definito in modo adattativo ad ogni iterazione successiva

•  Ottimi candidati per lo sviluppo agile •  Rappresentano un framework per gli accordi

contrattuali che definiscono le relazioni tra le parti e gli schemi di pagamento ma non lo scope

Progressive : struttura

•  Rappresentano un modello comune per relazioni a lungo termini tra clienti e fornitori agile

•  Un pattern frequente: 1.  Utilizzo di primi contratti che sono variazioni di

FPFS 2.  Successivamente si ha uno spostamento verso

contratti progressivi con T&M e/o capped T&M per iterazione

Progressive : variazioni

•  Capped-price, variable scope •  Capped-price, partial-fixed scope : viene

definito solo un piccolo set di requisiti, lasciando spazio ad apprendimento ed adattabilità

•  Fixed-price, variable scope : è possibile fissare le date finale (optional scope contract)

Progressive : rischio

•  Mitigare i rischi con modelli flessibili di contratto

•  Modello multi-fase : un grande progetto viene suddiviso in una serie di progetti più piccoli –  Le forme contrattuali possono variare da una fase

all’altra

Phased Development

Effort

$$$

profit

Project delivers funcFonality ≈quarterly Budget & PrioriFes adjusted quarterly as well

Phased Dev : struttura

•  Vengono finanziati dei rilasci trimestrali e approvati fondi supplementari dopo ogni release di successo

Phased Dev : variazioni di scope

•  Non esplicitamente definito dal modello •  Le release sono effettivamente ‘time boxed’ •  La consapevolezza che ci potrà essere

un’altra versione il trimestre prossimo rende più facile accettare il rinvio di una funzione per ottenere il time-box

Phased Dev : rischi

•  Per il cliente il rischio è limitato al massimo ad un trimestre dei costi di sviluppo

Cash flow – release singola

Cash flow – 2 release

Cash flow – staged

Phased Dev : relazione

•  Cooperativa •  Sia il cliente sia il fornitore hanno un

incentivo affinché ogni release abbia successo, in modo che verranno approvati ulteriori finanziamenti

Fixed Profit

profit

Effort

$$$

Fixed Profit

profit

Effort

$$$

AMer target compleFon date, Supplier works at cost

Target Cost : struttura

•  Basati su obiettivi di business ad alto livello •  Il costo target include tutti i cambiamenti •  Il target è una responsabilità congiunta delle

due parti •  Obbiettivi e costo target vengono

chiaramente comunicati a tutti le persone coinvolte che collaborano allo scopo di raggiungere il goal finale

Target Cost : struttura

•  I contratti target cost allineano le motivazioni di entrambe le parti

•  Vengono utilizzati da Toyota con i loro fornitori, riflettendo il pilastro del rispetto per le persone del Lean Thinking per stabilire relazioni di lunga durata con i fornitori, basate su fiducia e mutua collaborazione/supporto

Fixed Profit : struttura

•  Qualsiasi bilancio del progetto è costituito da costi effettivi e profitto

•  Le parti concordano su un determinato profitto in anticipo (ad esempio 150.000 €)

•  Indipendentemente da quando il progetto viene completato, il contraente riceve i costi sostenuti più il profitto concordato

Fixed Profit : variazioni di scope

•  Lo scope è fisso e viene calcolato durante la fase uno 1.  Calcolo del del target cost (no-wishful thinking)

mediante scrupolosa due diligence 2.  Esplicitazione dei costi da parte del fornitore in

modo che il cliente possa trasparentemente vedere tutti i dettagli che hanno portato al calcolo del target cost

Fixed Profit : attuazione

•  La fase due prevede l’utilizzo di metodologie agili (es: Scrum)

•  Tracciamento accurato dei costi •  Condivisione dei costi •  La chiave di successo è legata alle formule di

condivisione di pain/gain per effettuare aggiustamenti relativi alla differenza tra costi reali e target

Fixed Profit : esempio

target cost target profit target

customer

payment

actual

supplier cost

adjustement actual

customer

payment

actual

supplier

profit

€1.000.000 €150.000 €1.150.000 €1.100.000 + €60.000 €1.210.000

€110.000

€1.000.000 €150.000

€1.150.000 €900.000 - €60.000 €1.090.000

€190.000

Fixed Profit : rischi

•  Il rischio è condiviso •  Se il progetto finisce prima, il cliente paga

meno, ma il fornitore ha ancora il suo profitto

•  Se il progetto supera il budget, il cliente paga di più, ma il fornitore non guadagna il profitto aggiuntivo

Fixed Profit : rischi

•  Dopo la data di consegna stabilita, il fornitore non potrà più fatturare altro profitto, si limiterà a coprire i propri costi

•  Il rischio è condiviso mediante le formule di aggiustamento

•  Inoltre le parti possono (non è garantito) promuovere modi per ridurre gli sprechi durante il progetto

Fixed Profit : relazione

•  Cooperativa •  Entrambi hanno un chiaro incentivo a finire

presto •  Se il lavoro termina prima, sia il cliente, sia lo

sviluppatore ne traggono beneficio •  Il cliente per risparmiare denaro e il fornitore

per ottenere un margine di profitto più elevato

Jeff Sutherland

Money for nothing

profit

Effort

$$$

EsFmate to do “everything”

“Missing profit”

Business value achieved, so works stops

MfN / CfF : variazioni di scope

•  Lo scope può essere modificato •  Feature (o storie) progettate, ma non

realizzate, possono essere sostituite con altre storie della stessa dimensione

•  Invece la realizzazione di feature aggiuntive ha un costo extra

MfN / CfF : rischi

•  Il rischio è condiviso •  Entrambe le parti hanno interesse a

completare il progetto quanto prima •  Il cliente avrà costi inferiori, il fornitore avrà

un margine più elevato

Change for Free

Time

Busin

ess V

alue

Change for Free

Time

Busin

ess V

alue

Want this new one!

Change for Free

Time

Busin

ess V

alue

Drop this one

Want this new one!

Money for Nothing

Time

Busin

ess V

alue

ROI cut-off

Stop here

Money for Nothing

Time

Busin

ess V

alue

ROI cut-off

Don’t do these two

Stop here

Grande Mago -‐ h:p://www.alessandropoli?.it/site/

Moore difficult !

Money for Nothing

Time

Busin

ess V

alue

Money for Nothing

Time

Busin

ess V

alue

ROI cut-off

Stop here

Money for Nothing

Time

Busin

ess V

alue

ROI cut-off

Stop here

Don’t do these three

Money for Nothing

Time

Busin

ess V

alue

ROI cut-off

Customer gets 80%

Supplier gets 20%

Project are always done early!

Users avoid code bloat and unnecessary

features

Fixed Resources, Fixed Date

Time

Cost 80% of Business Value

3 20

I contratti che promuovono o obbligano un ciclo di sviluppo

sequenziale aumentano i rischi di progetto!

Suggerimenti

•  Money for Nothing & Change for Free •  Progessive •  Multi-phase variable model •  Adattamento e condivisione di pain/gain e

rischi – Target cost – Profit sharing

La forma del contratto pone importanti basi per un progetto di successo

Ricordiamo cosa dice il Manifesto Agile: la cooperazione con il cliente è

più importante del contratto

Quindi, qualunque cosa si faccia, è fondamentale tenere una relazione

positiva con il cliente!

What are Agile approaches?

Fabio Armani CEO OpenWare [email protected] @fabioarmani

Lean Agile Contracts - iad 2012

Technology

Transcript of Lean Agile Contracts - iad 2012