iad2012 #iad12 | @fabioarmani

Fabio Armani •  CEO di OpenWare •  f.armani@open-ware.org •  @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

#iad12|  @fabioarmani  

Il dilemma del prigioniero  vantaggio  

svantaggio  

vantaggio  svantaggio  

Cliente  

Fornito

re  

Il dilemma del prigioniero  

   

 lose-­‐win  

vantaggio  

svantaggio  

vantaggio  svantaggio  

Cliente  

Fornito

re  

Il dilemma del prigioniero  

   

 lose-­‐win  

vantaggio  

svantaggio  

vantaggio  svantaggio  

Cliente  

Fornito

re  

Il dilemma del prigioniero  

   

 lose-­‐win  

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  

#iad12|  @fabioarmani  

Predi>vo  

#iad12|  @fabioarmani  

Empirico  

#iad12|  @fabioarmani  

“la mappa non è il territorio“

Alfred  Korzibsky  

Cynefin

Lean Agile Contracts

#iad12|  @fabioarmani  

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

Lean Agile Contracts

1

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

2

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

#iad12|  @fabioarmani  

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

#iad12|  @fabioarmani  

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

3

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à

4

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  

Value  capture  vs  delivery  

Usual  AssumpFon  

50%  

50%  

Features  delivered  

CumulaFve  Value  

Captured  

Value  capture  vs  delivery  

Usual  AssumpFon  

Actual  DistribuFon  

50%  

50%  

90%  

Features  delivered  

CumulaFve  Value  

Captured  

5

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

6

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

7

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

8

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

9

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 …

Tempistiche di pagamento

Time  

Paym

ent  

3 18

3x5K = 15K

18x5K = 90K

5K per iteration (100%)

Tempistiche di pagamento

Time  

Paym

ent  

3 18

3x4K = 12K

18x4K = 72K

4K per iteration (80%)

72k +18k = 90K

Tempistiche di pagamento

Time  

Paym

ent  

6 18 12

6x4k + 6k = 30k

12x4k + 6k + 6k = 60k

4K per iteration (80%)

72k +12k + 6k = 90k

10

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

Shared pain/gain : esempio

•  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

Shared pain/gain : esempio

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

Shared pain/gain : esempio

actual person-days actual customer

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

Shared pain/gain : esempio

actual person-days actual customer

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

Lean Agile Contracts

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 : 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

Lean Agile Contracts

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 f.armani@open-ware.org @fabioarmani