First case law on agile IT projects

When applying the traditional waterfall method, the emphasis is on the design phase. In the design phase, all the technical and functional requirements for the software are drawn up. After this phase has been completed, the software is realized in its entirety, possibly divided into a handful of large components. This sounds logical, and makes contracting relatively easy, but in practice it  poses a number of problems. During the building process, new wishes and insights often arise. The waterfall method can then be experienced as a straitjacket, in which there is insufficient space for flexibility and manoeuvrability. In an extreme case, the software is delivered at the end of the project in accordance with design and planning, but the software does not meet the (actual) wishes of the customer. The agile approach offers a solution here.

In an agile working method, the emphasis is not on the design phase and formulating an end-result upfront, but on the process. Above all, there is an iterative, flexible process of software development. This usually means working with a central list of desired functionalities that have yet to be developed. These tasks are estimated by hours and prioritized. Within a fixed period of one or more weeks, the tasks with the highest priority are then taken up, with the intention that working software is delivered at the end of each sprint. By indicating the prioritization, the customer has a grip on what will be carried out and can easily adjust during the process. What the customer gains in flexibility, however, the customer may lose in terms of certainty about the end result to be achieved.

Developer DPDK spends almost three years building an online auction platform for client Dream Bid on the basis of the agile method. The launch of the platform is delayed several times due to issues with the system’s performance. After go-live, these problems persist and it turns out that a definitive fix would require a complete “rebuild” of the platform’s architecture. Dream Bid wants to wait nor pay for this rebuild and sues DPDK for damages.

In court, DPDK defends itself stating that the parties agreed on an agile approach. The functionality to be delivered was not predetermined and therefore whatever issues existed they do not amount to breach of contract. Moreover, according to DPDK, the fact that the architecture is not suitable for the desired number of users is the result of Dream Bid’s changes during the course of the project, which incidentally fits with the agile approach, but again cannot result in breach of contract.

The court finds the defense unconvincing and rules in favor of Dream Bid. The court bases this conclusion on DPDK’s duty of care. A software development agreement qualifies as a contract for services (Article 7:400 Civil Code). The developer must therefore observe the care of a good contractor (Article 7:401 Civil Code). In other words, DPDK must behave as a reasonably competent and reasonably skilled IT service provider. According to the court, a reasonably competent IT service provider can be expected to have provided a platform with an acceptable performance. If that were no longer possible due to changing requirements, DPDK should have explicitly warned about this. The fact that work is done on an agile basis does not in any way affect this warning obligation, according to the court.

A somewhat similar project ended up before the district court in The Hague (the judgment has not been published, but I represented the supplier). For several years, a software developer works on an investment platform. At the start of the project, only the basic outline of the platform is clear and development takes place on the basis of agile principles, with many changes along the road. When go-live comes into view the performance does not meet the expectations of the customer. Go-live is delayed several times, the customer loses faith in the project and eventually terminates the agreement for cause.

The customer argues, among other things, that it was not sufficiently informed about the agile method and what that would mean for the project. It is also argued that the supplier has not warned sufficiently about the consequences of the customer’s changes during the project, resulting in long project duration and potentially inappropriate underlying architecture.

In this case, the court dismisses the customer’s claims. The assertion that the system was not working properly and that on that basis there would be a shortcoming is dismissed on formal grounds without touching on the substantive issues. With regard to the duty of care, the supplier is able to demonstrate, in the form of emails and other documents, that they have indeed informed the customer about the nature of agile projects and have warned the customer about the potential impact of certain changes in the project. The multi-million euro claim is therefore dismissed.

The above judgments only come from lower courts and, moreover, strongly depend on the specific facts of those projects. One should caution to draw general conclusions too quickly on this basis. Nevertheless, a provisional conclusion may be appropriate.

The cases seem to underline that while it is relatively difficult to successfully hold a supplier liable in an agile project, this is by no means impossible. The most promising base will generally be the duty of care of the IT service provider. In particular, a supplier must clearly warn the customer when the customer (in its role of product owner) changes the course of the project in ways that affect the progress of the project or the suitability of the underlying architecture. As is evident from other IT cases, under certain circumstances, this could mean that a supplier must warn insistently, suggest alternatives or even refuse to proceed on a certain course.

In my opinion, both cases also illustrate a specific vulnerability of agile projects, in which, as mentioned, the emphasis is not on the design phase. There is therefore a chance that the actual wishes of the customer in terms of functionality and performance, which become clear during the project, ultimately do not match the underlying architecture of the solution. This is an important point to consider when starting an agile project.

Would you like to know more about the legal aspects of (agile) software development or IT projects? Feel free to contact our team.

Jeroen van Helden, attorney at law