120521 agile contracts 2.1
DESCRIPTION
Agile Contracts one-day seminarTRANSCRIPT
2012 – more presentations at slideshare.net/proyectalis
Agile Contracts
Madrid, March 2012
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Ángel [email protected]
@angel_m
www.presionblogosferica.com www.proyectalis.com/en/blog
www.linkedin.com/in/angelm www.slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
World Agile Conference
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
My Pleasure!
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Enough for a start…
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Agile
2012 – more presentations at slideshare.net/proyectalis
Values
Principles
Processes
Roles
Tools
Artifacts
Practices
2012 – more presentations at slideshare.net/proyectalis
Agile101 Estimate
Ouch!
Estimate
Replan R1.0 ¿R2.0?
BV
t
R1.0 ¿R2.0?
2012 – more presentations at slideshare.net/proyectalis
Agile101 Estimate
Ouch!
Estimate
Replan R1.0 ¿R2.0?
BV
t
R1.0 ¿R2.0?
- Self-organized, motivated team - Sustainable pace - Daily collaboration with customer and business people - Face to face communication - Seeking technical excellence - Constant reflection on how to improve and remove waste
2012 – more presentations at slideshare.net/proyectalis
Agile101 Estimate
Ouch!
Estimate
Replan R1.0 ¿R2.0?
BV
t
R1.0 ¿R2.0?
- Self-organized, motivated team - Sustainable pace - Daily collaboration with customer and business people - Face to face communication - Seeking technical excellence - Constant reflection on how to improve and remove waste
2012 – more presentations at slideshare.net/proyectalis
The Contract Concept
2012 – more presentations at slideshare.net/proyectalis
Earn as much as you can
X X X X = -10 -10 -10 -10 X X X Y = +10 +10 +10 -30 X X Y Y = +20 +20 -20 -20 X Y Y Y = +30 -10 -10 -10 Y Y Y Y = +10 +10 +10 +10
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Stupidity Quadrant (Carlo Maria Cipolla)
2012 – more presentations at slideshare.net/proyectalis
Western vision of contracts
2012 – more presentations at slideshare.net/proyectalis
The problem…
2012 – more presentations at slideshare.net/proyectalis
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
Eastern Vision of Contracts:
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Software Contracts
2012 – more presentations at slideshare.net/proyectalis
Contract
Good, beautiful, cheap… Choose any two of them!
?
Time Scope
Resources
2012 – more presentations at slideshare.net/proyectalis
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
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
2012 – more presentations at slideshare.net/proyectalis
Complexity R
equi
rem
ents
Technology
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Uncertainty
2012 – more presentations at slideshare.net/proyectalis
Uncertainty cone
2012 – more presentations at slideshare.net/proyectalis
Accuracy vs. Effort Accuracy
Estimation effort
2012 – more presentations at slideshare.net/proyectalis
ENOUGH
50-70% accuracy
100% accurate
Accuracy vs. Effort Accuracy
Estimation effort
2012 – more presentations at slideshare.net/proyectalis
Traditional Approach vs. Agile
Fix:
Estimate:
Scope
Scope
Cost Time
Cost Time
Plan Oriented
Value Oriented
2012 – more presentations at slideshare.net/proyectalis
Project Buffers
Buffer
80% project done
60% buffer used
Min T Max T
2012 – more presentations at slideshare.net/proyectalis
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
Change is the only constant. Uncertainty is the only certainty
Uncertainty, complexity…
2012 – more presentations at slideshare.net/proyectalis
Changes in software projects
2012 – more presentations at slideshare.net/proyectalis
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
Humprey’s Law: User won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
Humprey’s Law: User won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
Humprey’s Law: User won’t know what he wants
until the system is live
2012 – more presentations at slideshare.net/proyectalis
Ziv’s law: requirements will never be completely understood
2012 – more presentations at slideshare.net/proyectalis
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
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
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
2012 – more presentations at slideshare.net/proyectalis
@ Jeff Patton - www.agileproductdesign.com/
Iterative vs. Incremental
2012 – more presentations at slideshare.net/proyectalis
Walking Skeleton
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
?
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
MVP / MMFS
Agile Contract
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
MVP / MMFS
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
MVP / MMFS
Scope Creep
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
MVP / MMFS
Scope Creep
2012 – more presentations at slideshare.net/proyectalis
Agile Contract
MVP / MMFS
Scope Creep
2012 – more presentations at slideshare.net/proyectalis
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
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
Contract Models
2012 – more presentations at slideshare.net/proyectalis
Model 1: Fixed everything
2012 – more presentations at slideshare.net/proyectalis
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
2012 – more presentations at slideshare.net/proyectalis
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
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
Options:
a)
b)
c)
2012 – more presentations at slideshare.net/proyectalis
Options:
a)
b)
c)
2012 – more presentations at slideshare.net/proyectalis
Options:
a)
b)
c)
2012 – more presentations at slideshare.net/proyectalis
Win-Win?
2012 – more presentations at slideshare.net/proyectalis
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
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
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
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
1.4: Inception
-- Uncertainty
2012 – more presentations at slideshare.net/proyectalis
…..
1.4: Inception
2012 – more presentations at slideshare.net/proyectalis
…..
1.4: Inception
2012 – more presentations at slideshare.net/proyectalis
…..
1.4: Inception
2012 – more presentations at slideshare.net/proyectalis
…..
1.4: Inception
2012 – more presentations at slideshare.net/proyectalis
Histogram
2012 – more presentations at slideshare.net/proyectalis
Histogram Average
2012 – more presentations at slideshare.net/proyectalis
Histograma
95% SLA
80% SLA
Average
2012 – more presentations at slideshare.net/proyectalis
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
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
1.5: Money for nothing, change for free
But I don’t want to abort the contract!
2012 – more presentations at slideshare.net/proyectalis
1.5: Money for nothing, change for free
But I don’t want to abort the contract!
2012 – more presentations at slideshare.net/proyectalis
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
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
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
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
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
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
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
2.1: hour stock/ maintennance contract
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).
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)
Setting value SLA’s can be important (i.e., minimum and average velocity, measured as functional product delivered per every 100 hours)
Can include prioritization and wanted functionality (MOSCoW) based on min. V / max. V
M
O
S
C
W
2012 – more presentations at slideshare.net/proyectalis
2.1 Hour stock (+scope goal)
Min. V
Max. V
Sure we can do that
You gotta’ be kidding me!
We will probably end somewhere over here
2012 – more presentations at slideshare.net/proyectalis
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 supplier)
Some risk sharing © Jeff Patton
2012 – more presentations at slideshare.net/proyectalis
Agile Contrac.ng -‐ ADP 2008 -‐ Chris Spagnuolo and Rachel Weston
Agile Contracting/Proposal
- In our agile approach, budget and time select the requirements that can 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.
2012 – more presentations at slideshare.net/proyectalis
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
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
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
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
Modelo 3: Agile
Compromise
2012 – more presentations at slideshare.net/proyectalis
“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
“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
“Agile Compromise”
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
Fixed Everything Time & Materials Shared Risk
I don’t trust the supplier I trust the supplier
2012 – more presentations at slideshare.net/proyectalis
“Agile compromise”
“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
Min Max Target
We share profits We share costs
2012 – more presentations at slideshare.net/proyectalis
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
Possible Mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days
Bad estimates: you need 58 development days = 64 to deliver = +4 over target. We assume half (2 free days) and client drops de bottom 2 days of the backlog. Our profit drops from 12 days to 10.
2012 – more presentations at slideshare.net/proyectalis
Possible mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days
Good practice: we manage to build it in 44 days = deliver in 50 days = -10 under target. We share the whole buffer (6 days / 2 = 3 days) and even earn 4 additional days (under min), so we earn 7 days more than expected and client adds 3 free dyas worth of development to the backlog (his half of the buffer)
2012 – more presentations at slideshare.net/proyectalis
Possible Mechanic: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Profit= 20% (12) Max t = 72 days
Catastrophe: we need +24 days = we deliver in 78 days =( +12 over target +6 over max). The 6 over max are totally assumed by supplier. The 12 over target are shared, 6 for supplier and 6 are drop from clients’s backlog. Supplier is assuming +12 days and develops at costs, without any profit.
2012 – more presentations at slideshare.net/proyectalis
Another example: Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Cost/day: 100S$ Target cost = 6KS$ Profit(25%) = 1.5K$ Budget= 7.5KS$
Bad estimates : We need 58 development days = deliver in 64 = +4 over target. As there is no maximum defined, client and supplier might have agreed that they would share costs, so client removes 2 days and we assume 2 days. Final cost =6.2KS$, profit = 1,3KS$. Client loses some features, supplier loses some profit.
2012 – more presentations at slideshare.net/proyectalis
Another example: Good practice: we only need 44 dev. days =
deliver in 50 = -10 under target. We share buffer. Supplier earns 7 days (4 under min + 3 buffer) and client adds 3 free development days. Final cost: 5KS$, profit 2.5KS$ - and client is receiving extra features.
Dev Days = 48 Plan Days = 6 Min t = 54 days Buffer 10% = 6 Target t = 60 days Cost/day: 100S$ Target cost = 6KS$ Profit(25%) = 1.5K$ Budget= 7.5KS$
2012 – more presentations at slideshare.net/proyectalis
Yet another:
‘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
Target Scope Client’s buffer Supplier’s buffer
2012 – more presentations at slideshare.net/proyectalis
Joe’s bucket:
Target Scope Client Buffer Supplier Buffer
Dev Days = 48 Plan Days = 6 Min t = 54 days Min cost = 5.4KS$
10% scope creep
48*0,1 ≈ 5 days
Cost= 0,5KS$
10% uncertainty
48*0,1 ≈ 5 days
Cost=0,5KS$
GLOBAL BUDGET = 6.4KS$
2012 – more presentations at slideshare.net/proyectalis
Joe’s bucket:
Target Scope Client buffer Supplier buffer
Dev Days = 48 Plan Days = 6 Cost = 5.4KS$
4 days of unpredicted scope added
Cost= 0,4KS$
4 days worth of re-estimations and rework
Cost= 0,4KS$
0.1KS$ client (deducted from price)
0.1KS$ supplier (adds to price as Profit)
FINAL PRICE= 6.3KS$ (-0,1KS$)
2012 – more presentations at slideshare.net/proyectalis
Joe’s Bucket:
Alcance objetivo Buffer cliente Buffer Proveedor
Dev Days = 48 Plan Days = 6 Cost= 5.4KS$
No added scope or changes
Cost= 0
8 days of delay Cost= 0,8KS$
0.5KS$ client (deducted)
0.5K$ added to price as costs
-0.3KS$ payed by supplier (loses)
FINAL PRICE= 5.9KS$ (-0,5KS$)
2012 – more presentations at slideshare.net/proyectalis
Joe’s Bucket:
Alcance objetivo Buffer cliente Buffer Proveedor
Dev Days = 48 Plan Days = 6 Cost = 5.4KS$
5 days of added scope
Cost= 0,5kS$
0 days of delay Cost = 0
0.5KS$ extra profit
FINAL PRICE = 6.4KS$ (-0,0KS$)
2012 – more presentations at slideshare.net/proyectalis
Summary
2012 – more presentations at slideshare.net/proyectalis
Still no silver bullets…
2012 – more presentations at slideshare.net/proyectalis
“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
“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
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
Challenges
2012 – more presentations at slideshare.net/proyectalis
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
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
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
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
2012 – more presentations at slideshare.net/proyectalis
2012 – more presentations at slideshare.net/proyectalis
Jeff Sutherland, Agile 2008
2012 – more presentations at slideshare.net/proyectalis
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
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
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
Be Agile, My Friend…
2012 – more presentations at slideshare.net/proyectalis
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 [email protected]
http://creativecommons.org/licenses/by-nc-nd/3.0/