This presentation, that was presented at the Italian Agile Day 2012 conference by Fabio Armani. It deals with Lean Agile Contracts in terms of related principles, topics, typologies and models.

1. iad2012
#iad12 | @fabioarmani

3. Chi sono
Fabio Armani
• CEO di OpenWare
• f.armani@open-ware.org
• @fabioarmani

5. Una domanda che mi viene posta
frequentemente è la seguente:
“E’ possibile stilare contratti in ambito
Agile?”

6. Collaborazione col cliente più
che negoziazione dei contratti

8. #iad12|
@fabioarmani

10. “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

13. Il dilemma del prigioniero
#iad12|
@fabioarmani

14. Il dilemma del prigioniero
vantaggio
Fornitore
svantaggio
svantaggio
vantaggio
Cliente

15. Il dilemma del prigioniero
vantaggio
Fornitore
lose-­‐
win
svantaggio
svantaggio
vantaggio
Cliente

16. Il dilemma del prigioniero
vantaggio
Fornitore
lose-­‐
win
svantaggio
svantaggio
vantaggio
Cliente

17. Il dilemma del prigioniero
vantaggio
Fornitore
lose-­‐
win
svantaggio
svantaggio
vantaggio
Cliente

18. Il dilemma del prigioniero
vantaggio
Fornitore
lose-­‐
win
svantaggio
svantaggio
vantaggio
Cliente

19. Saggezza convenzionale

20. Saggezza convenzionale
• Le aziende inevitabilmente sono attente ai
propri interessi
• I contratti sono necessari per limitare
comportamenti opportunistici

21. Approccio agile

22. 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

23. T5
Agreement
#iad12|
@fabioarmani

24. Predi>vo
#iad12|
@fabioarmani

25. Empirico
#iad12|
@fabioarmani

26. “la mappa non è il territorio“
Alfred
Korzibsky

27. Cynefin

28. Lean Agile Contracts

29. #iad12|
@fabioarmani

30. 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

31. 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

33. Functionality
Traditional
Time Cost

34. Resources Functionality Time
fixed
Agile
Traditional
vary
Time Functionality Cost

35. Lean Agile Contracts

36. 1

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

40. 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

41. 2

44. 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

45. 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

46. #iad12|
@fabioarmani

47. 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

48. Elevator
Pitch
It’s a technique for distilling the product value proposition
#iad12|
@fabioarmani

49. 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

50. 3

52. Gestione del cambiamento
• Legata alla filosofia che è alla base delle
metodologie agili stesse

53. 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à

54. 4

56. 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”

58. 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

59. 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

60. Value
capture
vs
delivery
CumulaFve
Value
Captured
Features
delivered

61. Value
capture
vs
delivery
CumulaFve
Value
Captured
50%
Usual
AssumpFon
Features
delivered
50%

62. Value
capture
vs
delivery
Actual
DistribuFon
90%
CumulaFve
Value
Captured
50%
Usual
AssumpFon
Features
delivered
50%

63. 5

65. Approvazione
• Non ci devono esser ambiguità circa:
– Doneness
– Acceptance
– Correction
• Particolare cura nella negoziazione di questi
aspetti favorendo la collaborazione

66. 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

67. 6

69. 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

70. 7

72. 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

73. 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

74. 8

76. 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

77. 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

78. 9

80. 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 …

81. Tempistiche di pagamento
5K per iteration (100%)
3x5K = 15K
18x5K = 90K
Payment
3 Time
18

82. Tempistiche di pagamento
4K per iteration (80%)
3x4K = 12K
18x4K = 72K
Payment
72k +18k = 90K
3 Time
18

83. Tempistiche di pagamento
4K per iteration (80%)
6x4k + 6k = 30k
12x4k + 6k + 6k = 60k
Payment
72k +12k + 6k = 90k
6 Time
12 18

84. 10

85. 10
Pagamento e fatturazione,
compresi eventuali clausole di
bonus e penali

87. 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

88. Time & Materials
• Estremamente valido per progetti agili:
semplice e diretto
• Raccomandato
• Può applicarsi sia a:
– Fixed scope
– Variable scope

89. 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

90. 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

91. 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”

92. 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

93. 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

94. Shared pain/gain : esempio
project estimate average velocity original person-day payment if €500 per
(140 people, 2 weeks iteration) estimate person per day
100.000 points 4000 points 35.000 €17.500.000

95. 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

96. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
35.000 €17.500.000 0 0 €500

97. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000 0 0 €500

98. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000 0 0 €500
40.000 €18.250.000 14% +4% €456

99. 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

103. Sydney Opera House
• Iniziato come progetto a prezzo fisso e data
fissa
• Sfortunatamente non era assolutamente un
progetto standard
• Come risultato …

104. 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

105. 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

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

108. 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

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

110. Output
Fixed Scope
Fixed Scope
Time

111. Output
Fixed Time
Fixed Time
Time

113. Time & Materials
$$$
profit
Effort

114. 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

115. 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!

116. Time & Materials
$$$
profit
Effort

117. Time & Materials
$$$
with Fixed Scope and Cost Ceiling
Work
stops
when
all
requirements
have
been
met
profit
Effort

118. Time & Materials
$$$
with Variable Scope and Cost Ceiling
Work
stops
latest
at
Point
of
Maximum
revenues
profit
Effort

119. Lean Agile Contracts

120. Modelli di contratto

122. Fixed Price / Fixed Scope
$$$
revenue
Revenue
is
constants
regardless
effort
applied
or
delivery
date
Effort

123. 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ì).

124. 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ì).

125. 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

126. 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

127. 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

128. 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

130. 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

131. 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

132. 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

133. FP/FS : perché no
• Scope definito troppo presto (per
proteggere il fornitore)
• Scope troppo esteso (per proteggere il
cliente)

139. Variable-price variable-scope
progressive contracts

140. 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

141. 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

142. 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)

143. 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

145. Phased Development
$$$
Project
delivers
funcFonality
≈quarterly
Budget
&
PrioriFes
adjusted
quarterly
as
well
profit
Effort

146. Phased Dev : struttura
• Vengono finanziati dei rilasci trimestrali e
approvati fondi supplementari dopo ogni
release di successo

147. 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

148. Phased Dev : rischi
• Per il cliente il rischio è limitato al massimo
ad un trimestre dei costi di sviluppo

149. Cash
flow
–
release
singola

150. Cash
flow
–
2
release

151. Cash
flow
–
staged

152. 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

154. Fixed Profit
$$$
profit
Effort

155. Fixed Profit
$$$
AMer
target
compleFon
date,
Supplier
works
at
cost
profit
Effort

156. 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

157. 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

158. 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

159. 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

160. 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

161. Fixed Profit : esempio
target cost target profit target actual adjustement actual actual
customer supplier cost customer supplier
payment payment 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

162. 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

163. 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

164. 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

166. Jeff Sutherland

167. Money for nothing
$$$
Business
value
achieved,
so
works
stops
EsFmate
to
do
“everything”
“Missing
profit”
profit
Effort

168. 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

169. 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

171. Business
Value
Change for Free
Time

172. Change for Free
Want this new one!
Business
Value
Time

173. Change for Free
Want this new one!
Business
Value
Drop this one
Time

175. Business
Value
Money for Nothing
ROI cut-off
Stop here
Time

176. Business
Value
Money for Nothing
Don’t do these
two
ROI cut-off
Stop here
Time

177. Moore
difficult
!
Grande
Mago
-­‐
h:p://www.alessandropoli?.it/site/

178. Business
Value
Money for Nothing
Time

179. Business
Value
Money for Nothing
ROI cut-off
Stop here
Time

180. Business
Value
Money for Nothing
Don’t do these
three
ROI cut-off
Stop here
Time

181. Business
Value
Money for Nothing
Supplier
gets 20% Customer
gets 80%
ROI cut-off
Users avoid code bloat
Project are always
and unnecessary
done early! Time
features

182. Fixed Resources, Fixed Date
80% of Business Value
Cost
3 Time
20

183. Lean Agile Contracts

184. I contratti che promuovono o
obbligano un ciclo di sviluppo
sequenziale aumentano i rischi di
progetto!

185. Suggerimenti
• Money for Nothing & Change for Free
• Progessive
• Multi-phase variable model
• Adattamento e condivisione di pain/gain e
rischi
– Target cost
– Profit sharing

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

187. Ricordiamo cosa dice il Manifesto
Agile: la cooperazione con il cliente è
più importante del contratto

188. Quindi, qualunque cosa si faccia, è
fondamentale tenere una relazione
positiva con il cliente!

189. What
are
Agile
approaches?

190. Fabio Armani
CEO OpenWare
f.armani@open-ware.org
@fabioarmani