Transcription
Presenting a live 90-minute webinar with interactive Q&ADrafting Agile Software DevelopmentAgreements: Guidance for Corporateand Technology CounselEvaluating Agile vs. Waterfall Development, Structuring KeyProvisions, Minimizing Contract DisputesMONDAY, NOVEMBER 23, 20151pm Eastern 12pm Central 11am Mountain 10am PacificToday’s faculty features:Paul H. Arne, Partner, Morris Manning & Martin, AtlantaAnne M. Friedman, Of Counsel, DLA Piper, Los AngelesCallum Sinclair, Partner, DLA Piper, United KingdomThe audio portion of the conference may be accessed via the telephone or by using your computer'sspeakers. Please refer to the instructions emailed to registrants for additional information. If youhave any questions, please contact Customer Service at 1-800-926-7926 ext. 10.
New Developments in an Agile World:Drafting Software Development AgreementsBy: Paul H. Arne1,2Software development agreements pose challenges to attorneys and clients alike. Havinga robust development process is a key factor in the likelihood of success of any softwaredevelopment project. Project failure rates are high. Both of these factors place demands onthose who provide or receive development services and those who memorialize the transactionand allocate risk. Companies are increasingly using a new development methodology, broadlyknown as "Agile." This relatively new way of developing software poses additional challengesto attorneys.If you are an attorney who drafts, negotiates or reviews software developmentagreements, you need to know about Agile. If you haven’t already been brought into adevelopment transaction involving Agile software development, you will. The use of Agilesoftware development principles may change the way your software development agreementsshould be drafted.Software Development GenerallyWaterfall ApproachGenerallyTraditional software development is often described as “waterfall” development.The basic components of waterfall development reflect a sequential approach to development.Generally speaking, they include the following processes, to be completed in order: conception,analysis (including requirements gathering), design, construction, testing, implementation,production use, and maintenance.3 Upon completion of each step, the process flows to the nextone, hence the term “waterfall.” This process was derived from more traditional disciplines formaking things, such as manufacturing or construction. Inherent in this approach is a substantialattempt to determine as fully as possible what will be built before construction commences. Onecan see how important this principle would be when constructing a building.Under waterfall development, changes of plans are generally discouraged andshould be given special and serious review and scoping before the change is actuallyimplemented. This places a huge emphasis on getting the design process right.1 Paul is the chair of the Technology Transactions Group of Morris, Manning & Martin, L.L.P. This article does notcreate an attorney/client relationship with you and does not provide specific legal advice to you or your company.Certain legal concepts have not been fully developed and certain legal issues have been stated as fact for whicharguments can be made to the contrary, due to space constraints. It is provided for educational purposes only.2 Copyright Paul H. Arne, 2013. All rights reserved. The author wishes to thank Mike Cottmeyer for his insightsinto Agile development, especially for large organizations. Mr. Cottmeyer is the CEO of LeadingAgile, LLC, acompany devoted to assisting large organizations transition to Agile development methodologies, including training,coaching and strategic consulting in portfolio management, project management, and transformation. Also, specialthanks to Austin B. Mills for his assistance in preparing this article.3 See Wikipedia, Waterfall model, http://en.wikipedia.org/wiki/Waterfall model (as of October 12, 2013, 16:45EST).
Very thoughtful and useful techniques have been developed to help organizationsfigure out what software features and functionality should be built, including stakeholderinterviews, visioning, brainstorming, naturalistic observation, prototyping, focus groups, andstoryboarding. However, requirements gathering and waterfall software development have atleast two inherent problems. It is hard for human beings to describe what they need when they haven’t seen itbefore. Few people could have envisioned an iPod’s interface before actuallyseeing it. There is a lag between the time something is determined to be needed and thetime it is delivered. Changing technologies or business circumstances arisingbetween the completion of specifications and delivery of the completed softwaremay result in changed needs.Why this is important: Success RatesSuccess rates for software development are somewhat difficult to come by.However, the most well-known keeper of these kinds of statistics is The Standish Group. On aregular basis, The Standish Group publishes its “Chaos Report,” which is a survey of the success,or not, of IT projects.Historically, these reports are positively gloomy. For example, in 1995, TheStandish Group received survey responses from 365 organizations, representing 8,380 projects.4Here are the success rates:5Project ResolutionPercentageType 1: Project success16.2%Type 2: Project challenged:Project completed, but it was over budget, over time, ordelivered less functionality than originally planned52.7%Type 3: Project cancelled31.1%These are scary statistics for IT organizations. As can be seen, cancelled projectswere about twice the number of successful projects; over half missed deadlines, were over4See The Standish Group International, Inc., The Chaos Report ChaosReport.pdf.5 Id. at 3.-2-
budget, or were delivered without requested functionality. While this author has no industrystatistics on this issue, anecdotally — after discussions with the IT litigators in his firm — itshould be of little surprise that some of the most frequent disputes in technology are thoseinvolving software development relationships.Faced with these statistics, one can also see how important is it to havedevelopment agreements that help manage the development process — especially in times oftrouble — and manage disputes.The Standish Group also asked respondents to identify the factors that caused ITprojects to be “challenged” (i.e., over time, over budget and/or missing functionality). Of thefactors identified, 51.8% of respondents identified factors that relate to the difficulty ofdetermining requirements or changing needs.6 Human nature and the inexorable pace oftechnology and business are at odds with some of the fundamental organizing principles ofwaterfall software development.The Case for Agile DevelopmentBefore getting into what Agile software development is, let’s see why it is important.Success RatesThe Chaos report for 20107 showed the following, based on projects examinedfrom 1994 through ll10%0%SuccessfulChallengedFailed6These response categories were “lack of user input,” “incomplete requirements and specifications,” “changingrequirements and specifications,” “unrealistic expectations,” “unclear objectives,” and “new technology.” Id. at 5.7 See The Standish Group International, Inc., Chaos Summary for 2010 ary.pdf.-3-
One can see from the chart that the use of Agile development methodologies wereconsiderably more successful on average than waterfall methodologies.From July 22 until November 1, 2011, a different research group8 surveyed individualsfrom various competencies within the software development community. 6,042 individualsresponded.9 The median size of respondent’s software organizations was 100 personnel.10 Therespondents reported that 80% of their organizations had adopted Agile management techniquesin their organization.11 Sixty percent indicated that over half of their companies’ softwareprojects are Agile-based.12 Comparing Agile-based development projects with priormethodologies used by their companies, between 71% and 84% of respondents indicated thattheir Agile-based projects (i) increased their ability to manage changing priorities (84%), (ii)improved project visibility (77%), (iii) increased productivity (75%), (iv) improved team morale(72%), and (v) sped time to market (71%).13Not surprisingly, there is a lot of interest in Agile development.What Is Agile Software Development?The name, “Agile,” can be traced back to a single event, in February, 2001.14 While thename grew out of that particular event, programming styles that are consistent with the principlesof Agile have been around for much longer. Examples include software developmentmethodologies called “Crystal Clear,” “Extreme Programming (or “XP”),” “Rational UnifiedProcess,” “Dynamic Systems Development Method” (or “DSDM”), “Scrum,” “AdaptiveSoftware Development,” and “Feature-Driven Development.”15 Many of the listed programmingtechniques are now treated as subsets of Agile.Out of that event came the “Manifesto for Agile Software Development,” set forth belowin its entirety.168The survey organization was Analysis.Net Research. The survey was sponsored by VersionOne, which is theprovider of an Agile development management tool. Please consider the source of sponsorship when reviewing thestatistics; however, some of the survey results are compelling. See VersionOne Inc., State of Agile Survey, 2011, 6thAnnual (2012), http://www.versionone.com/pdf/2011 State of Agile Development Survey Results.pdf.9 Id.10 Id. at 1.11 Id. at 2.12 Id.13 Id. at 7.14 See Wikipedia, Agile software development, http://en.wikipedia.org/wiki/Agile software development(subheading “Agile Manifesto”) (as of October 12, 2013, 17:12 EST). Seventeen software developers met at a resortin Snowbird, Utah to discuss lightweight development methods.15 Id.16 Manifesto for Agile Software Development, http://agilemanifesto.org/ (last visited October 12, 2013) (emphasisin original).-4-
We 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.Another result of this meeting was a statement of principles17, which is set forth in thisarticle as Exhibit A.Note the distinct lack of the following as objectives of Agile: predictability of timing,predictability of cost, and clear advance determination of what functionality is to be developed.Generally, Agile methodologies results in the delivery of working software at relativelyshort intervals — as often as two weeks. These intervals are frequently called “sprints.” Teamsof developers must therefore contain all disciplines necessary to deliver working code. Agileteams will normally be staffed with architects/designers, programmers, and testers.Industry Trends Point to AgileAnother force that moves software development towards Agile methodologies is thechanging method of how software is being delivered — specifically, software as a service.Traditionally, software was delivered and operated on computers owned or controlled bythe licensee. This means that delivery of significant upgrades to software tend to be majorevents. Each new upgrade carries a significant cost to both the licensor and licensee. On thelicensor side, software must be tested against multiple hardware configurations. Interfaces mayalso need to be tested. Maintenance and support personnel must have the capability to supportmultiple versions of the software simultaneously, because not all customers will migrate to thenew version at the same time. On the licensee side, new versions of software can requireextensive testing before introduction into a production environment, as well as potentially usertraining. Because of these costs, based on the author’s experience, major new versions ofsoftware tend to be delivered no more than about twice a year.When software functionality is delivered as a service over the Internet, these dynamicscan change. First, software has to be tested against only one hardware environment. Second,17Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html (last visited October 12, 2013).-5-
there is no compelling reason to not introduce new functionality on an incremental basis as it iscompleted. With incremental change, training can occur more as an ongoing process rather thanbeing driven by major releases. Support and maintenance personnel frequently only have to dealwith one version of the software for all customers.Because of the above, release cycles for new functionality can be greatly shortened,allowing for new releases as often as a few times a month.18 New software functionality nolonger has to be such a major event. This new and growing model for the delivery of softwarefunctionality lends itself to a more iterative software development process. Therefore, certainindustry trends favor the adoption of Agile methodologies, at least for some kinds of software.Software Development AgreementsPurpose of AgreementsIt goes without saying that software development agreements serve the samefunctions as other contracts. Normal contract functions generally include the following: Certainty. Identifying clearly what the various parties are getting, when, and atwhat price. Roles. Establishing which party is responsible for what activities. Allocation of Risk. If things go badly, then the contract should state theresponsibilities of the parties and which party is responsible for theconsequences of the problem. Help in times of trouble. When problems or disputes arise, it can be veryhelpful to have a process in the contract that enables dispute resolution short ofcontract termination or litigation.Development AgreementsSoftware development relationships usually involve, or should involve, significantinteractions between the parties. As a result of these interactions, there are some other objectivesin software development agreements that are not as necessary in other contractual relationships.For example, guidance in the agreement about how the parties will interact with each otherduring the project can be helpful to set expectations and define responsibilities, and therebyreduce uncertainty and risk. Putting processes into these agreements can help manage risk. The18The author recently attended a speech given by the CIO of a very large technology provider that deliverstechnology on a SaaS basis. He indicated that his company frequently upgrades its software twice a day.-6-
following terms, among others, can be used in software development agreements to guide theparties, catch and address problems early, assign responsibilities, and manage risk. Development of Specifications. Because software development agreementsare routinely entered into before the parties know specifically what is beingcreated, processes are often built into the agreement related to determiningrequirements, setting timeframes, and providing for the review and approvalof the specifications. Establishment of Price. At times, the cost will not be known, either, so theremay be a need to provide for a mechanism to determine how much thedeveloper will be paid and when. Management and Decisions Making. Contracts for large scale developmentprojects often define the organizational structures for managing projects aswell as identifying who makes what decisions during the course of the project. Milestones. Software development agreements frequently call for thedevelopment and identification of various milestones, and the responsibilitiesof the parties if these development milestones are missed. Progress Reporting. Catching problems early can be very important to theultimate success of a project. Provisions related to what is reported and when,as well as the obligations of the parties based on the substance of the reports,are often found in software development agreements. Acceptance. The acceptance process normally provides for (i) how completedwork is reviewed and confirmed to be in order, (ii) what the responsibilities ofthe parties are if the completed work is found to be inadequate, and (iii) whatthe responsibilities of the parties are if the completed work complies with therequirements of the contract. Personnel. Frequently, software development agreements will provide forhow and under what circumstances developer personnel may be added to oreliminated from the development team. For example, it is not unusual to haveprovisions that prevent key personnel from being removed from the projectabsent unusual circumstances. Changing Plans. The process of requesting, scoping and introducing changeinto a project is normally addressed.-7-
Describing these processes in software development agreements can help managethe risks.Using Agile Development Features to Manage the RiskSome features of Agile development are problematic to attorneys who rightfullyseek certainty and allocation of risk. When faced with the need to prepare a softwaredevelopment agreement — a kind of agreement that is already known to be fraught with risk —image your client not being able to tell you (i) what is to be developed, (ii) how much it will cost,and (iii) how long it will take. On top of that, note in the Agile Manifesto a natural bias againstcontracts generally (“Customer collaboration over contract negotiation”). As an attorney, youmay get business pushback as a matter of principle.19However, there are some key features of Agile that help reduce the risk ofdevelopment projects. These features may be useful to consider when drafting a correspondingsoftware development agreement.Agile embraces changes in scope. This uncertainty, however, suggests that anongoing process will exist for evaluating and determining the scope. Therefore, consideridentifying what that process is and build into the agreement the requirement of significantparticipation in scope decisions by both parties.Also, some kind of scope, anticipated resources, number of sprints, and roughtimeline still should exist at the beginning of a project. Therefore, consider making sure that atleast what is known about scope, timing and cost are made a part of the agreement.It goes without saying that one should contemplate in the agreement how changesto scope are handled in terms of development, time and money.It is also important for the attorney to put Agile development in context.Admittedly, in Agile projects it may be less easy to state in a contract specifically what is beingdeveloped, at what cost, and how long it will take. However, if over 50% of the time the reasonscited for projects being over time, over budget or missing functionality relate to the difficulty ofdetermining requirements or changing needs, how much risk are you reducing by insisting oncertainty of scope at the beginning of a project? Also, if statistically software development usingAgile methodologies is more likely to be successful, why would an attorney resist it just becauseit is less “certain”?19However, Mr. Cottmeyer, who knows some of the people who attended the meeting where the Manifesto forAgile Software Development was developed, indicated that those in attendance were focusing on “contracts” thatoccur between IT staff and business units within companies and not relationships with outside software developers.-8-
Agile encourages close collaboration between the business unit and the softwaredeveloper. This means that there will be one or more processes — structured, informal or both— that are going to be a part of an Agile development proj
Nov 23, 2015 · Drafting Software Development Agreements By: Paul H. Arne1,2 Software development agreements pose challenges to attorneys and clients alike. Having a robust development process is a key factor in the likelihood of success of any software development project. Project failu
