Distributed Agile teams and alternative contractual forms - what works best?


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Distributed Agile teams and alternative contractual forms - what works best?

  1. 1. Distributed Agile Teams andAlternative Contractual Forms- What Works Best?Greg HutchingsGregoryHutchings@gmail.com
  2. 2. 2Distributed Agile Teams and Contractual FormsAbout the author…Greg HutchingsI live in Paris and work for Valtech,proposing, negotiating, managing andliving with large distributed agile projects.I travel often to Bangalore and withinEurope. I am originally from the SF Bayarea, where I was a client partner forThoughtWorks, after spending years insoftware product development.I’ve been involved with software teamssince the early 80’s, and have been usingAgile and XP practices with teams formallysince 2003 and informally since the early90’s.
  3. 3. 3Session outlineDistributed Agile Teams and Alternative Contractual Forms – What works best? Building and supporting contracts to engage large distributed Agile teams (30 min) In-depth Case Studies (30 min) Fixed-bid, T&M and pay for production contract alternatives (20 min) Discussion (10 min)
  4. 4. 4Building and supporting contracts Importance of the proposal Selecting and defining methods Types and structures of agile contracts Planning Releases, Iterations and Communication Client and Vendor Roles and Responsabilities Team organisation and roles Estimating functional and non-functional scope Alternative units for measuring software production Acceptance testing Warranties / Reversability
  5. 5. 5Distributed Agile proposal process Interest in doing distributed agile development is usually related to cost savings, ortime to market and enhanced capacity, and may focus on rates Most new large company clients I talk to have already have had an offshoreexperience, often not very positive or with mixed results, and have some fear Quality, productivity, schedule and budget control are all key issues for a client Methodology, included Agile, is often of increased importance for a client whenworking with an offshore vendor, and can help to address fears and concerns It is better to introduce offshore and onshore delivery staff early with a collaborativeapproach, and to absolutely involve the delivery team in estimates and clientrelationship building. After an understanding of the client’s needs is obtained – high level scope, timeframe and budget, and specific constraints, a proposal is prepared After the proposal is presented, reviewed, revised and agreed in concept, thecontractual development process begins
  6. 6. 6Selecting and defining methods in the contract In our proposals and contracts, we discuss Agile, Scrum, TDD, CI, and theimportance of collaboration; we incorporate lessons learned from prior projects Part of the Vendor role of developing business and ultimately writing and signing acontract is to understand the key drivers, concerns and constraints of the client,and another is to propose and coach success factors (agile adoption patterns) I discuss on-shore and off-shore roles, those that might be staffed by the Client andby the Vendor – with enablement / delivery trade-offs and relative priority A key role to define at the client is an internal distributed agile champion – whobecomes elemental to the contract negotiation and project execution, and who oftenbecomes the Scrum Product Owner. This person should be able to travel. The relative importance of knowledge transfer, cost, time-to-market and scope areimportant to clarify, allocate resources to and define acceptance of in the contract It is important for the proposal and then the contract to provide the team with timeto ramp-up, self-organize, perform an Iteration 0 and develop and validate sufficientrequirements / stories to begin Iteration 1
  7. 7. 7Types and structures of typical agile contracts Types and structures Time and materials Fixed bid: could be fixed capacity and/or fixed scope and/or fixed schedule Fixed cost per unit of work (Story point, UCP, Function point, etc.) Structures Pre-contract: verbal understanding, “hand shake”, email, letter of intent Simple contract for professional services – no scope defined, rates and budget Simple contract for software development – scope defined, total cost, timingassumptions defined with terms and conditions to protect vendor and client Hybrid contract – often a phase 1 (T&M or fixed bid) to define release backlog andhigh level estimates, assumptions and to produce a phase 2 fixed bid for delivery Fixed cost per unit of work. E.G. Valtech Software on Demand Building the contract collaboratively As with software, avoiding BDUF for contracts is a good practice. Iterate! MSA with SOWs is preferable if a longer term relationship is anticipated Maybe be best to meet and develop contract (from a template) together
  8. 8. 8Planning Releases, Iterations and Communication In addition to the type and structure, the contract will need to define the term of theengagement; it is useful to describe, plan for and gain commitment to events Although we probably don’t have enough precision in our estimates, yet, the clientprobably does have a budget in mind. After all, they are talking to you as a vendoror IT team which likely follows a budget exercise of the previous year. Based on a very rough sense of the work to be done, a capacity plan with a numberof iterations and a ramp-up in team size can be used to model what level of effortthe budget might cover. Especially for distributed agile projects, in the contractual discussion it is veryuseful to review a release plan of a number of iterations, and to discuss the need forface to face communication at iteration boundaries. For distributed projects weoften use a Sprint of 4 weeks, in part due to higher travel costs. A product or release backlog (high level requirements) is often shown as an exhibit.If the contract form is fixed bid, fixed scope, in order to protect client and vendoreither estimates involving development spikes on representative requirements orterms that permit substitution of or variance in scope are important.
  9. 9. 9Key events in a distributed agile IterationDay 2 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10IterationPlanning MeetingRequirementsWorkshopPrep Build Build Build Build Build BuildDay 1Week 1 Week 2Day 3DevelopmentDeployment ofprevious iterationDesignWorkshopEstWorkshopDevelopmentDevelopment of test casesSupport DeploymentDevelopment of testcasesUAT UATDay 11 Day 12 Day 13 Day 14 Day 15 Day 16 Day 17 Day 18 Day 19Build Build Build Build Build Build Build Build Build Package PackageWeek 3 Week 4 (Week -1)Day 20Next Iteration PlanningRetro-spectiveDemoDevelopmentTesting Testing Prior IterationPreparation of UAT Env Validate EnvDuring a distributed agile contract negotiation, I discuss the events in a sprintand which should involve face to face discussion.
  10. 10. 10Distributed Agile Events – roles and conditionsAbove is a sample description of some of the events in a distributed agile project.By discussing in the proposal and engaging via the contract the commitment of clientand vendor to communicate regularly face to face, the budget for travel and thecommitment of key staff to the project can be planned.Meeting /Session TypeFacilitatingRole Attendees LocaleSessionLength Pre-Condition Post-ConditionInput Responsible Role Output Responsible RoleReleasePlanningMeetingEMEM, PO, FM,PM, Arch, allBAs, Tech LeadFrance 1 dayProject is initiated,key participantsare on boardA backlog of highlevel requirementsis prioritized topermit planning ofthe iterations,overall release andmajor milestonesHigh levelfunctional andtechnicalrequirements,schedule andbudget contraintsPO, BAs, Arch,EM coachingRelease Backlog,known definition ofproject successEM, PM, POIterationPreparationPMPO, FM, PM,Arch, all BAs,Tech LeadFrance 20 daysDemo of previousiteration iscompleteEnoughinformation isavailable forfinalizing prioritiesfor the iterationand agreement toscope of iteration.Previous iterationscope "Done"status for eachscenario taken upPO, BAs, Arch,EM coachingHigh levelscenariosPM, FM, BAsIterationPlanningMeetingPMPO, EM, FM,PM, Arch, BAs,Tech Lead, DevsIndia 4 HoursHigh levelscenariosEnoughinformation isavailable forpreparingRequirementsOverviewHigh levelscenariosFM, BAsProritizedrequirementbacklog withdesired scope forthe iteration.BA + CustomerInputs Needed for the Session Session Output
  11. 11. 11Client and Vendor Roles and Responsibilities An agile contract should clearly state what is expected of each party, and of specificroles: who must do what, when, and sometimes how and where. Normally the client must approve budget, approve requirements and approveacceptance of delivered software, at a minimum, but it is nearly critical that theyparticipate in release and iteration planning, retrospectives and as product ownerusing the Scrum role metaphor, be available daily, even at a distance, to clarifyrequirements. These responsabilities need to be time-boxed, and particularly in the case of a fixedbid agreement, it is advisable and mutually beneficial to define the consequences ofbeing late. These may include transferring risk back from vendor to client (e.g. convert to timeand materials, assume capacity was consumed but wasted, etc.) or from client tovendor (e.g. a quality or scope debt was incurred by the vendor for not delivering) In this section of a contract an escalation procedure should also be defined so thatthe team does not become blocked prior to, during or after an iteration Executive sponsors / stakeholders should be defined, in the contract or exhibit.
  12. 12. 12Roles and Organization ChartProduct Owner(Owns Initiative budget)Domain expertsTechnical LeadSenior DevelopersRelease ManagementInfrastructureAgile Offshore CoachFranceFeature ManagerFranceExecutive Steering CommitteeExecutive Steering CommitteeTransversal CommitteeTransversal CommitteeOperational CommitteeOperational CommitteeDevelopment TeamProgram DirectorFranceProject ManagerTech Lead / CSMIndiaClient (typical)The larger the Client’s delivery involvement is, the less likely that theterms of a distributed agile contract can be fixed bid, and the morelikely that enablement will be the top priority.
  13. 13. 13Estimating functional and non-functional scope In all Agile projects, estimation is very important, and is necessary to plan releases anditerations Estimation units of a team often need to be translated into terms meaningful to the client The client’s units of measure vary, from story points, ideal days, actual days, use case points,function points, use cases, stories, large functional specifications, “a system sufficient toreplace the existing”, etc. Contractually, if the contract is not time and materials, something other than time must bedelivered and measurable in order to justify payment, and for distributed agile contracts themore easily and exactly the items or units can be measured and verified, the more clearcommunication will be and generally the better the relationship Clearly, it is very important to define the “Definition of Done” (everything implicitly includedwith a delivered with a product backlog item), within the team and in collaboration with theproduct owner. Ideally this includes pre-defined acceptance tests and the effort to define anddeliver them with requirements and executable code are included when doing detailedestimates The main point to make for distributed agile contracts is that you should define the unit ofmeasure in a manner that is clearly described and understood in the agreement, and can bemanaged, with incremental acceptance. We have found story points, similarly small-sizedproduct backlog items, Use Cases, UCP and function points to all be useful measures in thisregard. Teams often forget to include estimates in what ever units they are using for non-functionalrequirements in fixed bid contracts – or sometimes, even to adequately define theserequirements; the measurement of scope should include everything needed to completedelivery
  14. 14. 14Acceptance Testing Agile contracts or their associated proposals should define what acceptance tests are, whowrites them, validates them, performs them, where, and when. I often contractually suggest that the client participate in the definition of the acceptance testsduring the preparation of stories or use cases, and that they be discussed and validatedconsensually in the requirements workshop Acceptance of the delivery of an iteration is specified contractually to be associated with thepassage of the scope’s related acceptance tests, and in a fixed bid contract or a pay forproduction contract, this acceptance is often associated with the release of a payment. A KPI I recommend tracking is the % of functional tests automated, and I prefer to state in thecontract that feature delivery acceptance is assumed within a short period of time (eg 10 days)if automated acceptance tests pass and there is no indication by the client or team of otherreasons not to accept the delivery UAT is usually, at least with our clients, a separate phase of time that includes some additionalrisk in terms of time and budget, but which is absolutely necessary. We invite clientrepresentatives to iteration end demos and provide access to the project dashboard to reducethis risk. Customer visits to the offshore development site can be coordinated with demos andacceptance testing of the most recent iteration’s delivery if planned appropriately, and thispractice greatly increases the offshore team’s satisfaction level and the client’s confidence andtrust in the offshore team. In distributed agile projects, the importance of comprehensive and automated functional andnon-functional testing is critically important to serve as an objective indicator of project qualityand progress. Tools such as Rally Dev, Version 1 and others provide information radiators tokeep client and vendor in sync, and their usage is often stipulated in our contracts.
  15. 15. 15Warranties and Reversability Most vendor attorneys generally advise limiting the warranties provided by thevendor in many important ways However, clients wish to be reassured that the vendor is engaged and committedand aligned with the client’s business needs. These terms vary from country to country, and I have found warranties to bestronger in Europe than in the US in many cases. A common European standard isto guarantee that a custom app will be free of major or blocking defects for a periodof 3 months after delivery to production, and most often provides correctionservices at no charge. There may be penalty clauses for the vendor in the event ofmajor defects that require liability insurance to be purchased. Reversability clauses deal with the event that the Client decides to switch vendorsor in-source the application’s continued development or maintenance, by providingfor a knowledge transfer process supported by the vendor for a certain period andwith specific measures for completeness. Reversability clauses in a distributed agile team may require travel and/ortranslation services, so an appropriate budget should be defined and costed intothe contract at the time of its negociation.
  16. 16. 16Case Studies Case 1 : Employment agency application Distributed Agile project Fixed bid converts to bid per iteration Organisation and contract evolves and adapts Case 2 : eBusiness Catalog, eCommerce and POSAgile contract evolution in large distributed agileprogram Large distributed agile project Several interesting contractual forms Organisation also evolves and adapts, learning together
  17. 17. 17Case 1 : Employment agency applicationFixed bid -> bid per iteration Refactoring and port of a large temporary employment agency application Rewrite in Java of a large Forte application, identical feature set and human interface The distributed agile project was staffed with a relatively offshore team and smaller local team Project size : 6 500 person days Duration : 24 months Application to manage employment agency candidates (1000 agencies with > 5000 users) Acceptance criteria : Quality metrics Basis for invoicing : Acceptance of the iteration Project Results : Exceeded initial fixed bid budget by 3 iterations 2% defects beginning at the UAT (14000 functional test cases) Piloted September 2007 and went to production December 2007Fixed BidJune 2005 December 2005 June 2007 August 2007Bid per iteration / incremental acceptance UATRe-Negotiation
  18. 18. 18Case 1: Employment Agency ApplicationHow did this contract affect the team? The initial contract was bid for a fixed fee, with fixed scope, and though a desired time framewas agreed, there was no penalty for late delivery The onshore team was initially the sole point of contact with the client. They developed closerapport, negotiated the contract, provided estimates and built the requirements andarchitecture. The client wished to communicate in french and did not have face to face contactwith the offshore team. The offshore team was not involved in validating the onshore architect’s estimates, and did notfeel committed to the estimates, the contract or to the client Strained relations developed between the onshore and offshore teams, internally, andeventually with the client as quality expectations were not met. The client seemedunreasonable. A “blow-up” occurred when the quality level was consistently not acceptable. The parties met, including representatives from offshore, addressed some technical issuesrelated to human interface requirements, and renegotiated the budget and contract to permit re-estimation and budget fixing by iteration The now more collaborative and integrated team went on to successfully deliver theapplication.
  19. 19. 19Case 2 : eBusiness Catalog, eCommerce and POSAgile contract evolution in large distributed agile programProject was to implement an integrated multi-channel eCommerce solution with a new POS in 220 stores Progressively replace features of 7 legacy apps with a custom Java / WebSphere Commerce Server solution Distributed agile program began in France and shifted over time to large distributed team Project size : 15 000 person days. Duration: 3 years 4 contractual modes :• V1.C – Product Catalog, fixed bid, fixed scope – but no time boxing and 8 month delay!• V1.S - Sales (Point of sale) with integrated Catalog and eCommerce site – T & M with bonus /penalty.• V2 - Evolved Catalog and Sales for full production roll out – pay per productivity with velocity assumption• V3 - Time and materials support agreement, capped budget, prioritized backlogFixed bid duo-shore « agile »Jan 2005 December 2005 June 2006Time and materials with KPI – strong offshore T&M UATNegotiation• Change project management, France -> India• Rebalance French/India team and roles• Create direct India/customer communication• Quality and productivity indicators put in placeV1.CPOCDec. 2006V1.SNegotiation• V1.C delivered• V1.S negotiated, POC begun• Revamped process, ramped team
  20. 20. 20Case 2 : eBusiness Catalog, eCommerce and POSAgile Contract Evolution…BIG ramp up, T&M +/-Janvier 2007 June 2007 June 2008Pay per UCP, Rising Velocity assumptionNegotiation• Fine-tuned process for integration• Established UCP cost and budget• Forecast velocity and accelerationV1.S V2T & M with a capNegotiationNegotiation• T & M with + / -• Established PDbudget• Productivity & Quality• With trust established, returned to asimple time and materials mode forsupport of deployment and productionV3
  21. 21. 21Case 2 : eBusiness Catalog, eCommerce and POSAgile Contract Evolution… the T&M contract with bonus / penalty clause was in response to client demand for fixed bid andvendor concern about estimation risk and acceptance speed. This contract form had an effect on the team of very strong motivation to deliver completed use cases(use cases which passed their functional acceptance tests), but sustainable pace was not maintained.Morale was none-the-less very high. During this period, January – March 2007, the team ramped up from 18 to 90+ members, from 1 to 4delivery locations. The team earned the 5% productivity bonus by delivering 99,5% of Use Cases, but had a 2.5% penalty forquality based on integration tests The planned 2.5 month UAT and Beta test period was extended to 3.5 months, and a larger team thanplanned was maintained. During the release retrospective workshop we determined to broaden integration testing and definecollections of use cases that together delivered potentially shippable increments and real customervalue, and focus on ways to increase efficiency and production. We also agreed to discontinue thebonus / penalty clause.Quality ProductivityPerson DayIn-BudgetVarianceDefectRate andSeverityKPIQualityProductivityOK 2.5%Penalty5%Penalty5% Bonus +5% +2.5% 0Neutral 0 -2.5% -5%5% Penalty -5% -5% -5%V1.S
  22. 22. 22Keep it simple? A part of the contract on bonus / penalties we decided to discontinue…70% 80% 90% 95% 100%-5% -2,5% 0% 2,5% 5%70% 80% 90% 95% 100%-5% -2,5% 0% 2,5% 5%Inférieur ou égal àV1 Feature Complete (V1 F)Bonus / Malus au 15/6/2007V1 Acceptance (V1 A)Bonus / Malus au 31/3/2007Formule de calcul :∑ ((UC A / (UC A+UC Raf)) x UC Init)V1A =∑ (UC Init)V1.S
  23. 23. 23Case 2 : eBusiness Catalog, eCommerce and POSAgile Contract Evolution… The client was ultimately satisified with the team’s delivery in V1.S, but felt thatproductivity could be improved. We agreed and together defined a budget for feature development estimated in Use CasePoints (UCP). After substantial debate on whether velocity could be predicted, for commercial reasonsand based on some thin research on theoretical UCP productivity, a new contract wasagreed. The contract stipulated that we would bill the client for UCP delivered, and in effect, overa six month period, (6 four week iterations), deliver to the client a UCP productivity perperson that corresponded to the research. The total UCP (plus some) engaged by this contract were delivered, but only after 9iterations. The team became more efficient but not as much as predicted. Substantial collaboration was necessary between client, business analyst, technicalleads and project management to permit planning and accepting the UCP for eachiteration This ultimately resulted in a high trust relationship – and the contractual eventuallyevolved again, into… Time and materials. The project was deemed a success – and also a substantial learning experience.V2
  24. 24. 24New contractual forms to consider?- Valtech has introduced Software on Demand
  25. 25. 25What did the manifesto say about contracts?Manifesto for Agile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.© 2001 http://agilemanifesto.org
  26. 26. 26Conclusion Agile contracts are especially important for clients and vendors when largecommitments are at stake As an agile project itself, contractual forms evolve during a project It is better for both parties to gain some experience with a smaller commit level, andto inspect and adapt the contractual form Direct communication between the team and client are essential to optimize thelearning and evolution of the relationship and related contract Customer Collaboration trumps Contract Negociation – but contracts can benegotiated collaboratively and can be written to favor collaboration!
  27. 27. 27Questions and Discussion?
  28. 28. 28Thanks!Greg HutchingsE-mail gregoryhutchings@gmail.comLigne directe +33 (0)1 53 57 73 56Mobile +33 (0)6 87 25 00 58Greg HutchingsE-mail gregoryhutchings@gmail.comLigne directe +33 (0)1 53 57 73 56Mobile +33 (0)6 87 25 00 58