In 2001, the authors of the Agile Manifesto probably could not foresee what flight the
concept of ‘agile’ would take. Most software developers nowadays work on the basis of
some form of lightweight development method and there are organisations that set up
their entire (non-IT) organisation ‘agile’. Much has been written in the legal literature
about the nature of software development agreements based on agile principles.
This literature usually amounts to a warning for the client who does business with an agile
developer: if you do not make agreements about the end result to be achieved, you
cannot hold a supplier liable for poor quality software.
We are now seeing the first case law on agile IT projects in the Netherlands. Do these
rulings confirm the warnings in the literature?
Agile vs Waterfall
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 priorit
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.
Auction platform
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.
Investment platform
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 way. 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.
Provisional conclusion
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? Please contact Natascha van Duuren attorney at law / partner at De Clercq.
Read The Full Version Here
