Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Contracting in the Second Decade of Agility

712 views

Published on

The Benefits of Agile Software Development are often completely crushed by the weight of Traditional Outsourcing Contracts and Negotiations. Now that we are well into the Second Decade of Agile Methods, it's time to start repeating more of the benefits.

Published in: Leadership & Management
  • Be the first to comment

Agile Contracting in the Second Decade of Agility

  1. 1. AGILE CONTRACTING In the Second Decade of Agility @cgosimon info@lasting-benefits.com
  2. 2. Contracting for Agile Practices Contracting for Agile Benefits
  3. 3. MY BIO • Practitioner, Consultant,Trainer • Occasional CTO • 25+ years in software • 15+ years in “Agile”
  4. 4. MY HISTORY • Independent ISV • Multi-million dollar waterfall projects • Military Simulations • Internal AgileTeams • Outsourced Agile Development • Training / Coaching / Consulting
  5. 5. TRADITIONAL AGILE Product Owner Scrum Master Users Stake holders The Team
  6. 6. OUTSOURCED AGILE Product Owner Users Stake holders Scrum Master The Team Moral Hazard
  7. 7. we’ve increased our Moral Hazard WE CONTRACT BECAUSE
  8. 8. Because we outsourced our Software Development WE INCREASED OUR MORAL HAZARD
  9. 9. Outsource our Software Development? SO WHY DID WE?
  10. 10. EXPERTISE
  11. 11. COST
  12. 12. RISK
  13. 13. THETRADITIONAL ALGORITHM goto Define Solution goto Quote goto Plan goto Execute goto Complain fork Set Objectives
  14. 14. ASSUMPTIONS & OBJECTIVES • Objectives are disjoint from Definition • Expertise in Definition is Separated from Expertise in Execution • Goal of preparation is Completeness & Correctness of the Definition - creating a fungible commodity • Goal of theVendor Selection process is to find the cheapest supplier • The Biggest Risk is not getting everything we asked for
  15. 15. ECONOMIC DRIVERS • Time & money is spent on upfront analysis & contract negotiation • which increases the cost of delay • Plus transaction costs throughout the project • Customers have to get a good deal • Otherwise the Software probably wouldn’t be worth it…
  16. 16. THE FUNDAMENTAL ASSUMPTION Is that we can describe what needs to be done so completely, that it doesn’t matter who does it
  17. 17. ANDTHAT BY DOING SO We’ll get the hoped for outcomes
  18. 18. HOWEVER…
  19. 19. IFYOU DEFINE ONLY ONE WAYTO WIN You’ve just created an infinite number of ways to fail
  20. 20. WHYTHETRADITIONAL APPROACH Is pre-disposed to failure
  21. 21. MAKING SENSE 
 OFTHE WORLD 
 WITHTHE

  22. 22. Simple (The Known) Complicated (The Knowable) OrderedDomains UnorderedDomains Disorder Complex Chaotic Cause & Effect Obvious, predictable & repeatable Cause & Effect Separated by space & time and/or requiring analysis or expertise Cause & Effect Only coherent in retrospect, but not repeatable Cause & Effect not perceivable
  23. 23. What strategies are effective in each domain?
  24. 24. •Legitimate “Best Practice” •Standard Operating Procedures •Analytical / Reductionist •“Current Good Practice(s)” •Pattern management •Solutions emerge through co-evolution with agents Simple ComplicatedComplex Chaotic •Stability-focused intervention •Crisis management
  25. 25. Sense ➠ Categorise ➠ Respond Sense ➠ Analyse ➠ Respond Probe ➠ Sense ➠ Respond Simple ComplicatedComplex Chaotic Act ➠ Sense ➠ Respond
  26. 26. Domain Appropriate Command Structures
  27. 27. Simple ComplicatedComplex Chaotic Strong Central Weak Distributed Strong Central Strong Distributed Weak Central Strong Distributed Weak Central Weak Distributed
  28. 28. TO SUM UP • We can’t describe the solutions to Complex Problems in complete detail ahead of trying to solve them • Our solutions can only co-evolve with the agents • Which means it does matter who builds it • Expertise not cost is the most important in vendor selection (Stop demanding dumb people who don’t care)
  29. 29. The Analytical Reductionist techniques that create explicitly documented Defined Predictive “Waterfall Plans” work fine for simple and complicated problems alike Their “domain inauthenticity” however means that they will begin to fail completely as they encounter problems of increasing complexity
  30. 30. It’s not that we’re failing at Predictive ReductionistTechniques They’re failing us
  31. 31. AGILE FRAMEWORKS Produce better results because they implement “Probe ➠ Sense ➠ Respond” loops.
  32. 32. UNLESS You wrap your Agile in a domain inauthentic wrapper
  33. 33. LIKE A TRADITIONAL CONTRACT
  34. 34. SO WHY DO WE CONTINUETO CONTRACT In such an inauthentic style?
  35. 35. REASON ONE
  36. 36. THE AWESOMETHING ABOUT AGILE Is that it’s so focused on Software
  37. 37. THE BIGGEST WEAKNESS OF AGILE Is that it’s so focused on Software
  38. 38. When you say: “9 out of 10 Bushfires are caused by humans” All I hear is: “There’s a Koala out there who knows how to use matches”
  39. 39. When we said: “We are uncovering better ways of developing software.” All they heard was: “I’m glad you admit that it’s all your fault” http://lasting-benefits.com/2014/05/31/a-conversation-with-the-agile-manifesto/
  40. 40. This never happens This is how they expected Agile to work
  41. 41. THE RESULT • Software Development is treated as construction • Definable & Predictable • Much time will elapse before deliverables have value • Payment cycles should be long • Interim deliverables are close to irrelevant • Early termination represents a crisis to be avoided • Customer involvement is front loaded
  42. 42. REASONTWO
  43. 43. LEGAL REASONING • Is about following a Causal Chain • A Contract may not be indeterminate • Is based on precedent rather than pure logic • Changes very slowly (Stare Decisis) • Is always “behind the curve”
  44. 44. Enforceable via C ontractLaw Where the solutions to our problems live
  45. 45. LAWYERS • Are duty bound to “Obtain for their client the benefit of any and every remedy and defence authorised by law from threats seen & unseen” • Focus on protection when trust deteriorates • “Think the unthinkable” • Are conservative and combative
  46. 46. REASONTHREE
  47. 47. LACK OFTRUST
  48. 48. AGILE STRONGLY BENEFITS CUSTOMERS Far more than it does vendors
  49. 49. SO WHY ARETHEY RELUCTANT? AndVendors so very keen?
  50. 50. SUPPLIER MOTIVATIONS • A genuine desire for customer success • Mindlessly jumping on the latest bandwagon • Seems like a good way to get “off the hook”
  51. 51. A MARKET FOR LEMONS? • Created after years of disappointing results • Drives the customers to gain profits from “side effects” • Based around fear and asymmetric information
  52. 52. THE CONTRACT SERVES AS A REPLACEMENT FORTRUST
  53. 53. IT ALSO DEFINESTHE RULES FOR A GAME
  54. 54. EACH PLAYER HAS A STARTING SET OF DESIRED OUTCOMES Supplier Outcomes Customer Outcomes
  55. 55. Legal Outcomes SOME OF WHICH ARE LEGAL Supplier Outcomes Customer Outcomes
  56. 56. Supplier Outcomes Customer Outcomes THEN WE NEGOTIATE Legal Outcomes
  57. 57. UNTIL WE STRIKE A DEAL Supplier Outcomes Customer Outcomes Legal Outcomes
  58. 58. SO FAR SO GOOD...
  59. 59. BUT…
  60. 60. Supplier Outcomes Customer Outcomes Legal Outcomes A GOOD LAWYER WILL GET IT TO LOOK LIKETHIS…
  61. 61. Supplier Outcomes Customer Outcomes Legal Outcomes BUT BE LIKETHIS
  62. 62. I WOULDN’T WANNA DO BUSINESS WITH ANYBODY WHO’D HAVE ME AS A CLIENT
  63. 63. ANDTHE SUPPLIER?
  64. 64. CUSTOMER COLLABORATION?
  65. 65. WE NEED A NEW GAME
  66. 66. THE AGILE ALGORITHM Define Objectives Set Constraints do { Plan Define Execute} until happy Enjoy
  67. 67. AGILE WAS RIGHT We need to remove Hazard rather than manage it
  68. 68. TRUST CREATES AN ECONOMIC SURPLUS
  69. 69. TARGET COST ALIGNS INCENTIVES
  70. 70. BUILDINGTRUST BUILDS PROFITS • TheTraditional approach uses Contracts as a replacement for trust • This however came at the price of increased “Transaction Costs” • Increasing trust reduces transaction costs – creating a larger “surplus” Transaction costs make up around 30% of the costs of any given project
  71. 71. SO WHAT ISTRUST?
  72. 72. WHO DO YOUTRUST? (and why?)
  73. 73. TRUST IS A RESPONSE, NOT A CHOICE (at least not a rational one)
  74. 74. IS BUILT ONTOP OF TRUSTWORTHINESS
  75. 75. TRUSTWORTHINESS • Competence • Honesty • Reliability
  76. 76. THE FIRST STEPTOWARDS WISDOM Is to say “I don’t know”
  77. 77. THE FIRST STEPTOWARDS TRUST Is to say “I don’t trust you”
  78. 78. PROTECT CUSTOMER INTERESTS • Incremental Delivery • A Clean Code Base • A low barrier to exit
  79. 79. PROTECT SUPPLIER INTERESTS • Share in the reward for early delivery • Compensated for early termination
  80. 80. VULNERABILITY BUILDSTRUST
  81. 81. BUILDTRUSTTHROUGH TRANSPARENCY • EncourageTransparency by increasing Safety • Create Safety by Protecting Confidentiality • Sharing Confidential Information builds trust through exposing Vulnerabilities
  82. 82. BUY SOMETRUST
  83. 83. TAKE MULTIPLE TEAMS FOR ATEST DRIVE
  84. 84. AN AGILE PROJECT IS NOT DISTINCT FROM IT’S PEOPLE You’re renting Individuals to Interact with…
  85. 85. YOU’RE NOT PROVING A CONCEPT You’re fostering collaboration
  86. 86. MULTI-TRACKING WILL INCREASETHE QUALITY OF PROJECT DEFINITION
  87. 87. REFLECT Does your business model really support Agility?
  88. 88. AGILE CONTRACTING HEURISTICS
  89. 89. EDUCATE & INVOLVE Lawyers in Agile
  90. 90. TELLYOUR LAWYERS • Early termination is no longer a cause for concern because we keep our code clean and our increments valuable (but contract for that) • We no longer believe we can completely describe the micro level activities that will result in our desired macro level outcomes • Not building stuff can be a good thing • We no longer wish to seek unfair advantage
  91. 91. CREATE AN IPD
  92. 92. REMEMBERTHIS? goto Define Solution goto Quote goto Plan goto Execute goto Complain fork Set Objectives
  93. 93. A Traditional Contract creates a Prisoner’s Dilemma
  94. 94. THIS CREATES AN IPD Define Objectives Set Constraints do { Plan Define Execute} until happy Enjoy Unless you know how many Sprints it’s going to take Where the dominant strategy is collaboration
  95. 95. MANAGE INTHETAILS
  96. 96. Probably doesn’t matter Awesomely Early Horrifically late
  97. 97. THINK RESILIENCE NOT ROBUSTNESS Which means you focus the contract on what you’re going to do when things go wrong
  98. 98. CHANGETHE LANGUAGE • The language we use day to day influences the way we think and act • Compare: • “The Current Hypothesised Implementation is” to “The System Shall” • Talking about “opinions” instead of “bugs”
  99. 99. KEEPTHE FOCUS ONTHE GOAL And off the Sprints (and don’t even mentionVelocity)
  100. 100. PROVIDE EXEMPLARS Story Maps and Impact Mapping are your friends
  101. 101. ENCOURAGE OWNERSHIP • Regular Reviews are not enough • Clients need to regularly accept as their own the software that the supplier has built • We value something far more highly when we perceive ownership (Endowment Effect)
  102. 102. FOCUS ON WHATYOU HAVE NOW Not just where you’re going
  103. 103. DON’T PUSH IT • Not everybody is ready or able • Not every software problem is complex
  104. 104. ITERATETOWARDS AGILITY • Get clients used to being more involved • And you being more involved with them • Avoid Sprint “Failure” penalties • Start with the introduction of re-ordering • Then move to substitution
  105. 105. ASKYOURSELVES And your customers
  106. 106. WHEN DOYOU WANTTO BE HAPPIEST? • At the moment the contract is signed? OR • When the Software goes into production?
  107. 107. SUBSTITUTE FEELING IN CONTROL For being in Control
  108. 108. WHICH REDUCESYOUR FEAR
  109. 109. OTHERWISE…
  110. 110. FEAR LEADSTO ANGER ANGER LEADS TO HATE HATE LEADSTO WATERFALL
  111. 111. info@lasting-benefits.com

×