The document discusses various contract models for agile software development projects. It begins by describing a "fixed everything" model where scope, schedule and budget are fixed upfront. This model is not recommended as it breaks agile principles and puts all risk on the supplier. Alternative models discussed include a collaborative approach with more flexibility, a progressive "fixed everything" model divided into stages, and a "competitive sprint" model. Overall the document advocates for contract models that embrace uncertainty and allow for adaptation based on ongoing learning.
Falcon Invoice Discounting: The best investment platform in india for investors
120521 agile contracts 2.1
1. Agile Contracts
Madrid, March 2012
2012 – more presentations at slideshare.net/proyectalis
2. 2012 – more presentations at slideshare.net/proyectalis
3. ngel M edinilla!
Á @proye
c talis.co
m
edinilla
angel.m l_m
@ange
www.slideshare.net/proyectalis
www.linkedin.com/in/angelm
www.presionblogosferica.com
www.proyectalis.com/en/blog
2012 – more presentations at slideshare.net/proyectalis
4. 2012 – more presentations at slideshare.net/proyectalis
5. 2012 – more presentations at slideshare.net/proyectalis
6. 2012 – more presentations at slideshare.net/proyectalis
7. 2012 – more presentations at slideshare.net/proyectalis
8. 2012 – more presentations at slideshare.net/proyectalis
9. 2012 – more presentations at slideshare.net/proyectalis
11. 2012 – more presentations at slideshare.net/proyectalis
12. 2012 – more presentations at slideshare.net/proyectalis
13. My
Pleasure!
2012 – more presentations at slideshare.net/proyectalis
14. 2012 – more presentations at slideshare.net/proyectalis
15. 2012 – more presentations at slideshare.net/proyectalis
16. Enough for a start…
2012 – more presentations at slideshare.net/proyectalis
17. 2012 – more presentations at slideshare.net/proyectalis
18. 2012 – more presentations at slideshare.net/proyectalis
19. Agile
2012 – more presentations at slideshare.net/proyectalis
20. Values
Principles
Processes Practices
Roles Artifacts
Tools
2012 – more presentations at slideshare.net/proyectalis
21. Agile101
Estimate
Ouch!
R1.0 ¿R2.0?
Estimate BV
Replan R1.0 ¿R2.0? t
2012 – more presentations at slideshare.net/proyectalis
22. Agile101
- Self-organized, motivated team
Estimate - Sustainable pace
- Daily collaboration with customer and
business people
- Face to face communication
- Seeking technical excellence
- Constant reflection on how to improve
Ouch! and remove waste
R1.0 ¿R2.0?
Estimate BV
Replan R1.0 ¿R2.0? t
2012 – more presentations at slideshare.net/proyectalis
23. Agile101
- Self-organized, motivated team
Estimate - Sustainable pace
- Daily collaboration with customer
and business people
- Face to face communication
- Seeking technical excellence
- Constant reflection on how to improve
Ouch! and remove waste
R1.0 ¿R2.0?
Estimate BV
Replan R1.0 ¿R2.0? t
2012 – more presentations at slideshare.net/proyectalis
28. Western vision
of contracts
2012 – more presentations at slideshare.net/proyectalis
29. The problem…
2012 – more presentations at slideshare.net/proyectalis
30. Litigation
He said… She said…
The system is not working The client changed his mind
We can’t use it Users are not trained
You should have warned us You did not listen to us
The system is buggy Data was corrput
You gave us no advice You took bad decissions
Under-qualified developers Inadequate interlocutors
Bad development process Non-involved customer
The system did not work in field Client did not adapt his processes
You were late Changes were added
2012 – more presentations at slideshare.net/proyectalis
31. Eastern Vision of Contracts:
2012 – more presentations at slideshare.net/proyectalis
32. 2012 – more presentations at slideshare.net/proyectalis
33. 2012 – more presentations at slideshare.net/proyectalis
34. 2012 – more presentations at slideshare.net/proyectalis
35. Software Contracts
2012 – more presentations at slideshare.net/proyectalis
36. Contract
Time Scope
?
Resources
Good, beautiful, cheap… Choose any two of them!
2012 – more presentations at slideshare.net/proyectalis
37. From a REAL CONTRACT
Communitites
The communities section is a new space on the Web where
collaborative work environments will be set for the different
communities defined by the organization.
Content management roles must be defined for each community
so they can manage, update and energize the Web space
Each of these spaces must provide tools that make all the usual
social network practices possible, including collaborative
tools, knowledge management, etc. In this sense, the
communities section can include blogs, forums, document
management systems, task management systems, etc.
It will be possible to create as many communities as needed, all
of them similar except for the customization of look and feel
through colors and logos.
2012 – more presentations at slideshare.net/proyectalis
38. Doubts!
Communities
Are these spaces shared? Who uses them?
Which roles exists other than manager?
What’s the meaning of “managing” or “updating”? Does it include, for instance,
software updates and data backup?
Which are those “usual practices on social networks”? What do you understand for
“knowledge management”? And “document management”? What does “etcetera”
include?
“Can” include means that they are optional?
Is there any restriction on the size or kind of documents to be managed? Is everyone
allowed to upload documents?
Is there any kind of search engine to be included in the system?
What’s the actual functionality of the forum? Includes avatars? Icons? HTML
embedding? RSS feeding? Can you create sub-forums?
What’s a task manager? Does it include some kind of calendar? Alarms? Filtering
tasks? Search? Project Management?
Are communities created automatically or by hand? Are the logos and colours the
same in all community views? How are communities indexed or organized? How are
they linked or referred from the rest of the web?
…
2012 – more presentations at slideshare.net/proyectalis
39. 2012 – more presentations at slideshare.net/proyectalis
47. Accuracy vs. Effort
Accuracy
100% accurate
50-70% accuracy
ENOUGH
Estimation effort
2012 – more presentations at slideshare.net/proyectalis
48. Traditional Approach vs. Agile
Fix: Scope Cost Time
Value
Oriented
Plan
Oriented
Estimate: Cost Time Scope
2012 – more presentations at slideshare.net/proyectalis
49. Project Buffers
60% buffer used
80% project done
Buffer
Min T Max T
2012 – more presentations at slideshare.net/proyectalis
50. Hofstadter’s law: "It always takes
longer than you expect, even when
you take into account Hofstadter's
Law.”
2012 – more presentations at slideshare.net/proyectalis
51. Uncertainty, complexity…
Change is the only constant.
Uncertainty is the only certainty
2012 – more presentations at slideshare.net/proyectalis
52. Changes in
software
projects
2012 – more presentations at slideshare.net/proyectalis
53. Berard’s Law - “Walking on water and
developing software from a specification are
easy if both are frozen..”
2012 – more presentations at slideshare.net/proyectalis
54. Humprey’s Law: User
won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
55. Humprey’s Law: User
won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
56. Humprey’s Law: User
won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
57. Ziv’s law: requirements will never be completely understood
2012 – more presentations at slideshare.net/proyectalis
58. Ziv’s law: requirements will never be completely understood
Wegner’s lemma: an interactive system can never be fully specified nor
can it ever be fully tested
2012 – more presentations at slideshare.net/proyectalis
59. Ziv’s law: requirements will never be completely understood
Wegner’s lemma: an interactive system can never be fully specified nor
can it ever be fully tested
Langdon’s lemma: software evolves more rapidly as it approaches
chaotic regions
2012 – more presentations at slideshare.net/proyectalis
60. Medinilla’s law for Software
Contracts: 40 thousand lines of
code won’t fit into a 20 page
contract
2012 – more presentations at slideshare.net/proyectalis
61. 2012 – more presentations at slideshare.net/proyectalis
62. Iterative vs. Incremental
@ Jeff Patton - www.agileproductdesign.com/
2012 – more presentations at slideshare.net/proyectalis
63. Walking Skeleton
2012 – more presentations at slideshare.net/proyectalis
64. Agile Contract
2012 – more presentations at slideshare.net/proyectalis
65. Agile Contract
2012 – more presentations at slideshare.net/proyectalis
66. Agile Contract
2012 – more presentations at slideshare.net/proyectalis
67. Agile Contract
?
2012 – more presentations at slideshare.net/proyectalis
68. Agile Contract
2012 – more presentations at slideshare.net/proyectalis
69. Agile Contract
MVP /
MMFS
2012 – more presentations at slideshare.net/proyectalis
70. Agile Contract
MVP /
MMFS
2012 – more presentations at slideshare.net/proyectalis
71. Agile Contract
MVP /
MMFS
Scope
Creep
2012 – more presentations at slideshare.net/proyectalis
72. Agile Contract
MVP /
MMFS
Scope
Creep
2012 – more presentations at slideshare.net/proyectalis
73. Agile Contract
MVP /
MMFS
Scope
Creep
2012 – more presentations at slideshare.net/proyectalis
74. Iterative and Incremental Contract
Reduces risk: there’s ALWAYS some working software you can
use
More freedom to client: he decides when to release something
or stop the project
Provides frequent feedback from client and users
Provides real information on project progress
Delay is less critical
2012 – more presentations at slideshare.net/proyectalis
75. So…
“The best way to achieve predictable software development
outcomes is to start early, learn constantly, commit late, and
deliver fast. This may seem to cut against the grain of conventional
project management practice, which is supposed to give more
managed, predictable results. But predictability is a funny thing; you
cannot build with confidence on a shifting foundation. The problem
with conventional approaches is that they assume the
foundation is firm; they have little tolerance for change.”
Mary Poppendieck – ‘The predictability Paradox’
2012 – more presentations at slideshare.net/proyectalis
76. Contract Models
2012 – more presentations at slideshare.net/proyectalis
77. Model 1: Fixed everything
2012 – more presentations at slideshare.net/proyectalis
78. Fixed everyting
Breaks every discussed principle
All risk for supplier
No incentives for client to accept the
product early
Assumes you can perfectly define the
system to be built
A lot of time and resources spent on
RFP / RFQ
RFP / RFQ seldom includes
tolerances, buffers or measure of
uncertainty – estimates are given by
client in form of delivery dates
Favours the “optimistic” (desperate?)
supplier – creates the game of…
2012 – more presentations at slideshare.net/proyectalis
79. 2012 – more presentations at slideshare.net/proyectalis
80. Fixed everyting
Does not provide the lower costs
(competent suppliers will include
buffers in their quotations)
A lot of excess functionality (YAGNI)
will be added to the requirements “just
in case”, as contracts seldom include a
change / add mechanism
If everything goes right, client will pay
more for software
If everything goes wrong, supplier will
drop quality in order to meet deadlines
2012 – more presentations at slideshare.net/proyectalis
81. What the eye can’t see…
Nobody is in this business to lose
money (at least, not for much time)
“Big” firms accept these contracts all
the time
Ergo big companies are earning
money with these contracts
How?
2012 – more presentations at slideshare.net/proyectalis
82. a)
b)
Options:
c)
2012 – more presentations at slideshare.net/proyectalis
83. a)
b)
Options:
c)
2012 – more presentations at slideshare.net/proyectalis
84. a)
b)
Options:
c)
2012 – more presentations at slideshare.net/proyectalis
85. Win-Win?
2012 – more presentations at slideshare.net/proyectalis
86. Variant 1.1 : fixed everyting +
collaboration
“Good faith”: original scope subject
to negotiation
Will work on most important items
first, and if we can make them all we
can drop items or extend the
contract
Problem: too fuzzy
Problem: the frog and the scorpion
2012 – more presentations at slideshare.net/proyectalis
87. 1.2: progressive fixed everything
(“UCR3”, “VC”)
Unified Commitment – Rule of 3rds,
Venture Capital
Divide project into 3 or 4 parts
Execute the first as Fixed Everything to
produce an MVP / MMFS (no additional
or low priority features)
Obtains real hands-on information about
the system and its usage
Lets the client redefine the next phases
depending on the results
If the supplier under-delivers, you can
cancel the project and cut your loses
soon
2012 – more presentations at slideshare.net/proyectalis
88. 1.3: Competitive Sprint
( a“Lean Approach”)
Toyota’s concurrent approach
UCR3, but we hire several
suppliers at the same time for
phase 1
We select one of the suppliers
depending on their deliveries, but
as we are paying all of them, we
can incorporate everything we learn
from the other suppliers to the final
contractor’s solution
2012 – more presentations at slideshare.net/proyectalis
89. 1.4: Inception
A.K.A. “Sprint zero” or consulting contract
Contracting supplier for a week or two to build the product backlog
Then, supplier can give better estimates of how much and when
Can include a first sprint of development or two: supplier will also be
able to demonstrate velocity and delivery
2012 – more presentations at slideshare.net/proyectalis
90. 1.4: Inception
-- Uncertainty
2012 – more presentations at slideshare.net/proyectalis
91. 1.4: Inception
…..
2012 – more presentations at slideshare.net/proyectalis
92. 1.4: Inception
…..
2012 – more presentations at slideshare.net/proyectalis
93. 1.4: Inception
…..
2012 – more presentations at slideshare.net/proyectalis
94. 1.4: Inception
…..
2012 – more presentations at slideshare.net/proyectalis
95. Histogram
2012 – more presentations at slideshare.net/proyectalis
96. Histogram
Average
2012 – more presentations at slideshare.net/proyectalis
97. Histograma
Average
95% SLA
80% SLA
2012 – more presentations at slideshare.net/proyectalis
98. Different kinds of projects
T-Shirt sizes and different
histograms:
XS – 3 days
S – 40 days
M – 90 days
L – 150 days
XL – 220 days
2012 – more presentations at slideshare.net/proyectalis
99. 1.5: Money for nothing, change for
free
Xebia + Sutherland
Money for nothing: client can call the project “done” any time,
paying the supplier 20% of the cancelled scope (client saves 80% if
he finds current functionality enough, supplier wins 20% for doing
nothing)
2012 – more presentations at slideshare.net/proyectalis
100. 1.5: Money for nothing, change for
free
But I don’t want to
abort the contract!
2012 – more presentations at slideshare.net/proyectalis
101. 1.5: Money for nothing, change for
free
But I don’t want to
abort the contract!
2012 – more presentations at slideshare.net/proyectalis
102. 1.5: Money for nothing, change for
free
Change for free: any feature can be exchanged for another of
similar size (exchange instead of change)
2012 – more presentations at slideshare.net/proyectalis
103. 1.5: Money for nothing, change for
free
Rule: I cut the pie, you choose the
piece you want
2012 – more presentations at slideshare.net/proyectalis
104. 4.6 Change Control
Both parties recognize that there will be change to scope throughout this project. Change will be accommodated
provided that the total Story Points do not exceed the total amount stated in Section 5.
No changes shall be made to Stories being delivered in the current Sprint, Stories already delivered but not yet
accepted and Stories accepted.
Any changes, which impact user stories, which have already been delivered, will usually require additional
rework and will be considered as new Stories.
Changes to the requirements defined by the Stories and Story Tests listed in the Annex A of this SOW or otherwise
affecting the scope (in terms of total Story Points to be delivered) of the “Project” must be approved following the
Change Request Process set forth below.
4.7 Change Request Process
The standard change control for this project will be as follows. The only decision makers required here are the
Exigen Services SCRUM Master and “Client” Project Manager.
Once a change is accepted the following steps will occur:
For each change that Exigen Services and “Client” agree to define as a new story the definition of the story is to be
completed by the “Client” Product Owner.
Analysis of the change by the Exigen Services will take place during the next planned Sprint Planning session.
This analysis will define the story point cost of the new story. If the change applies to an already implemented
story then any rework required will be included in the story point cost of the new story.The “Client” Product
Owner must attend this session
The “Client” Product Owner must make the decision concerning the change. There are two possible options:
Accept the change into the Product Backlog and decide which story (or stories) are to be removed or Reject the
change.
Finally, the “Client” Product Owner should prioritize the new story (if added) against the Product Backlog
http://coactivate.org/projects/agile-contracts/sample-fixed-price-agile-contract
2012 – more presentations at slideshare.net/proyectalis
105. 1.5: Money for nothing, change for
free
Sutherland, Agile 2008 – “Agile
Contracts”:
1/3 of organizations admit to be “too
disfunctional” to use this approach:
Not able to build a proper product
backlog
Not able to prioritize features
according to their business value
Not able to trust development
teams
Supplier still suffer the cost of delay if
initial estimates are wrong or features
are not well described / understood.
2012 – more presentations at slideshare.net/proyectalis
106. 2012 – more presentations at slideshare.net/proyectalis
107. 2012 – more presentations at slideshare.net/proyectalis
108. Time and materials
“From a client’s perspective, this is like a contractor saying he’s not sure how
much of a house can be built for $100,000, but they’ll use five people for
three months, build one room at a time and see how far he can get.”
Bruce Eckfeldt and Rex Madden, “Selling Agile: target cost contracts”
2012 – more presentations at slideshare.net/proyectalis
109. Time and materials
Wrongly considered “the Agile
contract” (“pendulum law” - all risk is
for client now)
Could be cheaper to hire developers
Does not give incentives to the
supplier to deliver and be efficient –
be careful to include SLA’s!!
Invested time does not necessarily
mean value delivered
It can go on for ever
You need to trust your supplier a lot
2012 – more presentations at slideshare.net/proyectalis
110. 2.1: hour stock/ maintennance
contract
M
T&M with a ratio (i.e., “between 180 and
240 hours every month) during a given
time (10 months) until you reach a total
(2000). O
It’s very important to set SLA’s (you
don’t want your client to ask for 2.000
hours the last month of the contract) S
Setting value SLA’s can be important
(i.e., minimum and average velocity, C
measured as functional product
delivered per every 100 hours)
Can include prioritization and wanted W
functionality (MOSCoW) based on min.
V / max. V
2012 – more presentations at slideshare.net/proyectalis
111. 2.1 Hour stock (+scope goal)
Min. V Sure we can do that
We will probably end
somewhere over here
Max. V
You gotta’ be kidding me!
2012 – more presentations at slideshare.net/proyectalis
113. Agile Contracting/Proposal
- n our agile approach, budget and time select the requirements that can
I
be delivered. Our clients have the ultimate project control and may declare
their satisfaction with the application as a whole at any time in the
development process. Our clients can decide that although there is budget
remaining, the delivery team has met their objectives and can call the
project complete.
- On the flip side, although the total budget may be expended on a project,
and all backlog items may not have been developed, our clients are
guaranteed to have live, working functionality that is of the highest value to
them due to the constant inspection and adaptation of the project backlog.
Agile
Contrac.ng
-‐
ADP
2008
-‐
Chris
Spagnuolo
and
Rachel
Weston
2012 – more presentations at slideshare.net/proyectalis
114. 2.3: price per Story Point
Incentivizes the delivery of
working software as soon as
possible
Changes are welcome as
long as you pay for them
Problem: may need an
external, neutral party (what’s
a Story Point?)
Problem: it can produce
unwanted software just to
cash in points
2012 – more presentations at slideshare.net/proyectalis
115. 2.4: Points + hours
Robert C. Martin (Uncle Bob)
Fixed scope / variable time
Calculate points and velocity
Calculates the project cost
Reduce the hour cost and put the
rest as point cost
If there’s excess of hours, we can
slightly rise prices
If we do it in less time, we get a
slight bonus (incentive)
2012 – more presentations at slideshare.net/proyectalis
116. 2.4: Points + hours
1000 points, 100 points a week
(10 weeks) with a team of 5
(5x40x10=2000 hours). 40€/h
80.000€ Charge 10€/h and
60€ per point (2000x10+1000x60
= 80.000)
If you take 12 weeks, project cost
will be 1000x60 + 2400x10 =
84.000
If you do it in 8 weeks, 1000x60 +
1600x10 = 76.000
2012 – more presentations at slideshare.net/proyectalis
117. 2.5: IDIQ
Indefinite Delivery / Indefinite Quantity
We want at least 1000 story points
We want deliveries to be between 4
weeks and 6 months
We will always give notice with 4
weeks that we want some delivery
It’s essentially T&M, but with some
estimates on demand and terms
2012 – more presentations at slideshare.net/proyectalis
118. Modelo 3:
Agile
Compromise
2012 – more presentations at slideshare.net/proyectalis
119. “Agile Compromise”
Many names and approaches (“target cost”, “not to exceed/fixed
fee”,”shared profit”, “Lean Approach”…)
As always, what’s important is principles, not the specific set of tools
2012 – more presentations at slideshare.net/proyectalis
120. “Agile Compromise”
Progressive (iterative and
incremental)
Shared risk, shared profits,
incentives to win-win behavior
Assumes positive intention and
client-supplier collaboration (Agile)
Limits the chance of opportunistic
behavior
2012 – more presentations at slideshare.net/proyectalis
121. “Agile Compromise”
I don’t trust the supplier I trust the supplier
Fixed Everything Shared Risk Time & Materials
Scope is fixed at high level
There’s a target cost / time and certain margin / buffer for
uncertainty
A mechanism is needed so supplier nor client abuse that
margin
2012 – more presentations at slideshare.net/proyectalis
122. “Agile compromise”
We share profits We share costs
Min
Target Max
“Target time” for a prioritized backlog, aggresive minimun
and maximum time (“double worst case scenario”)
Under the minimum, supplier wins. Over the maximum,
supplier loses…
BUT… in the middle, we share costs or profits 50/50
Incentivizes both client AND supplier to end as soon as
possible
2012 – more presentations at slideshare.net/proyectalis
123. Possible Mechanic:
Define stories with your client
Estimate in points or days = Min t
Add some buffer (10% for known
clients, 30% “hostile” clients) =
Target t
Add your profit = Max t (if you last
more than that, you lose money)
If I last more than Target, I earn less
than expected
If I last less than Target, I earn more
than expected
2012 – more presentations at slideshare.net/proyectalis
124. Possible Mechanic:
Dev Days = 48 Bad estimates: you need 58 development
Plan Days = 6 days = 64 to deliver = +4 over target. We
assume half (2 free days) and client drops de
Min t = 54 days
bottom 2 days of the backlog. Our profit
Buffer 10% = 6 drops from 12 days to 10.
Target t = 60 days
Profit= 20% (12)
Max t = 72 days
2012 – more presentations at slideshare.net/proyectalis
125. Possible mechanic:
Dev Days = 48 Good practice: we manage to build it in 44
Plan Days = 6 days = deliver in 50 days = -10 under
target. We share the whole buffer (6 days / 2
Min t = 54 days
= 3 days) and even earn 4 additional days
Buffer 10% = 6 (under min), so we earn 7 days more than
Target t = 60 days expected and client adds 3 free dyas worth of
Profit= 20% (12) development to the backlog (his half of the
Max t = 72 days buffer)
2012 – more presentations at slideshare.net/proyectalis
126. Possible Mechanic:
Dev Days = 48 Catastrophe: we need +24 days = we
Plan Days = 6 deliver in 78 days =( +12 over target +6
Min t = 54 days over max). The 6 over max are totally
assumed by supplier. The 12 over target are
Buffer 10% = 6
shared, 6 for supplier and 6 are drop from
Target t = 60 days clients’s backlog. Supplier is assuming +12
Profit= 20% (12) days and develops at costs, without any
Max t = 72 days profit.
2012 – more presentations at slideshare.net/proyectalis
127. Another example:
Dev Days = 48
Bad estimates : We need 58 development
Plan Days = 6 days = deliver in 64 = +4 over target. As
Min t = 54 days there is no maximum defined, client and
Buffer 10% = 6 supplier might have agreed that they would
Target t = 60 days share costs, so client removes 2 days and we
Cost/day: 100S$
assume 2 days. Final cost =6.2KS$, profit =
Target cost = 6KS$
Profit(25%) = 1.5K$
1,3KS$. Client loses some features, supplier
Budget= 7.5KS$ loses some profit.
2012 – more presentations at slideshare.net/proyectalis
128. Another example:
Dev Days = 48
Good practice: we only need 44 dev. days =
Plan Days = 6 deliver in 50 = -10 under target. We share
Min t = 54 days buffer. Supplier earns 7 days (4 under min +
Buffer 10% = 6 3 buffer) and client adds 3 free development
Target t = 60 days days. Final cost: 5KS$, profit 2.5KS$ - and
Cost/day: 100S$
client is receiving extra features.
Target cost = 6KS$
Profit(25%) = 1.5K$
Budget= 7.5KS$
2012 – more presentations at slideshare.net/proyectalis
129. Yet another:
Target Scope Client’s buffer Supplier’s buffer
‘Joe’s bucket’ (Thoughtworks): buffer for client and
provider – each manages the part he is more able to
Client buffer is for additional scope
Supplier buffer is for re-estimations and unidentified
tasks
2012 – more presentations at slideshare.net/proyectalis
130. Joe’s bucket:
GLOBAL BUDGET = 6.4KS$
Target Scope Client Buffer Supplier Buffer
Dev Days = 48 10% scope 10%
creep uncertainty
Plan Days = 6
48*0,1 ≈ 5 48*0,1 ≈ 5
Min t = 54 days days days
Min cost = 5.4KS$ Cost= 0,5KS$ Cost=0,5KS$
2012 – more presentations at slideshare.net/proyectalis
131. Joe’s bucket:
0.1KS$ client
(deducted
FINAL PRICE= 6.3KS$ (-0,1KS$) from price)
Target Scope Client buffer Supplier buffer
Dev Days = 48 4 days of 4 days worth of
unpredicted re-estimations
Plan Days = 6 scope added and rework
Cost = 5.4KS$ Cost= 0,4KS$ Cost= 0,4KS$
0.1KS$ supplier
(adds to price as
Profit)
2012 – more presentations at slideshare.net/proyectalis
132. Joe’s Bucket:
0.5KS$ client (deducted)
FINAL PRICE= 5.9KS$ (-0,5KS$)
Alcance objetivo Buffer cliente Buffer Proveedor
Dev Days = 48 No added 8 days of delay
scope or Cost= 0,8KS$
Plan Days = 6 changes
Cost= 5.4KS$ Cost= 0
0.5K$ added to
price as costs
-0.3KS$ payed
by supplier
(loses)
2012 – more presentations at slideshare.net/proyectalis
133. Joe’s Bucket:
FINAL PRICE = 6.4KS$ (-0,0KS$)
Alcance objetivo Buffer cliente Buffer Proveedor
Dev Days = 48 5 days of 0 days of delay
added scope Cost = 0
Plan Days = 6
Cost= 0,5kS$
Cost = 5.4KS$
0.5KS$ extra
profit
2012 – more presentations at slideshare.net/proyectalis
134. Summary
2012 – more presentations at slideshare.net/proyectalis
135. Still no silver bullets…
2012 – more presentations at slideshare.net/proyectalis
136. “Fixed” projects
More risk to supplier – worse on the long
term
Use buffers for some uncertainty
Do progressive development / contracting
“Inception” - collaboration
Have mechanisms deal with and trace
changes
Incentivize the early delivery and
acceptance of the project
2012 – more presentations at slideshare.net/proyectalis
137. “Variable” projects
More risk to client
Limit risks by limiting scope or budget
Periodic and frequent deliveries – define “done, done”
Business value based prioritization
Incentivize deliveries of value
Use SLA’s and target velocity
2012 – more presentations at slideshare.net/proyectalis
138. Agile Approach
Share risks and benefits
Inception – Joint Backlog
Development
High level definition of Scope
Target Scope / Time / Budget
Collaboration
Incentivize deliveries and early
finishing of the project
2012 – more presentations at slideshare.net/proyectalis
139. Challenges
2012 – more presentations at slideshare.net/proyectalis
140. Client Collaboration
Joint Application Development (JAD), daily collaboration
Meetings
High level definition of scope / stories, including acceptance criteria
Accepting deliveries (can block advance!)
Client process can be an obstacle (“gantt charts, task lists and man-
hours”)
2012 – more presentations at slideshare.net/proyectalis
141. Team
Communication with client
Iterative and Incremental development
Accept uncertainty – embrace change!
Reject non-approved changes (in some kind of contracts)
2012 – more presentations at slideshare.net/proyectalis
142. Sales Force
Make the team participate in proposals
Develop Agile proposals
Sell Agile
Be careful with some Agile term (“fail
fast”, “variable scope”, “uncertainty”,
“changes”…)
Don’t sell “Silver Bullets”
2012 – more presentations at slideshare.net/proyectalis
143. To convince…
Try some Sprints
Success stories: burn-downs, metrics,
comments of other clients…
Examples of companies using Agile
(specially industry leaders, clients and
competitors)
Follow the pain: What’s not working right
now? How Agile solves that?
Share some retrospectives with your client
Offer Ágile metrics and tools (dashboards,
access to source repository or continuous
integration servers…)
2012 – more presentations at slideshare.net/proyectalis
144. 2012 – more presentations at slideshare.net/proyectalis
145. 2012 – more presentations at slideshare.net/proyectalis
147. Worst case…
We can’t do it
It sound good in theory, but it is not
realistic
My client won’t allow me
My supplier won’t allow me
My company won’t allow me
My boss
My peers won’t allow me
My mommy won’t allow me…
2012 – more presentations at slideshare.net/proyectalis
148. Worst case…
Use a buffer according to your historical
average uncertainty
Do more generalistic scope documents
Do iterative and incremental development -
Prioritize your project plan according to
business value
Do follow-up meetings every two weeks and
show working software to your client
Watch closely for changes (Money for
nothing / change for free)
Report daily to your clients (excel or simillar)
Gradually introduce other practices (CI,
TDD, retrospectives…)
2012 – more presentations at slideshare.net/proyectalis
149. Last Advice:
Stop complaining about fixed-price, fixed-scope, fixed-time
contracts. Implement Scrum, double your performance, accept
the contract at industry-average price and get rich by keeping
the difference
Jeff Sutherland
(or wasn’t him??)
2012 – more presentations at slideshare.net/proyectalis
150. Be Agile, My
Friend…
2012 – more presentations at slideshare.net/proyectalis
151. Debate and
questions
angel.medinilla@proyectalis.com
2012 – more presentations at slideshare.net/proyectalis
153. http://creativecommons.org/
licenses/by-nc-nd/3.0/
This presentation is based upon
the ideas and work of many
people. And while I’ve tried to
recognize copyrights and give
credit and attribution where
possible, I cannot possibly list
them all, so if you feel like
there’s something that should be
added, changed or removed
from this presentation, please
drop me an e-mail at
angel.medinilla@proyectalis.com
2012 – more presentations at slideshare.net/proyectalis