Legal Tips for Outsourced Agile Software Development

April 2014

Author: John A. Leonard

  1. Use Agreements Which Contain Common Protections– But Contemplate Agile.  Although not waterfall development, the parties still need to agree on what work will be done, the price, the ownership of Intellectual Property, and other issues that keep the project on track and describe expectations of the parties.  Agile replaces waterfall, but does not replace the need for a well drafted agreement.
     
  2. Designate User Story Acceptance Tests Before Coding.  Testing user stories should be part of the acceptance procedures.  It is generally better to designate the testing requirements at the time the user story is identified and ranked as well as whether automated testing (e.g. standard testing for validation of credit card payments) can be used to reduce costs.
     
  3. Use Change Orders to Manage the Relationship.  Product owners and scrum masters must communicate regularly regarding changes due to business functionality or complexity and should be documented by changes orders.  Pricing protections such as “Not to Exceed” quotations must also be subject to increases due to changes in the scope of work.  A pre-agreed process of change orders is an important part of any software development agreement.
     
  4. Protect Your IP.  All intellectual property originates as a trade secret.  From there, you can choose to migrate it to a registered trademark, copyright or patent.  Employees, independent contractors and anyone else who comes into contact with your IP creation or protection should transfer IP to the company and keep the IP secret pursuant to a technology transfer and non-disclosure agreement.  This is especially true when dealing with outsourced software development. 
     
  5. “Deconstruct” User Stories and Protect Value.  Agile development is based on validated User Stories.  Every User Story consists of the following elements: Hypothesis + Positive Testing Data with Actionable Metrics = Validated User Story.  Each User Story is implemented in one or more iterations.  Each element may be the basis of trade secret, copyright, trademark or patent protection.  Initially, treat all elements as a trade secret and migrate important elements to registered copyrights, trademarks or patents.
     
  6. Get the Most of Initial User Story Backlog Meeting.  With any release there should be an initial meeting to review and rank User Stories and discuss thoughts on how many iterations are required for a particular release.  The backlog meetings should be outlined in the contract.  The meeting is important to establish the working relationship, assumptions and whether additional end user customer discovery and validation should take place prior to programming.  Having the product owner list potential User Stories prior to the meeting is important.
     
  7. Take Steps to Avoid IP Contamination.  A significant source of liability can be the use of trade secrets, copyright or patents owned by others.  Outsourced programmers should anticipate that customers will require that all work be original.  With respect to patents, customers need to appreciate that programmers will only warrant that to their knowledge work does not violate another owner’s patent.  Use of open source may or may not be an issue, depending upon how the customer and end users plan on using an application and whether  object code will be distributed.  Hardware which contains firmware is especially problematic in this regard.
     
  8. Manage the MVP.  By definition, Minimal Viable Products (MVPs) are products which will change upon further customer discovery and validation.  Under these circumstances, parties may wish to abbreviate some, but not all of the issues discussed above.  Testing and acceptance could be streamlined; however, protection of IP is still important.  Programming must be original and ownership of IP must be addressed.

 

This Article is published for general information, not to provide specific legal advice. The application of any matter discussed in this article to anyone's particular situation requires knowledge and analysis of the specific facts involved.

Copyright © 2014 Fairfield and Woods, P.C.,ALL RIGHTS RESERVED.

Comments or inquiries may be directed to:

John A. Leonard