120521 agile contracts 2.1

Agile Contracts
Madrid, March 2012

2012 – more presentations at slideshare.net/proyectalis

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


World Agile Conference


My
Pleasure!


Enough for a start…


Agile


Values

Principles

Processes Practices

Roles Artifacts

Tools


Agile101
Estimate

Ouch!
R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

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


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


The Contract Concept


Earn as much as you can

 XXXX= -10 -10 -10 -10
 XXXY= +10 +10 +10 -30
 XXYY= +20 +20 -20 -20
 XYYY= +30 -10 -10 -10
 YYYY= +10 +10 +10 +10


Stupidity Quadrant
(Carlo Maria Cipolla)


Western vision
of contracts


The problem…


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


Eastern Vision of Contracts:


Software Contracts


Contract

Time Scope

?
Resources

Good, beautiful, cheap… Choose any two of them!


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.


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?
 …


Complexity
Requirements

Technology


Uncertainty


Uncertainty cone


Accuracy vs. Effort
Accuracy

Estimation effort


Accuracy vs. Effort
Accuracy
100% accurate

50-70% accuracy

ENOUGH

Estimation effort


Traditional Approach vs. Agile

Fix: Scope Cost Time

Value
Oriented

Plan
Oriented

Estimate: Cost Time Scope


Project Buffers
60% buffer used

80% project done

Buffer

Min T Max T


Hofstadter’s law: "It always takes
longer than you expect, even when
you take into account Hofstadter's
Law.”


Uncertainty, complexity…

Change is the only constant.
Uncertainty is the only certainty

Changes in
software
projects


Berard’s Law - “Walking on water and
developing software from a specification are
easy if both are frozen..”


Humprey’s Law: User
won’t know what he wants
until the system is live


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


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


Medinilla’s law for Software
Contracts: 40 thousand lines of
code won’t fit into a 20 page
contract


Iterative vs. Incremental

@ Jeff Patton - www.agileproductdesign.com/

Walking Skeleton


Agile Contract


Agile Contract

?

Agile Contract

MVP /
MMFS


Agile Contract

MVP /
MMFS

Scope
Creep


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


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’

Contract Models


Model 1: Fixed everything


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…


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


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?


a)

b)
Options:

c)


Win-Win?


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


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


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


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


1.4: Inception

-- Uncertainty


1.4: Inception

…..


Histogram


Histogram
Average


Histograma
Average

95% SLA
80% SLA


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


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)


free
But I don’t want to
abort the contract!


free
 Change for free: any feature can be exchanged for another of
similar size (exchange instead of change)


free
 Rule: I cut the pie, you choose the
piece you want


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


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.


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”


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


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


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!


2.2: Iterative and Incremental time
and materials (“True Agile”)
 Functional deliveries at the
end of every sprint, cost per
sprint
 Excellent engineering that
can incorporate changes in
the future
 Possibility of ending the
project after any sprint, with
or without cost (incentive for
© Jeff Patton supplier)
 Some risk sharing


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


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


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)


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


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


Modelo 3:
Agile
Compromise


“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


 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


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


“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

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


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


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)


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.


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.


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$


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


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$


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)


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)


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


Summary


Still no silver bullets…


“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


“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


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


Challenges


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”)


Team
 Communication with client
 Iterative and Incremental development
 Accept uncertainty – embrace change!
 Reject non-approved changes (in some kind of contracts)


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”


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…)


Jeff Sutherland, Agile 2008


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…


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…)


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??)


Be Agile, My
Friend…


Debate and
questions

angel.medinilla@proyectalis.com

Thank you!


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


120521 agile contracts 2.1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 120521 agile contracts 2.1

Similar to 120521 agile contracts 2.1 (20)

More from Proyectalis / Improvement21

More from Proyectalis / Improvement21 (20)

Recently uploaded

Recently uploaded (20)

120521 agile contracts 2.1