Agile Contracting in the Second Decade of Agility
•
3 likes•1,027 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Agile Contracting in the Second Decade of Agility
Similar to Agile Contracting in the Second Decade of Agility (20)
Recently uploaded
Recently uploaded (20)
Agile Contracting in the Second Decade of Agility
- 1. AGILE CONTRACTING In the Second Decade of Agility @cgosimon info@lasting-benefits.com
- 2. Contracting for Agile Practices Contracting for Agile Benefits
- 3. MY BIO • Practitioner, Consultant,Trainer • Occasional CTO • 25+ years in software • 15+ years in “Agile”
- 4. MY HISTORY • Independent ISV • Multi-million dollar waterfall projects • Military Simulations • Internal AgileTeams • Outsourced Agile Development • Training / Coaching / Consulting
- 7. we’ve increased our Moral Hazard WE CONTRACT BECAUSE
- 8. Because we outsourced our Software Development WE INCREASED OUR MORAL HAZARD
- 9. Outsource our Software Development? SO WHY DID WE?
- 10. EXPERTISE
- 11. COST
- 12. RISK
- 13. THETRADITIONAL ALGORITHM goto Define Solution goto Quote goto Plan goto Execute goto Complain fork Set Objectives
- 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. 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. THE FUNDAMENTAL ASSUMPTION Is that we can describe what needs to be done so completely, that it doesn’t matter who does it
- 17. ANDTHAT BY DOING SO We’ll get the hoped for outcomes
- 18. HOWEVER…
- 19. IFYOU DEFINE ONLY ONE WAYTO WIN You’ve just created an infinite number of ways to fail
- 20. WHYTHETRADITIONAL APPROACH Is pre-disposed to failure
- 22. MAKING SENSE OFTHE WORLD WITHTHE
- 24. 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
- 25. What strategies are effective in each domain?
- 26. •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
- 27. Sense ➠ Categorise ➠ Respond Sense ➠ Analyse ➠ Respond Probe ➠ Sense ➠ Respond Simple ComplicatedComplex Chaotic Act ➠ Sense ➠ Respond
- 29. Simple ComplicatedComplex Chaotic Strong Central Weak Distributed Strong Central Strong Distributed Weak Central Strong Distributed Weak Central Weak Distributed
- 30. 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)
- 31. 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
- 32. It’s not that we’re failing at Predictive ReductionistTechniques They’re failing us
- 33. AGILE FRAMEWORKS Produce better results because they implement “Probe ➠ Sense ➠ Respond” loops.
- 34. UNLESS You wrap your Agile in a domain inauthentic wrapper
- 36. SO WHY DO WE CONTINUETO CONTRACT In such an inauthentic style?
- 37. REASON ONE
- 38. THE AWESOMETHING ABOUT AGILE Is that it’s so focused on Software
- 39. THE BIGGEST WEAKNESS OF AGILE Is that it’s so focused on Software
- 40. 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”
- 41. 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/
- 42. This never happens This is how they expected Agile to work
- 43. 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
- 44. REASONTWO
- 45. 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”
- 46. Enforceable via C ontractLaw Where the solutions to our problems live
- 47. 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
- 48. REASONTHREE
- 49. LACK OFTRUST
- 50. AGILE STRONGLY BENEFITS CUSTOMERS Far more than it does vendors
- 51. SO WHY ARETHEY RELUCTANT? AndVendors so very keen?
- 52. SUPPLIER MOTIVATIONS • A genuine desire for customer success • Mindlessly jumping on the latest bandwagon • Seems like a good way to get “off the hook”
- 53. 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
- 54. THE CONTRACT SERVES AS A REPLACEMENT FORTRUST
- 55. IT ALSO DEFINESTHE RULES FOR A GAME
- 56. EACH PLAYER HAS A STARTING SET OF DESIRED OUTCOMES Supplier Outcomes Customer Outcomes
- 57. Legal Outcomes SOME OF WHICH ARE LEGAL Supplier Outcomes Customer Outcomes
- 59. UNTIL WE STRIKE A DEAL Supplier Outcomes Customer Outcomes Legal Outcomes
- 60. SO FAR SO GOOD...
- 61. BUT…
- 62. Supplier Outcomes Customer Outcomes Legal Outcomes A GOOD LAWYER WILL GET IT TO LOOK LIKETHIS…
- 64. I WOULDN’T WANNA DO BUSINESS WITH ANYBODY WHO’D HAVE ME AS A CLIENT
- 65. ANDTHE SUPPLIER?
- 67. WE NEED A NEW GAME
- 68. THE AGILE ALGORITHM Define Objectives Set Constraints do { Plan Define Execute} until happy Enjoy
- 69. AGILE WAS RIGHT We need to remove Hazard rather than manage it
- 70. TRUST CREATES AN ECONOMIC SURPLUS
- 74. 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
- 75. SO WHAT ISTRUST?
- 76. WHO DO YOUTRUST? (and why?)
- 77. TRUST IS A RESPONSE, NOT A CHOICE (at least not a rational one)
- 78. IS BUILT ONTOP OF TRUSTWORTHINESS
- 79. TRUSTWORTHINESS • Competence • Honesty • Reliability
- 80. THE FIRST STEPTOWARDS WISDOM Is to say “I don’t know”
- 81. THE FIRST STEPTOWARDS TRUST Is to say “I don’t trust you”
- 82. PROTECT CUSTOMER INTERESTS • Incremental Delivery • A Clean Code Base • A low barrier to exit
- 83. PROTECT SUPPLIER INTERESTS • Share in the reward for early delivery • Compensated for early termination
- 85. BUILDTRUSTTHROUGH TRANSPARENCY • EncourageTransparency by increasing Safety • Create Safety by Protecting Confidentiality • Sharing Confidential Information builds trust through exposing Vulnerabilities
- 86. BUY SOMETRUST
- 87. TAKE MULTIPLE TEAMS FOR ATEST DRIVE
- 88. AN AGILE PROJECT IS NOT DISTINCT FROM IT’S PEOPLE You’re renting Individuals to Interact with…
- 89. YOU’RE NOT PROVING A CONCEPT You’re fostering collaboration
- 90. MULTI-TRACKING WILL INCREASETHE QUALITY OF PROJECT DEFINITION
- 91. REFLECT Does your business model really support Agility?
- 93. EDUCATE & INVOLVE Lawyers in Agile
- 94. 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
- 95. CREATE AN IPD
- 96. REMEMBERTHIS? goto Define Solution goto Quote goto Plan goto Execute goto Complain fork Set Objectives
- 97. A Traditional Contract creates a Prisoner’s Dilemma
- 98. 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
- 101. THINK RESILIENCE NOT ROBUSTNESS Which means you focus the contract on what you’re going to do when things go wrong
- 102. 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”
- 103. KEEPTHE FOCUS ONTHE GOAL And off the Sprints (and don’t even mentionVelocity)
- 104. PROVIDE EXEMPLARS Story Maps and Impact Mapping are your friends
- 105. 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)
- 106. FOCUS ON WHATYOU HAVE NOW Not just where you’re going
- 107. DON’T PUSH IT • Not everybody is ready or able • Not every software problem is complex
- 108. 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
- 110. WHEN DOYOU WANTTO BE HAPPIEST? • At the moment the contract is signed? OR • When the Software goes into production?
- 111. SUBSTITUTE FEELING IN CONTROL For being in Control
- 113. OTHERWISE…
- 114. FEAR LEADSTO ANGER ANGER LEADS TO HATE HATE LEADSTO WATERFALL