Agile Contracts – Can we make them possible?

4,145 views

Published on

One of the clearest signs of a strong, mature Agile culture in a software development organization is the degree of Agile in the contractual agreements with its clients -- and viceversa.

However, there is often so much resistance that, apparently, just the mere thought of an Agile contract defeats the envisioning capacity of many organizations.

There are of course solid reasons for this, but the three questions we'll try to answer in this session are: are these reasons so solid, after all?; are there alternatives?; and are there ways to make these alternatives more appealing for all parties involved?

With these questions in mind, we'll explore the nature of our traditional contractual forms and the culture they come from, in different situtations; we'll see which is our responsibility in making and signing these contracts; we'll see some real-life alternatives; and finally, we'll discuss practical way for facilitating a transition to a more modern approaches to this subject.

Published in: Business, Technology
1 Comment
33 Likes
Statistics
Notes
No Downloads
Views
Total views
4,145
On SlideShare
0
From Embeds
0
Number of Embeds
277
Actions
Shares
0
Downloads
0
Comments
1
Likes
33
Embeds 0
No embeds

No notes for slide

Agile Contracts – Can we make them possible?

  1. 1. Agile Contracts, can wemake them possible?Andrea Provaglio@andreaprovaglio
  2. 2. What I DoI help IT organizations implementbetter ways of doing business.I coach teams and individuals whowant to improve technically andrelationally.In 20+ years in IT, I had clients inthree continents and a U.S. workvisa for “extraordinary abilities inSciences”.
  3. 3. ==================================================Why Contracts
  4. 4. - Operational processes- Delivery and acceptance- Payment cycles- Responsibilities of the parties- Risk managementApparently, contracts areabout...
  5. 5. - Hopes- Fears (especially)- Collaboration- TrustLooking closer, they areabout:
  6. 6. Contracts and CultureContractProjectCultureModels(past)Influences(future)
  7. 7. ==================================================Traditional contractsdont serve SD well
  8. 8. Wrong assumption:SD is like construction ormanufacturing.
  9. 9. - Project is relatively predictable- Build all or nothing, over a long time- Feedback will be poor- Serious damage if project terminatesbefore completion- Payment cycles will be long- Rework is impossible, or at leasteconomically not feasibleTherefore:
  10. 10. Contracts are written bylegal professionals.
  11. 11. Trained and bound to...- Protect their clients- Be distrustful of unrealistic expectations
  12. 12. Tend To Care Mostly About...- Limitation ofLiability- Indemnification- Price / Charge- IntellectualProperty- Termination- Warranty- Service Levels- Payment- Delivery /Acceptance- Confidentiality
  13. 13. Usually Untrained On...- The nature of Software Development- The Agile principles- System thinking
  14. 14. This, plus the lack of trust,leads to inadequateSoftware Developmentcontracts.
  15. 15. ==================================================SoftwareDevelopment is aService
  16. 16. Software Development isabout the ephemeralizationof goods.
  17. 17. Both parties are in alearning process,explorative and heuristic.
  18. 18. Estimates will beinaccurate (and Agile won’tfix this).
  19. 19. ==================================================Agile Contracts arebased on AgilePrinciples
  20. 20. Create a framework forcollaboration and trust.customercollaborationover contractnegotiation
  21. 21. Promote frequent, regularfeedback.[...] satisfy thecustomer through earlyand continuous deliveryof valuable software.
  22. 22. Accept that the client can’tknow everything upfront(and doesnt want to).responding tochange overfollowing a plan
  23. 23. Are pragmatic in theirmethods.Simplicity (the art ofmaximizing the amountof work not done) isessential
  24. 24. Ought to keep client andcontractor focused ondelivery and quality.working software isthe primary measureof progress
  25. 25. Building TrustTransparencyFeedback Value DeliveryOver time your contractstructure will simplify.
  26. 26. ==================================================A Few AgileContractual Forms
  27. 27. Capped T&M with Iterations- Maximum budget is allocated, iterationshave a fixed price- Goal is defined, scope may change; time isflexible- Each iteration will deliver workingsoftware- Client may refuse to pay the iterationoutcome -- and doesn’t keep it
  28. 28. Fixed Price per Story Point- Rough amount of effort estimated at thebeginning, in story points- Product backlog is prioritized by the client- Story points come at a fixed price, thusdetermining the maximum budget- Each iteration delivers the stories withhighest priority, story points are billed- Client can change stories, except for theones being developed
  29. 29. Money for Nothing, Changesfor Free- Similar to Fixed Price per Story Point- Client can walk away before completion,by paying only 20% of the work not yetdone (compared to initial estimate)
  30. 30. ==================================================Real-life Examples
  31. 31. - Fixed price or T&M to create high-levelprioritized backlog- Estimated in story points- Fixed price per story point- Plus warranty and contingency- Leads to budget allocation- Stories can be replaced or dropped- Extra scope will be charged (extra budget)- Client is constantly involved- attends Sprint planning meeting and review (every two weeks)- approves stories and acceptance tests- participates in exploratory tests (monthly)- responds to questions within 8 hours- Bugs resolved in the next SprintCegeka
  32. 32. - Paul Klipp’s One Page Contract- Literally one page- A contract for “Programming Services”- Uncapped T/M with monthly billing cycles- Client owns source code- Contractor commits to workmanlikeperformance- Intellectual property is covered- Based on reciprocal trust and honestyLunar Logic
  33. 33. ==================================================Resistance to Change
  34. 34. Ignorance of the Agileprinciples
  35. 35. Mental Models
  36. 36. FearResponsibility to innovate (managers)Not protecting the client (legal pros)
  37. 37. Hidden Primary GoalSpending people’s money (public)Reduce risk, maximize profit (private)
  38. 38. ==================================================What We Can Do
  39. 39. Take full responsibility ofthe contracts we sign.
  40. 40. Be Agile before signing anAgile contract.
  41. 41. Recognize and respect theclients resistance tochange.
  42. 42. Help the client and legalprofessionals understandAgile, for the client’s sake.
  43. 43. Promote collaborationthrough transparency,feedback and valuedelivery.
  44. 44. Focus on delivery first,legally manage risk next.
  45. 45. Be creative.
  46. 46. ==================================================We’re Done
  47. 47. - Take responsibility of what you sign and ofits nature- Respect and understand the resistance tochange- First promote delivery, collaboration,feedback and trust; manage fears next- Be Agile and explain the business benefits- Be creativeTo Wrap It Up
  48. 48. Thank You!LinkedIn Twitter SlideshareAlso on:http:// andreaprovaglio. comhttp:// beyondagile. com
  49. 49. Acknowledgements- Thanks to these friends and colleagues:- Paul Klipp (Lunar Logic)- Johan Lybaert (Cegeka)- Maria Diaconu (Mozaic Works)- Stefano Leli and Roberto Lupi- References- http:// agilecontracts. org- http:// alistair.cockburn.us/ Agile+contracts- http:// jeffsutherland.com/ Agile2008MoneyforNothing.pdf- http:// infoq.com/ articles/ agile-contracts- http:// paulklipp. com/images/OnePageContract.pdf- Images- http:// mcfcrandall.wordpress.com/2012/09/02/words-of-wisdom/

×