Agile Software Development: legal considerations when contracting for an agile project

From the inception of the Agile Manifesto in 2001, which recorded the 12 principles of agile software, there has been an increasing trend towards applying the methodologies of the Agile software development movement in preference of the traditional waterfall model. By most accounts, Agile has become the mainstream model of development, with former methods being cast aside as too slow and complex, whose output solutions often lack in quality.

However, despite its lauded benefits, contracting for an Agile software development project remains a challenge. Traditional waterfall methodologies operate on the basis of clear, defined stages of the development project with a fixed objective; as such, the project can be documented with relative ease. In contrast, the iterative, fluctuating nature of Agile means that capturing the rights and obligations of both developer and product owner is likely to require a more considered approach. With that in mind, it is important to carefully and properly record the basis of the project, together with the fundamental commercial terms, at the outset so as to avoid any confusion or dispute later on. This article sets out the key legal considerations to be aware of when contracting for an Agile software development project. Please note that we have adopted the concepts and language associated with Scrum methodology, but most matters discussed will also apply to other Agile models.

In any software development agreement, the fundamental starting point is to determine what the purpose and vision of the project is. Commonly, most waterfall software development agreements will focus heavily on the fundamental specifications (which in turn will inform whether the software is accepted or not). However, a well-prepared Agile agreement will set out the product vision as an overarching framework for the project that the parties collaboratively will work towards, and update as the customer’s requirements change. It is likely that the product vision will be set out in a separate annex to the main agreement, and should be continually referred to throughout the project.

Bearing in mind the principles set out in the Agile Manifesto, an Agile agreement should clearly define the key project roles; namely the development team, product owner (i.e. customer) and ScrumMaster. The Agile agreement should set out the roles and responsibilities of each of the individual personnel, together with the required level of dedication to the project. For example, are members of the development team entitled to work on any other projects during the current project term? Given that Agile projects can take place on a large scale, a detailed account of the expectations and responsibilities of each of the key players will avoid any ambiguity as the project progresses.

It is a fundamental principle of Agile that the parties regularly meet to assess the progress of the project and adjust if the customer requirements change. As such, the Agile agreement should give some indication of the timetable of planning and management meetings. Generally speaking, this will involve setting out how often the Scrum meetings, Sprint planning meetings and Sprint review meetings will occur. In particular, the Sprint process would normally be documented in the Agile software development agreement. The parties should agree on the duration of the Sprints, together with an acknowledgement from the parties that the duration of a Sprint cannot be extended. Any tasks that are not completed in a Sprint should be re-inserted into the product backlog and prioritised accordingly. This will ensure that valuable software is being provided to the customer at the end of each Sprint. The Agile agreement may also provide for a mechanism to determine how many high-priority items identified by the product owner can be developed, and once identified, that such items are fixed for that specific Sprint. On conclusion of a Sprint, a well-drafted Agile agreement will also set out when the next Sprint is due to commence. By providing a clear framework for the Sprint process, the parties will be able to focus their attention on delivering the agreed high-priority items to ensure that each Sprint is as productive as possible. In addition, the parties may wish to consider the detail in which the Sprint process is set out in the Agile agreement; it may be preferable that the finer elements of the process (such as the focus of daily Sprint meetings) are left as non-binding obligations so as to avoid a technical breach of contract.

Another key principle that applies to the Scrum model is the “Definition of Done”, being the criteria to determine whether the results of the Sprint have been completed. The “Definition of Done” can give rise to dispute if not properly defined, and therefore should be clearly specified in the Agile agreement. This will commonly include a review of code quality, nature and scope of tests to be applied and completion of any relevant documentation. The Agile agreement should also provide how the “Definition of Done” will be applied at each Sprint planning meeting to items developed during that Sprint, and who is responsible for ensuring that completed items comply with the “Definition of Done” on conclusion of a Sprint. If there is a dispute regarding compliance of a completed item with the “Definition of Done”, it may be sensible to include a dispute resolution procedure that the parties must follow (for example, expert determination or mediation) before they can commence legal proceedings. Finally, once all items in the product backlog have been completed in accordance with the “Definition of Done”, the Agile agreement should confirm when the project is deemed to be completed and whether any other acceptance criteria will apply.

The parties must also have a clear understanding of who will own the intellectual property rights in the developed software. Generally, it is likely that the customer will want ownership of the intellectual property in the code, therefore it is common that these intellectual property rights are assigned to the customer on completion of the project. If this is the case, the customer will own the software absolutely, and the developer will have no right to use the software after completion. If open-source software has been used, you will need to consider how this is dealt with in the Agile agreement.

Aside from these technical matters, we also suggest that the parties agree and document other key commercial terms, such as pricing, risk and liability, any warranties to be given by the developer, and what termination provisions will apply to the Agile arrangement. Each of these commercial terms will differ from those traditionally found in a waterfall agreement, and therefore we recommend that they are carefully and properly considered prior to entering into the agreement.

At Leathes Prior, we are able to provide bespoke and specialist advice to businesses in the digital sector, including on agile software development agreements and intellectual property protection. If you would like to discuss any of the matters contained in this article, then please contact a member of our Corporate & Commercial Team on 01603 281168.

Note: the content of this article is for general information only and does not constitute legal advice. Specific legal advice should be taken in any specific circumstance.