What to look out for when contracting agile software development?

Agile software development has become the core project management model applied by most, if not all, software developers nowadays. Often customers are unable to define their software needs from the commencement of a project, since they may vary depending on the business value, budget, profitability, its own clients’ requirements and other variables.

By over simplifying the concept, the agile process implies a flexible iterative development of the desired software, each iteration representing a so called “potentially shippable product” – i.e. a fully functioning standalone software module. This iterative approach to software development has been created to better adapt to the constantly changing requirements of the customers, as well as to deliver high quality products through on-going inspection and assessment of the software to be developed, continuous collaboration between cross-functional teams and prompt response to changes.

To put it bluntly:

agile means delivering what the customer wants even if he does not know it yet.

This model is not, however, without obstacles for lawyers. One of core the values of agile software development, and probably one of the most feared by legal professionals, is: “customer collaboration over contract negotiation”, hence the paradox. The question that we are often faced with in this type of engagements is: how can the parties have the flexibility of the agile model while maintaining the same level of protection as in standard waterfall development agreements?

This following article intends to give a broad overview on the most important aspects related to drafting agile software development agreements. For the sake of example, we will focus on the SCRUM methodologies, but many concepts presented herein are equally applicable to agile as a whole and are not limited to SCRUM.

1.      Shifting to agile: do we need a clean slate?

The short answer: YES!

Legal costs with contract drafting are never on the wish list of any developer or customer who wants to switch to the agile software development models, especially if they already have a very good standard waterfall software development agreement. Why can’t this agreement just be adapted to the new model when the subject matter is in fact identical: software development?

The truth is that the differences between the waterfall model and the agile model are significant, and adapting a contract which was designed specifically for the waterfall model may leave the parties exposed to various risks from a legal perspective.

2.      The essentials of drafting agile software development agreements

This section shall focus only on certain specific aspects of the agile software development agreements, such as the key roles in the project, sprints procedure, acceptance, liability etc. 

2.1.  Define the key roles within the project

Any agile software development agreement should identify the key roles in each project, as well as the obligations corresponding to each member of the project team. In principle, any such agreement should include the following roles and corresponding obligations:

The Product Owner

• is the key representative of the Customer;
• is responsible for clearly communicating the goals and objectives of the project (i.e. the customer’s requirements) to the development team;
• is responsible for drafting and on-going revision of the product backlog;
• is responsible for drafting and on-going revision of the release plan; 

The Development Team

• usually consists of employees of the developer (but could also include customer personnel);
• is responsible for the actual development and testing of the software;
• is responsible for estimating the effort required for the development of each item in the product backlog;

The Scrum Master (or agile coach)

• may be an employee of the customer, of the developer or a third party;
• the role of the Scrum Master essentially consists of support obligations for the product owner and development team (similar to a coach);
• the Scrum Master does not have any authority over the development team and the product owner, but must ensure that each of them cooperates in the most efficient manner and do not encounter any obstacles that may affect or impair the software development process.

2.2.  Define the sprint process

During the duration of the agile agreement, the software is developed in iterations, often called “sprints”. The duration of each sprint is at the sole discretion of the parties, but it is usually between 2 and 4 weeks. A sprint usually starts with planning of the respective iteration (aka the sprint planning meeting) and ends with the acceptance and review of the deliverables (aka sprint review meeting).

Although in practice there are discussions whether the sprint process, in itself, should be legally binding for the parties (claiming that a too rigid approach to the sprint process would be incompatible with the agile model), we deem that to a certain extent it is recommendable to make such process binding on the parties, as this would also better delineate the liability of each party in case the project does not progress as intend.

For example, planning and review meetings should be clearly defined in any agile software development agreement, whereas daily meetings could be left at the sole discretion of the development team in order to allow for better flexibility and time management during each individual sprint. 

2.3.  Create the Definition of Done

In SCRUM processes, the definition of done is the benchmark against which each deliverable from a sprint is measured, in order to determine whether it satisfies the customer’s requirements. Utmost importance must be given to the Definition of Done, since it will pave the way for any future liability of the developer. The Definition of Done should be carefully drafted and negotiated at the commencement of the project, to ensure that both parties have a common understanding on what “done” actually means with regards to the delivered software. For examples, the definition of done could provide that all customer’s functional/non-functional tests have been passed, that the acceptance criteria have been met for each product backlog item etc.

2.4.  Create a liability mechanism for delay

In principle, delay is not a common concept in SCRUM projects. This is because velocity (which represents how many product backlog items can be developed by the development team during a sprint) is usually variable. If certain items could not be completed during a sprint, they are returned to the product backlog and prioritized in future sprints. In this respect, lawyers find themselves in situations in which they avoid determining a specific liability for delay and rely on the other provisions of the agreement, such as the obligations of each persons involved in the project to self-organize and self-adapt in order to deliver in a timely and efficient manner.

In our view, however, this does not mean that the consequences of delay cannot be regulated in another manner. For example, in many situations velocity of the development team can be determined with high precision. In this respect, even though fixed milestone and deadlines are usually discouraged, certain provisions guaranteeing a minimum velocity can overcome such gaps. Nonetheless, lawyers should pay very close attention to how such clauses are drafted, to ensure that even the guaranteed velocity allows the flexibility required by the agile models. Drafting too rigid provisions would lead to bottlenecks throughout the project. 

2.5.  Dispute Resolution mechanism

Finally, agile models rely heavily on the collaboration of the parties. There are many points during each engagement that disputes may arise, such as: whether the delivered iteration meets the definition of done, whether the effort estimates of the development team are reasonable and in accordance with good industry practice etc. Of course, in each agreement parties try to solve any dispute amicably, but in case they fail they must defer the dispute to the court.

Under agile models, given the incremental delivery, such approach would create significant bottlenecks throughout the project. In this respect, a multi-tier dispute resolution mechanism is essential to any agile software development agreement. For example, any dispute which cannot be resolved between the product owner, scrum master and development team, may be referred to the middle management of each parties and ultimately to the top management of either party. Relying on an expert’s opinion is also often recommended in agile software development agreements, since many of the disputes are very technical in nature.

3.    Key Takeaways

With the shift from waterfall software development models to agile development models, customers and developers alike must ensure that adequate contractual mechanisms are in place, which accurately reflect the new software development methodology. Considering the significant differences between the two models, the adaptation of classic waterfall software development agreements is not recommendable, as there will always be a risk of significant gaps in the protection granted to the parties. 

Roles and procedures are the core elements of any agile software development agreement and collaboration of the parties represents the shell. Disputes should be treated as a natural part of the process, and should be solved amicably through adequate mechanisms without bringing the progress to a full stop.

Agile models represent a success story and are here to stay. It remains the job of legal professionals to ensure that the agreements keep up with the rapidly changing trends in the technology sector. In the end, flexibility doesn’t mean anything without adequate safeguards.