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.

Devil&Details On Agile Contracts

1,360 views

Published on

An overview of agile reasoning and agile contracts specifically

Devil&Details On Agile Contracts

  1. 1. ©2010TietoCorporation Devil&details in Agile Contracts Cristiano Sadun Manager Tieto, Software Solutions cristiano.sadun@tieto.com
  2. 2. Outline • Agile methods- overview • Why agile contracts? • Perspectives • What do we agree upon? • Pitfalls • Standard contracts • Real world cases • Q&A
  3. 3. ©2010TietoCorporation Agile methods Why, and what does it mean?
  4. 4. Agile methods – why, and what does it mean? 1994: 16% of IT projects are “successful”(*) (53% challenged, 31% failed) (*) Chaos report, Standish Group, 1994
  5. 5. Agile methods – why, and what does it mean? Waterfall (Royce, 1970)
  6. 6. Agile methods – why, and what does it mean? 0.5+ years time is the challenge t Requirements Design Implementation Test Requirements Design Implementation Test Requirements Design Implementation Test Requirements Design Implementation Test Change over in many modern environments
  7. 7. Agile methods – why, and what does it mean? “An ounce of prevention is worth a pound of cure”
  8. 8. Agile methods – why, and what does it mean? Running a software project: piloting a plane vs. driving a car
  9. 9. Agile methods – why, and what does it mean? • Agile methods are appropriate for contexts where external factors or changes weight more than internal: • Customer-related projects • Market-related projects • Changing or unknown environmental conditions (laws, regulations, cross country) • Long-running ( > 6 months) • The longer the project/effort, the most likely are changes along the way
  10. 10. Agile methods – why, and what does it mean? Introducing: feedback! • Projects are run in short iterations, with frequent re-planning • Scope is often not pre-fixed: • Scope changes (and their cost) are agreed at the start of each iteration.. • ..in collaboration with the customer.. • ..with demonstrations at the end of each iteration.. • .. and with formalized sign-offs. • Focus on responding to change over following a plan.
  11. 11. © 2010 Tieto Corporation Agile methods – SCRUM, a popular method • Iteration = “Sprint” (4-5 weeks) (is time boxed) • Each thing to realize = “User Story” (must be simple and testable) • Difficulty of the thing = “Complexity” (measured in “Story Points”) • Each thing to realize must have “Test conditions” • Things we may want to realize = “Product Backlog” • Things to will realize in the next iteration = “Sprint Backlog” • Each completed, working story is said to be “Done” • Every sprint is started with a “Planning meeting” • Concluded with a “Review meeting” • Things are supposed to be production ready after every sprint
  12. 12. ©2010TietoCorporation Agile contracts
  13. 13. Why agile contracts? Agile projects (and project management) ≠ Agile agreements
  14. 14. Why agile contracts? Traditional agreement + Agile project management = Disaster
  15. 15. • Based on fixed requirements, agreed project plan • Expects major, infrequent milestones at given dates • Regulates customer interaction limited to steering groups or PM • Progress reporting based on completion percentages • Separate change management procedure with change orders • Consequent payment schedule • Consequent penalties (or bonuses) Why agile contracts? A “traditional” contract supports
  16. 16. An agile contract need to support • Commitment from the customer(s) to actively steer the project scope via a given process; • Many, smaller deliveries; • Mechanisms for agreeing, signing off and crediting the work done; • Mechanisms to stop the iterations; • Commitment to describe the scope in a testable way • Commitment to “feed” the delivery machine with enough scope • Consequent payment schedules; • Consequent steering and penalties/bonuses clauses. Why agile contracts?
  17. 17. © 2010 Tieto Corporation Why agile contracts? Lower risk by continuous agreement
  18. 18. © 2010 Tieto Corporation Why agile contracts? Lower risk by continuous agreement
  19. 19. Perspectives • Agile methods are used by: • Software Houses • IT Departments • IT Services Suppliers • Agile projects requires agile contracts mainly in IT Supplier/Buyer context • ..or in SLA based IT operations. When independent parties need to agree on the process for defining the right scope along the execution.
  20. 20. What do we agree upon? • Traditionally, scope is given as a set of requirements + a compliance list • With agile processes, detailed scope is subject to continuous adjustment and re-agreement, starting from an initial common understanding • We still need to have a base for estimations, performance monitoring, evaluation of results and final acceptance
  21. 21. What do we agree upon? • Traditionally, scope is given as a set of requirements + a compliance list • With agile processes, detailed scope is subject to continuous adjustment and re-agreement, starting from an initial common understanding • We still need to have a base for estimations, performance monitoring, evaluation of results and final acceptance
  22. 22. What do we agree upon? • An initial scope (or “baseline scope”) provides basis for estimation and pricing • Items in the scope must be testable • The supplier keeps the delivery responsibility: i.e. there are clear acceptance criteria and liabilities for not meeting them • A process to monitor progress and ensure incremental acceptance is achieved (i.e. units of work “done”, “in production”, “signed off”) • There can still be a set of milestones and delivery dates • There can be an agreement on the average rate of delivery
  23. 23. Examples • Fixed price per Story Point • Fixed price per Story Point + time&material • Multimodel: fixed price phases, target price or time&material phases • Sequence of Sprints • Sequence of Sprints, with ramp-up and ramp-down • Incremental acceptance with micro- milestones
  24. 24. Pitfalls • General terms and conditions&templates • Are usually thought with traditional methods in mind, and so are “template” contracts in frame agreements: language, wording, expectations on how the project is run • Things that traditionally are in a contract, but shouldn’t • Commitment to a compliance list • Commitment to a detailed delivery scope • A detailed activity plan • Milestones over more than a month • Things that traditionally aren’t in a contract, but should: • Commitment by the customer to allocate resources to the process • Agreement to follow a given process,(sign-offs, acceptance progress) • Agreement to verify the delivery during the project • Clear responsibility of the steering group to sign-off progress • Allocation of responsibility for “feeding” the agile process • Commitment to produce testable requirements/stories
  25. 25. Unchanged • Agreement on a delivery/project closing date • At the date, the pre-agreed units of work should have been produced and accepted; errors in the delivery must stay in the agreed range. • “Delivery responsibility”/Acceptance matrix • The delivery must work as a whole. • Escalation mechanisms • The process depends on continuous agreement.. which may not always be there • Anything not impacted from continuous scope adjustment
  26. 26. Standard contracts • PS 2000 – a mix agile/traditional • Based on requirement analysis / solution description / construction / acceptance • Close customer collaboration (joing goordination group) • Uncertainty matrix / uncertainty increment • Allows partial deliveries • IDIQ contracts (Indefinite Delivery/Indefinite Quantity) • Range based agreements • Iterations sequence contracts • Sequence of fixed-capacity iterations with stop and rampdown triggers Early years: not many exist, and the ones which do aren’t perfect yet
  27. 27. Real world cases (Tieto) • Software product development • Tieto Energy Components (Scrum), 2006 - present • IT Departments • NetCom (Norway) Teknisk/IT (Scrum, Lean), 2006-present • Contracted delivery projects • Salsa project (Scrum), 2007-2008, (Scrum/Lean) 2010
  28. 28. Summary • Three things to remember: • Agile projects should not be run under traditional contracts; • Agile contract place emphasis on follow up of a given process (formal signoffs etc) for frequent mutual agreement between the parties • The final delivery can be very different from the initial scope. Traceability is critical.
  29. 29. ©2010TietoCorporation Q&A
  30. 30. ©2010TietoCorporation

×