Agile vs Waterfall Legal Issues

Transcription

1 (Fr)Agile Developments: Handle with care? ANDREW JOINT ED BAKER GEORGE BERKOWSKI 25/06/2014

2 Agenda Introduction Working in an agile environment Agile vs Waterfall Legal issues in agile arrangements Drafting and structuring more agile agreements

3 Working in an agile environment

4 Agile vs Waterfall

5 Waterfall Development Requirements Design Build Test Release Time e.g. 1 Year

6 Problems In Waterfall Identified issues with waterfall developments

7 The Rise of Agility Alternative methodologies began to gain wide-spread popularity in the 1990s New methodologies focused on iterative development quick creation of working software on a piecemeal basis Not a new concept Why use agile? NASA

8 What is Agile Software Development? In 2001 prominent software developers met to agree the main values of agile development The Manifesto for Agile Software Development was created: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan while there is value in the items on the right, we value the items on the left more.

9 Agile vs Waterfall Not just about writing code Agile as a concept comes from S/w development Waterfall software development is the most common approach but changing rapidly Becoming a key requirement for a variety of IT agreements Refers to the whole process from conception to deployment in a planned structured process

10 Agile Development Time e.g. 1 month Subset of Requirements Entire Requirements Design Build Test Refine/Add Requirements Release

11 Agile Software Development Agile is an umbrella term that applies to types of iterative software development cycles Most common types of agile methodologies are: Scrum (most popular) Lean Extreme Programming (XP) Crystal Feature Driven Development Method (FDD) Dynamic Systems Development Method (DSDM)

12 What is Scrum? A Scrum team usually consists of 7 people (+/- 2 people) Less than 5, unlikely to have the skill set to do the work More than 7, communication overhead undermines efficiencies Big projects have multiple teams ( scrum of scrums ) The scrum team works together in short bursts of development activity called sprints. Sprints are fixed periods of time to design, build and test a portion of the overall project. Usually last between 2-6 weeks. Goal to deliver potentially shippable product

13 Scrum: The Backlogs The development project follows two key documents: Product Backlog Sprint Backlog The Product Backlog is the entire project to do list for all software features Covers everything the project could hope to achieve both realistic and not The Sprint Backlog is the team s to do list for the Sprint

14 Who s Who in the Scrum Team members: Have complete authority as to how the work gets done Have an area of specialism required for the project, but may be required to work outside this - doing the job not doing my job The Scrum Master is the: The shepherd /supervisor of the development team Problem solver Common for this to be a Supplier role

15 What is Scrum: Product Owner The Product Owner: Is responsible for the overall aim and goal of the project Represents the interests of the business owns the product backlog Prioritises the items on the product backlog for selection onto sprint backlogs creates acceptance criteria for the user stories Common for this to be a Customer role

16 What is Scrum: Product Owner Product Owner role is a key difference to waterfall transfer of risk/expertise requirement from Supplier to Customer Waterfall = what do I need? Agile = what I want Danger of single point of failure Is the Customer always best placed to do this?

17 Legal Issues in Agile

18 IPRs Mix of Customer and Supplier teams as part of scrum Mix of tools / input / data ownership of output Joint ownership Impact on warranties/indemnities OSS lends itself to agile concept GPL etc.

19 Liability Risk Transfer: More customer responsibilities Customer responsibilities ongoing Focus is on the micro Who has responsibility for Customer failures? What is the impact for Customer failures? Aim high/miss high approach impact on defining breach

20 Governance Governance becomes (more!?) important Critical from Customer s perspective only way to mitigate customer risk The process is designed to maximise the identification of problems, so Ostriching cannot be allowed In short sprint phases, timing is crucial

21 Termination Breach vs expected failures It s not right, but it s ok Whitney Houston Mid-project termination is hard Access to materials post termination e.g. product backlog, important

22 So is Agile a Good Idea? Less successful stories 2010, a bad year for agile: De Beers UK Limited v Atos Origin IT Services UK Limited [2010] EWHC 3276 (TCC) BSkyB Limited and another v HP Enterprise Services UK Limited (formerly Electronic Data Systems Limited) and another [2010] EWHC 86 (TCC)

23 Drafting and structuring more agile agreements

24 To recap.. 1. Sprint = an iteration of software development (design, build, test) 2. Product backlog = project to do list, contains all user stories 3. Sprint backlog = committed user stories for a sprint 4. User stories = an outcome based description of software functionality. 5. Product owner = customer role, prioritises product backlog, sets acceptance criteria.

25 Contracting for Agile Development Flexibility inherent in agile development is very different from waterfall, particularly in: Development Lifecycle Requirement flexibility Division of responsibilities between customer and supplier Despite this, contracts based upon a waterfall methodology are often used as a starting point when contracting for agile projects does this work?

26 Contracting for Agile Development Customer Requirements Common waterfall approach: 3.1 The Supplier shall perform the Development Services to provide the Developed Software to meet the Customer Requirements Specification set out in Schedule 1 by the Completion Date. Does this work for agile? What needs to change?

27 Contracting for Agile Development Acceptance Criteria Common waterfall approach: 7.5 No later than 30 days from the Signature Date, the Customer shall deliver to the Supplier the user acceptance criteria and test data for the Acceptance Tests for Developed Software. These criteria and data shall be such as are reasonably required to show that each module complies with the relevant parts of the Customer Requirements Specification. Does this work for agile? What needs to change?

28 Contracting for Agile Development Legal Acceptance Common waterfall approach: 8.1 Acceptance of the Developed Software shall be deemed to have occurred on whichever is the earliest of: (a) the signing by the Customer of an Acceptance Certificate following successful completion of the testing under clause 7.5; or (b) the use of the Developed Software by the Customer in the normal course of its business. Does this work for agile? What needs to change?

29 Contracting for Agile Development Termination Common waterfall approach: 7.6 If the Supplier: (a) is unable to correct defects within a period of two months from the commencement of Acceptance Tests under clause 7.2; or (b) fails Acceptance Tests on more than three (3) occasions, then the Customer may reject the Developed Software and terminate this agreement for material breach pursuant to clause 24.4(d). Does this work for agile? What needs to change?

30 Contracting for Agile Development Change Control Common waterfall approach: 16.9 The Change Control Procedure will apply to all changes requested by the Customer to the Specification. Within seven working days the Supplier shall prepare for the Customer a written quote of any increase or decrease in the Charges, and of any effect that such change would have on the Completion Date. No change to the Customer Requirements Specification shall be effective until a Change Control Authorisation Note is signed by both parties. Does this work for agile? What needs to change?

31 Contracting for Agile Development OSS Common waterfall approach: 18.4 Supplier warrants and represents that there has not been included or used any Open- Source Software in the development of the Developed Software nor does any Developed Software operate in such a way that it is compiled with or linked to Open-Source Software. Does this work for agile? What needs to change?

32 Contracting for Agile Development Therefore: Differences in methodology need to be reflected in the contract Using a waterfall contract for agile development will have unintended consequences T&M contract is one option, but Customers will expect some form of delivery commitment in higher value contracts. Delivery commitments need to work within the flexibility of the agile methodology

33 Conclusions

34 So is Agile a good idea? Success stories: this methodology let the IT department complete a project from start to finish, in a year, far less than the usual month time frame Research survey of 205 IT professionals using Agile said those benefits include improved quality, more opportunities for midcourse corrections, improved customer or business satisfaction, better alignment between business and IT and improved time to market

35 So is Agile a good idea? It depends on: The Customer success/failure is in Customer s hand must know requirements well The Customer s Product Owner(s) The Customer/Supplier being able to work together The size of the project team larger/multi-supplier is more riskier for agile Pricing model is it just T&M? The contract does it work?

36 Any Questions?

37 Speakers Andrew Joint Partner +44 (0) Ed Baker Associate +44 (0)