120521 agile contracts 2.1

  • 1,745 views
Uploaded on

Agile Contracts one-day seminar

Agile Contracts one-day seminar

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,745
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
54
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 @angewww.slideshare.net/proyectaliswww.linkedin.com/in/angelmwww.presionblogosferica.comwww.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
  • 10. World Agile Conference 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 PrinciplesProcesses Practices Roles Artifacts Tools 2012 – more presentations at slideshare.net/proyectalis
  • 21. Agile101Estimate 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 teamEstimate - 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 teamEstimate - 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
  • 24. The Contract Concept 2012 – more presentations at slideshare.net/proyectalis
  • 25. 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 2012 – more presentations at slideshare.net/proyectalis
  • 26. 2012 – more presentations at slideshare.net/proyectalis
  • 27. Stupidity Quadrant(Carlo Maria Cipolla) 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. LitigationHe said… She said…The system is not working The client changed his mindWe can’t use it Users are not trainedYou should have warned us You did not listen to usThe system is buggy Data was corrputYou gave us no advice You took bad decissionsUnder-qualified developers Inadequate interlocutorsBad development process Non-involved customerThe system did not work in field Client did not adapt his processesYou 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 ? ResourcesGood, beautiful, cheap… Choose any two of them! 2012 – more presentations at slideshare.net/proyectalis
  • 37. From a REAL CONTRACTCommunitites  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
  • 40. ComplexityRequirements Technology 2012 – more presentations at slideshare.net/proyectalis
  • 41. 2012 – more presentations at slideshare.net/proyectalis
  • 42. 2012 – more presentations at slideshare.net/proyectalis
  • 43. 2012 – more presentations at slideshare.net/proyectalis
  • 44. Uncertainty 2012 – more presentations at slideshare.net/proyectalis
  • 45. Uncertainty cone 2012 – more presentations at slideshare.net/proyectalis
  • 46. Accuracy vs. EffortAccuracy Estimation effort 2012 – more presentations at slideshare.net/proyectalis
  • 47. Accuracy vs. EffortAccuracy 100% accurate 50-70% accuracy ENOUGH Estimation effort 2012 – more presentations at slideshare.net/proyectalis
  • 48. Traditional Approach vs. AgileFix: Scope Cost Time Value Oriented Plan OrientedEstimate: 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 takeslonger than you expect, even whenyou take into account HofstadtersLaw.” 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 projects2012 – more presentations at slideshare.net/proyectalis
  • 53. Berard’s Law - “Walking on water anddeveloping software from a specification areeasy if both are frozen..” 2012 – more presentations at slideshare.net/proyectalis
  • 54. Humprey’s Law: Userwon’t know what he wants until the system is live 2012 – more presentations at slideshare.net/proyectalis
  • 55. Humprey’s Law: Userwon’t know what he wants until the system is live 2012 – more presentations at slideshare.net/proyectalis
  • 56. Humprey’s Law: Userwon’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 understoodWegner’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 understoodWegner’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 SoftwareContracts: 40 thousand lines ofcode won’t fit into a 20 pagecontract 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 developmentoutcomes is to start early, learn constantly, commit late, anddeliver fast. This may seem to cut against the grain of conventionalproject management practice, which is supposed to give moremanaged, predictable results. But predictability is a funny thing; youcannot build with confidence on a shifting foundation. The problemwith conventional approaches is that they assume thefoundation 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. HistogramAverage 2012 – more presentations at slideshare.net/proyectalis
  • 97. HistogramaAverage 95% SLA80% 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 ControlBoth parties recognize that there will be change to scope throughout this project. Change will be accommodatedprovided 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 yetaccepted and Stories accepted.Any changes, which impact user stories, which have already been delivered, will usually require additionalrework 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 otherwiseaffecting the scope (in terms of total Story Points to be delivered) of the “Project” must be approved following theChange Request Process set forth below.4.7 Change Request ProcessThe standard change control for this project will be as follows. The only decision makers required here are theExigen 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 becompleted 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 implementedstory then any rework required will be included in the story point cost of the new story.The “Client” ProductOwner must attend this sessionThe “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 thechange. Finally, the “Client” Product Owner should prioritize the new story (if added) against the Product Backloghttp://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
  • 112. 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 2012 – more presentations at slideshare.net/proyectalis
  • 113. Agile Contracting/Proposal- n our agile approach, budget and time select the requirements that can Ibe delivered. Our clients have the ultimate project control and may declaretheir satisfaction with the application as a whole at any time in thedevelopment process. Our clients can decide that although there is budgetremaining, the delivery team has met their objectives and can call theproject 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 areguaranteed to have live, working functionality that is of the highest value tothem 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: AgileCompromise 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 (deductedFINAL 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
  • 146. Jeff Sutherland, Agile 2008 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-timecontracts. Implement Scrum, double your performance, acceptthe contract at industry-average price and get rich by keepingthe differenceJeff 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 questionsangel.medinilla@proyectalis.com 2012 – more presentations at slideshare.net/proyectalis
  • 152. Thank you!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.com2012 – more presentations at slideshare.net/proyectalis