Computer system implementation using the agile methodology was intended to remedy the problems typically experienced with projects conducted using the waterfall approach, where the time and costs of implementation are ill-judged, often making it necessary to repeatedly conclude annexes to an agreement or litigate with regard to the scope of work assigned and late delivery. The agile approach to projects was also intended to render the final system more compatible with the client’s current needs, enabling a faster response if change became necessary.

Many clients hoped that this approach would mean that projects were conducted more efficiently, cheaper, and more effectively than those conducted using the agile methodology.

Unfortunately, as the agile approach becomes more popular in Poland, it has also become clear that there is an increasing number of unsuccessful projects implemented using this methodology, and of disputes over performance of agile project agreements.

Evidently, a certain level of maturity of an organization (especially the client’s organization) and of the personnel hired to conduct a project using agile methodology is essential for an agile project to proceed correctly. This level of maturity also means being mindful of the objective, i.e. a system that meets the client’s needs, but also budget control, i.e. monitoring the ultimate fee of the contractor for the entire implementation project, and the assignments that the contractor delivers to the client in each timebox/sprint.

This is because, in practice, the parties may at times come to ‘forget’ about budget monitoring, the importance of delivery of individual stages, and specification of what constitutes a deliverable when conducting a project using the agile approach and concentrating on adapting the contractor’s assignment to the changing needs of the client.

If there is no control over a project, this can also lead to concerns relating to intellectual property rights acquired by the client. If the parties break off the business relationship before the originally envisaged date, this can often mean that the client does not play for certain elements of the assignment, while the agreement stipulates that economic copyright to particular elements of the system passes to the client as of the moment of payment. In practice, the parties may not be certain of the scope of intellectual property rights that the contractor transfers to the client. If it is not known which parts the client paid for, it is very difficult to determine the elements to which the client has acquired the rights. In these circumstances, the client does not know whether they can lawfully use the delivered works.

The issue of cost-effectiveness from a commercial perspective of the work done by the contractor is equally problematic. Frequent revision of needs regarding functionality usually causes the assignment to be expanded, and consequently the client has to pay a higher fee. 

In view of the above, based on lessons learned when advising on projects conducted using the agile approach and the ensuing disputes, it is advisable for clients conducting projects in this way to carefully monitor and keep records of delivered products (including quality and delivery dates) and to remember the importance of the business element when conducting projects.  This is because, according to people involved in projects, even the best IT system, in the course of production, may never be completed due to steadily growing construction costs, where at a certain point the cost incurred and expected to be incurred cease to be acceptable to people responsible for the client’s finances.