Protecting IP in an Agile Software Development Environment

“Gone are the days of three-year $50 million software programs. Now, I want returns on investment within three to five months. We need to change the way we develop software so that we can get things out into the market quicker.”

—Trevor Mather, Former CEO of ThoughtWorks

 

Over the last decade, there has been a movement among the software developer community to employ some form of “agile development” rather than the traditional software development methodology. The belief is that these agile methodologies lead to higher quality software and faster development cycles. More recently, the implementation of agile software development has transitioned not only from small startups to large companies, but also from enterprises developing noncritical, consumer apps to those developing software for medical, aviation, military, and financial systems, where the presence of errors pose high human or economic risk. With these transitions, intellectual property (IP) law practitioners must adopt their traditional lawyering approaches to capturing and securing IP (especially patent) rights. A failure to recognize and adapt to the agile software development environment will result in a failure of IP law practitioners’ essential job function—helping to create or sustain client profitability and enable long-term business growth.

 

Traditional Software Development

Before understanding what agile software development approaches are, we first discuss the “traditional” software development approach.

First described in 1970,[i] the traditional software development approach (often called the “waterfall approach”) involves a sequential, flow-down five-step process illustrated in figure 1. Waterfall projects begin with a requirements phase where all the functional, technical, and marketing requirements of the software are documented before moving to the design phase. There, the software architecture of the product is documented before moving on to the actual coding of all the requirements. Once coding is complete, the software is tested (and debugged) before it is deployed in a customer environment. This sequential “throw it over the wall” approach, where designers, developers, and testers fail to interact during each step of the process, takes place over the course of several months or even years. Thus, end users typically only get to see results at the very end of the waterfall project.

The major shortcoming of the waterfall approach is that all the requirements for a software product are defined at the beginning of a project, when project members rarely have perfect information. Thus, the most important design decisions are made with the least amount of knowledge. Further, as market changes inevitably cause user requirements to change over the course of a years-long project, pivoting to meet the competitive landscape is costly (and almost impossible).

 

Agile Software Development

In contrast to the sequential, waterfall approach is the agile software development approach. Generally speaking, the agile approach employs small, cross-functional teams of designers, coders, and testers working through multiple iterations (called “sprints”) that last two to four weeks in order to produce a potentially shippable product. After each sprint—each delivering a software product with increasing functionality—there is an opportunity for (internal and external) customers to review the latest incremental build. Agile is based on the notion that sometimes customers need to see the wrong product before they can articulate what they really need!

The agile software development movement traces its roots to a group of 17 influential software developers who, in 2001, issued a Manifesto for Agile Software Development and then formed the nonprofit Agile Alliance.[ii] The manifesto distills the agile development philosophy into 12 principles, the first of which reads: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Today, there is no singly accepted definition of what constitutes agile development. In fact, while a 2013 survey of over 3,500 software professionals concluded that 88 percent of organizations were using some form of agile,[iii] a 2012 survey of 200 companies found over 100 definitions of what the term even meant.[iv] Since then, numerous agile development approaches have been developed (e.g., Scrum,[v] Extreme Programming (XP), Feature-Driven Development (FDD), Kanban, Lean, etc.), all more or less adhering to the 12 principles to achieve higher quality software in a shorter period of time via self-organizing teams collaborating with customers with less documentation and reduced time to market.[vi]

As shown in figure 2, agile projects proceed in an iterative fashion where new features are integrated to extend the capabilities of the software. That is, each sprint delivers user-desired, working, and tested features. Each iteration generally consists of four distinct phases: planning, development, user review, and retrospective.

In the planning phase, all stakeholders (i.e., designers, testers, coders, and product management) meet to decide and document which new features are to be added to the software, or what changes to existing features need to be made. Once decided, the order of feature completion or change is prioritized. Next, the development team creates a list of technical tasks necessary to create each of the one or more desired features, and allocates a time and resource estimate to each such task. This phase comes to an end when all stakeholders agree upon the features to be implemented within the given time and resource constraints.

In the development phase, the development team works to code, test, and debug the one or more features agreed upon between product management and other stakeholders during the planning phase. Then, in the user review phase, the development team demonstrates the software and its newly implemented features or changes to product management (and perhaps potential customers/product advisors). Product management then decides if the software is correct and complete. Thus, completed features are removed from the list of features needing another planning phase, and incomplete features are again candidates for future iterations. Lastly, in the retrospective phase, the development team meets to reflect on the last iteration and discuss those tasks, techniques, and team interactions that worked and those that need improvement.

In sum, organizations implementing agile development approaches believe that the software development process improves through “more stable requirements, earlier fault detection, less lead times for testing, increased communication, and increased adaptive capacity.”[vii] With respect to measuring the effectiveness of various agile development approaches, one proponent states it best:

When it comes to measurements, agilists have a different philosophy than traditionalists. We believe that metrics such as cost variance, schedule variance, requirements variance, and task variance are virtually meaningless . . . . Instead, . . . [d]oesn’t it make sense to measure the success of software development efforts by the delivery of working software?[viii]

 

Challenges to Capturing and Protecting IP within Agile

There has been much written and debated about the patentability of software (and, more generally, computer-implemented inventions).[ix] This is especially true since the June 2014 U.S. Supreme Court decision in Alice Corp. Pty. Ltd. v. CLS Bank International.[x] Despite this, software—the output of a $600 billion annual revenue, two-million-person IT industry[xi]—is not only eligible for patent protection, but accounts for more than 50 percent of issued U.S. patents (as shown in figure 3). That said, we now turn to the challenges of capturing and protecting intellectual property within an agile software development environment.

As discussed above, agile software development emphasizes short time frames and fast-paced (“sprint”) work cycles. While agile development produces innovations worth protecting, the limits imposed by an agile methodology wreak havoc on the traditional workflow of an IP practitioner. For instance, traditional IP capture methodologies rely on a more relaxed flow of invention disclosure, evaluation, strategy, and IP rights procurement, which unfolds over a period of several months during (or sometimes after) a traditional product development cycle. In an agile environment, however, a faster-paced, condensed idea submission and evaluation process that occurs over the course of a few days or weeks is needed. Similarly, the rapid pace of sprints leaves developers with precious little time to strategize, analyze, document, and capture potential intellectual property. Thus, while the post-Alice requirements for robust software IP patent protection are increasing, the time available to evaluate and provide details for such software IP protection decreases within an agile environment.

Further complicating IP capture efforts is the reality that any given sprint may only result in completion of a portion of a product, rather than a fully functioning product. With only small portions of an ultimate deliverable being completed in each sprint, it can be difficult to determine when enough innovation has occurred to warrant seeking IP protection. Additionally, the use of many discrete sprints and their respective deliverables can cause clients to lose perspective and fail to appreciate that a series of smaller innovations can lead to a larger creative output worthy of IP protection. That is, agile developers often “can’t see the forest for the trees,” as they focus on smaller, more manageable sprint deliverables. Lastly, shortened agile time frames and a focus on sprint deliverables may contribute to a decrease in communication between team members and legal personnel, which also negatively affects the identification of, and action upon, protectable intellectual property.

In sum, a focus on smaller, more immediate deliverables in a shortened time frame can cause participants to lose sight of their deliverables’ innovative qualities when faced with specific agile procedures and a rush to deliver within a sprint’s time frame. An emphasis on continuous, iterative delivery may have the unfortunate side effect of devaluing innovative contributions in the eyes of many on the development team. That is, moving from one sprint to the next may often work against the reflection and reconsideration of earlier sprints, as the agile process forces participants to focus solely on what’s needed for the current sprint. Pushing requirements from one sprint to the next can create the false sense of “well, we’re just catching up to where we wanted to be in the last sprint,” rather than appreciating the innovation that has already been made. While the retrospective phase asks team members to consider what occurred in that last sprint, it will often not include IP considerations for the project as a whole.

 

Techniques

Against the backdrop of the many challenges presented above, we now provide six considerations for IP practitioners whose clients employ agile development methodologies in order to effectively identify and protect intellectual property.

 

Third-Party Nondisclosure Agreements with Feedback Clauses

During the many user review phases of an agile project, a developer has to necessarily disclose the product under development to a potential (external) customer in order to gain valuable insight about the features just developed. Thus, how does such a client protect its intellectual property? Well, a nondisclosure agreement (NDA)—even if it is called a “product advisor agreement”—is a must. But an NDA with a “feedback clause” is even better. A simple example of such a clause is:

Notwithstanding any other provision in this Agreement, if Customer provides any ideas, suggestions, or recommendations regarding the Product (“Feedback”), Company is free to use and incorporate such Feedback in its products, without payment of royalties or other consideration to Customer, so long as Company does not infringe any of Customer’s IP rights in the Feedback which existed prior to the time of providing such Feedback.

A more advanced example is as follows:

Customer understands that, as a product advisor, Company may ask that Customer: (i) provide feedback or input on a number of topics, including but not limited to, the design, functionality, user interface, development, and integration or release strategy of Company’s products or services; and (ii) participate in focus groups and/or the usability evaluation for certain Company products, prototypes, or mock-ups. Unless otherwise agreed to in writing by Company and Customer pursuant to a separate agreement, Customer acknowledges and agrees that any such feedback, input, or participation by Customer in any such activities (collectively, “Feedback”) is provided on a voluntary basis only and Customer will not seek or be entitled to receive any compensation in any form for such Feedback. Further, Customer agrees that no Feedback provided by it shall include confidential or proprietary information that is owned by Customer or any other third party, or that Customer is compelled to keep confidential by law or otherwise. To the extent that any IP is created, conceived, developed, or made during the course of Customer’s engagement as a product advisor, it shall be exclusively owned by, and is hereby assigned to, Company, whether it is based upon, makes references to, incorporates, or otherwise makes use of, in whole or in part, Feedback.

 

Personnel Agreements with IP Assignment Clauses

Given the current environment in which workers are as mobile as the apps they create, one of the biggest threats to a company’s intellectual property, unfortunately, is its own employees and contractors.[xiii] Thus, it is prudent for IP practitioners to advise their clients to: (1) enter into employment and contractor agreements that contain nondisclosure obligations and IP assignment clauses with all personnel upon their initial engagement with the company; and (2) implement physical and IT security controls (e.g., document management systems, data loss prevention software, USB block, etc.) to control access to source code files and design documents.

Further, fostering a culture of IP training (both formal and informal “brown bags”) and inventor incentives (e.g., remuneration, recognition plaques, annual dinners, etc.) will assure that company personnel are not only aware of intellectual property, but also enthusiastically participate in its capture, protection, and enforcement.

 

Copyright Notices

Software code and its resulting graphical user interface (GUI) and user experience (UX) designs are, of course, also protectable via copyright, which vests automatically when created. Marking code files with copyright notices provides some protection during agile sprints to at least warn all personnel with (authorized and unauthorized) access that such files contain company intellectual property. Actual copyright registration of at least a portion of a project’s software code (e.g., every x iterations or every y months) should also be considered to give clients the ability to send cease and desist letters, sue, collect increased damages, etc.[xiv] Thus, while a software product’s design should be evaluated from a (utility and design) patent perspective, copyright protection can also be a quick and inexpensive tool to protect intellectual property during and after agile development.

A simple example of a copyright notice for project files is “©” or “Copyright” followed by the year and company name. A more advanced copyright notice to remind personnel of the importance of intellectual property is as follows:

/*
* Copyright © [year] by [Company]. All rights reserved.
*
* The copyright to the computer software herein is the property of Company.
* The software may be used and/or copied only with the written permission of
* Company or in accordance with the terms and conditions stipulated in
* the agreement/contract under which the software has been supplied.
*/

 

Treat as a Trade Secret and Then Evaluate for Patent Protection

The trade secret laws offer protection for a variety of software-related innovations, such as any “formula, pattern, compilation, program, device, method, technique, or process.”[xv] Thus, any code or design that has independent economic value from not being generally known to the public can be classified and protected as a trade secret so long as reasonable steps are taken to keep it confidential. Thus, making sure that clients have a trade secret protection protocol with defined steps to mark, log, and track trade secret materials (e.g., code, comments, algorithms, design docs, etc.) is essential. For example, software code, comments, know-how, processes, algorithms, etc., can be labeled and protected as trade secrets. A client’s trade secret protocol—often termed a “data protection policy”—should include steps for determining: (1) whether the subject matter is already known, (2) whether the subject matter is able to be kept secret from end users, and (3) whether access to the subject matter can be controlled.

Once a trade secret protection protocol is in place and incorporated into the agile development process (e.g., before the user review phase), implementing the protocol involves: (1) marking and storing trade secret materials separate from non–trade secret materials; (2) educating employees (e.g., via new employee orientation, current employee reminders, and departing employee exit interviews) on the importance of marking and keeping trade secret materials confidential and restricted; (3) executing appropriate confidentiality or nondisclosure agreements; and (4) periodically reviewing documents and procedures for compliance. While there are no “magic words” that must be present to indicate a trade secret, recognizable phrases include “trade secret,” “confidential,” or “proprietary information.” Such phrases can be added to a header, footer, comment, background, etc., within any source code document, comment/notes file, manual, or any other project documentation.

An example of a more detailed trade secret label is as follows:

This document contains confidential and proprietary trade secret information owned and controlled by Company. Reproduction or distribution of this document, or use of the information contained herein in any way, is strictly forbidden without express authorization from the Company. Care shall be taken to maintain the confidentiality of this document and its constituent information and prevent its disclosure outside of Company facilities.

Information labeled as a trade secret during one sprint can be revisited and perhaps later filed as a patent application in a subsequent sprint or wrap-up review.

 

Series Provisional Patent Application Filings Followed by at Least One Nonprovisional

Given agile’s iterative approach, a client may best be served by filing one or more U.S. provisional patent applications during each sprint. An initial meeting at the planning phase can be used to set a rough roadmap for provisional application filings. Invention disclosure information can then be gathered during the development phase for filing before the user review phase.

With one or more provisionals filed according to a regular rhythm throughout the multisprint development process, one or more nonprovisional patent application filings can be filed at the end of the project. This rhythm should allow an IP practitioner adequate time to prepare resulting nonprovisionals that are robust (and “Alice-proof”) without losing any benefit of the provisionals’ priority dates. While a provisional, of course, should include a thorough, enabling description of the relevant subject matter, being able to ignore some of the nonprovisional application “niceties” and spend less time drafting claims allows the practitioner to adjust to the filing pace necessitated by the sprints’ short duration. Such a provisional drafting process can also help to reduce overall costs because any sums spent in preparing provisional applications should save cost when associated nonprovisionals are later filed.

A focus on a single, discrete innovation (or a few closely related innovations) in each provisional filing should allow the practitioner to optimize their drafting efficiency, while also minimizing back-and-forth between the practitioner and the inventors, who don’t have much time to spend on IP matters in a typical sprint cycle. Then, at the end of a project, the inventors, IP practitioner, and managers can reflect on the development work done and the provisionals filed, and revisit the filing strategy in order to finalize the nonprovisional filings needed for the resulting product. Lessons learned from one sprint to the next may alter or otherwise impact the initial IP protection strategy. Ultimate filings may include utility filings to protect the functionality of the product (which can take advantage of the filing dates of the earlier-filed provisionals), and design filings to protect the product’s GUI and UX (which, unfortunately, cannot claim priority to any of the provisional applications). Some provisionals, rather than being incorporated into a nonprovisional filing and published, may be allowed to lapse and remain secret, protected by the company as trade secrets instead.

 

Structured Invention Disclosures and Patent Application Filings

Drafting provisional and nonprovisional applications according to a modular and/or template approach created for the particular product under development should decrease the time (and expense) needed to prepare multiple filings. For example, a practitioner may develop one or more application templates that provide certain base information, background systems and methods, terminology, and other frameworks, upon which each filing can be built. Using such templates, the practitioner can then focus on describing the inventive aspects of the application without spending too much time (re)inventing the wheel, all while keeping pace with the agile development process. Shorter, “nonboilerplate” write-ups will result in shorter reviews and provide a better fit within the time and resource constraints imposed by agile development. The process described herein comports with the new first-to-file U.S. patent system by following the “Chicago voting rule”—file “early and often”!

 

Summary: An IP Rhythm to Match Agile’s Fast-Paced Iterations

As discussed above, IP practitioners have many tools at their disposal to advise and serve their clients in identifying and protecting intellectual property while accommodating the unique demands of the various agile software development methodologies employed by such clients. These approaches are not mutually exclusive and can be applied in various combinations to provide robust IP protection. For example, software developed through an agile process can be protected by an NDA, copyright, trade secret (in whole or in part), and multiple, modular template-based provisional applications followed by at least one nonprovisional application. Agile software development—like other innovations produced by various R&D methodologies—demands a multifaceted IP strategy, client engagement, and frequent monitoring by IP counsel.

As shown in figure 4, the goal of the practitioner should be to mirror the client’s agile development methodology with the six considerations discussed above. This results in an IP-educated development team entering into the planning phase where initial IP priorities are identified. In the sprint phase, inventions can be mined, and in the user review phase, provisional filings are made. During the retrospective phase, IP protection strategies can be reviewed, confirmed, and finalized. Using this rhythm, each iteration of the agile project provides a subsequent opportunity to further refine the IP capture/protection strategy. The resulting product can then be reviewed prior to release to identify further opportunities for (domestic and international) patent filings and other protection mechanisms (e.g., trademark and copyright registrations, end-user license agreements, etc.).

 

Conclusion

More and more clients from enterprises of all sizes and from varying industries are producing (and will begin to produce) software using agile development methodologies as they seek to produce higher-quality software faster. While the adoption of these agile approaches has no effect on IP rights themselves, it does affect how IP practitioners should counsel their clients. That is, IP rights are IP rights, and the basic requirements for their registration and enforcement obviously remain unchanged. But, if the First Commandment of Business—“know thy customer”—is a guide, IP practitioners should educate themselves about the agile methodologies their clients use to innovate, and be more nimble in their approach to counseling and securing IP rights for such agilist clients.

This article, which originally appeared in the ABA’s Landslide® Magazine in July 2015, reflects the authors’ current personal views and should not necessarily be attributed to their current or former employers, or their respective clients or customers.

 

Endnotes

[i]. Winston W. Royce, Managing the Development of Large Software Systems, in Inst. of Elec. & Elecs. Eng’rs (IEEE), Proceedings of IEEE Western Electronic Show and Conference (WESCON) 328 (1970).

[ii]. See Kent Beck et al., Manifesto for Agile Software Development (2001).

[iii]. VersionOne, 8th Annual State of Agile Survey (2014).

[iv]. See Brian Bloom, Agile Development Costly, Confusing: Report, IT World Can. (July 23, 2012).

[v]. This is the most popular form of agile software development. (For a tutorial video, see http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm.)

[vi]. See Gaurav Kumar & Pradeep Kumar Bhatia, Impact of Agile Methodology on Software Development Process, 2 Int’l J. Computer Tech. & Electronics Engineering, no. 4, Aug. 2012, at 46.

[vii]. Id. at 49.

[viii]. Scott W. Ambler, Answering the “Where Is the Proof That Agile Methods Work?” Question, Agile Modeling (2014).

[ix]. See Raymond Millien & Christopher George, The Patentability of Software: Myths, Facts and a Proposed Test, IPWatchdog (May 28, 2014).

[x]. 134 S. Ct. 2347 (2014) (holding that an “inventive concept” must be present in a patent claim to ensure that, in practice, the claim amounts to significantly more than a patent on a law of nature, natural phenomena, or abstract idea).

[xi]. See U.S. Dep’t of Commerce, The Software and Information Technology Services Industry in the United States, SelectUSA (2012).

[xii]. U.S. Gov’t Accountability Office, GAO-13-465, Intellectual Property: Assessing Factors That Affect Patent Infringement Litigation Could Help Improve Patent Quality 12 (2013).

[xiii]. Symantec Corp., What’s Yours Is Mine: How Employees Are Putting Your Intellectual Property at Risk (2013)(citing survey results that 59 percent of U.S. software developers believe that they have the right to reuse source code they’ve written for their next employer; and 42 percent believe that employees should have ownership rights in their inventions).

[xiv]. See 17 U.S.C. §§ 411–12.

[xv]. Unif. Trade Secrets Act § 1(4) (amended 1985), 14 U.L.A. 437 (1990) (emphasis added).