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.
Agile Contracts, can wemake them possible?Andrea Provaglio@andreaprovaglio
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”.
- Operational processes- Delivery and acceptance- Payment cycles- Responsibilities of the parties- Risk managementApparently, contracts areabout...
- Hopes- Fears (especially)- Collaboration- TrustLooking closer, they areabout:
Contracts and CultureContractProjectCultureModels(past)Inﬂuences(future)
==================================================Traditional contractsdont serve SD well
Wrong assumption:SD is like construction ormanufacturing.
- 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:
Accept that the client can’tknow everything upfront(and doesnt want to).responding tochange overfollowing a plan
Are pragmatic in theirmethods.Simplicity (the art ofmaximizing the amountof work not done) isessential
Ought to keep client andcontractor focused ondelivery and quality.working software isthe primary measureof progress
Building TrustTransparencyFeedback Value DeliveryOver time your contractstructure will simplify.
==================================================A Few AgileContractual Forms
Capped T&M with Iterations- Maximum budget is allocated, iterationshave a ﬁxed price- Goal is deﬁned, scope may change; time isﬂexible- Each iteration will deliver workingsoftware- Client may refuse to pay the iterationoutcome -- and doesn’t keep it
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 ﬁxed 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
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)
- 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
- 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
==================================================Resistance to Change
- 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 beneﬁts- Be creativeTo Wrap It Up
Thank You!LinkedIn Twitter SlideshareAlso on:http:// andreaprovaglio. comhttp:// beyondagile. com
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/