Contract drafting and agile software projects

IT-Projects

In software development agile project methods are becoming more and more important. Agile methods allow carrying out particularly large projects in which the scope is unclear in the beginning and a constant coordination with the client is possible.

There are different methods on how IT-project can be handled.

One widespread method is called the “waterfall-method”. Before the project starts the technical classifications are written down in a specification. The specification is then taken as the basis of the IT project´s contract.

In case of agile project methods such as Scrum, Kanban, Agile Data Warehousing, Crystal or Extreme Programming the requirements of the costumer for the software are developed together in small steps within the project.

Software development method Scrum

The aim of this widespread method is to provide the costumer with fast software that meets his specific requirements. The main focus of this method is to reach the project goals. However, the uncertain legal situation and the missing set of agreements in agile software development complicate working with Scrum and results in rather not applying these methods. Especially as the complex projects and the independent development phases bring legal peculiarities in the software production contracts.

Within this method the following questions are about to ask: how can isolated work contracts be applied to individual sprints and integrated into the sprint backlog without interfering? Are there possibilities of termination / exit strategies? How can uncertainties regarding the provision of services in the individual sprints be effectively compensated to ensure a smooth and safe operation?

Service or employment contracts in Scrum?

Within the scrum method the agreed contents are crucial for whether the contract is predominantly a service or an employment contract. The project-related cooperation and the strong participation of the client rather indicate an employment contract. Also if for instance the client adopts the role of the product owner and therefore the contractor does not have the central control of the project anymore it indicates an more employment contract.

Likewise a clear classification as a service contract is difficult because when closing a contract the features of the software are not yet clearly known. A quality agreement or payment arrangement present from the beginning is usually not existing or difficult to create.

Nonetheless: For contractual arrangement one should keep in mind that according to the jurisprudence a service-contractual success might already be found in the proper conduct of investigations or the preparation of reports.

Employment contract	Service contract
Only performance is owed, not success (e.g. consulting contract)	Success is owed, defect free work (e.g. construction projects)
No warranty rights/no acceptance	Warranty rights /acceptance
Right to terminate at short notice	Barely legal termination options
Bound by instructions	Not bound by instructions
Right to claim fee even when poor performance

Therefore it makes sense to categorize the individual “sprints” as isolated service contracts. In that case it is necessary to define a partial success within the sprint planning meeting and to document it in the sprint backlog in order to distribute the risks appropriately and provide legal certainty. These service contracts can be part of a framework agreement, which in turn contains general provisions such as compensation, liability or exit opportunities.

However, it is to avoid turning the sprint backlog into a service specification or functional specification with resounding impact on the basic catalogue of the product backlog. Because the product backlog with its overview of all elements of the product should be particularly effective as it does not precisely characterize the elements in the classical sense, but merely gives an indication of the direction for the initial estimated requirements. Main characteristic is thus its dynamic, what distinguishes it from the traditional service specification or functional specification.

What you should be aware of in case of a framework agreement

Generally, framework agreements are comprehensive agreements. Hereinafter only a few issues, which are in need of regulation, will be addressed.

Qualifications/Product Owner

Important within the agile framework agreement is that the parties agree on their respective qualifications. In this respect, the role of the product owner receives special meaning: he defines the product requirements – especially in light of the existing budget – as well as he has the responsibility for the content and use of the system to be developed. The parties should select him under strictest qualification-aspects and the relevant powers should be transferred to him. Only then he can accurately evaluate whether the performance meets the planned basic requirements. This is accompanied with the authority to initiate and implement changes in prioritization, goal definition and budgeting. If the parties have agreed on a person and / or the qualification of the product owner, it should then be written down in a contract.

Agile compensation policies

In addition it makes sense to rely on alternative compensation models within the agile contracts, which will properly balance the risk between both parties (e.g. function point method). Even the definition of compensation of single sprints is possible – but requires a lot of trust, as the number of sprints is often undetermined in the beginning.

Insofar as content requirements of the project results are broadly agreed on at the beginning of cooperation, the parties may also make an agreement on how many development cycles they expect for the implementation, how much time is most likely needed and the estimated costs – but caution is advised to not lose agility through the contractual agreements. In this context it is especially important to choose an agreement particularly suitable for the specific project.

Damages/rights of use

The question of giving certain rights of use is often of secondary importance and contractual clauses are mostly too inaccurate. Regulations about the date of granting such rights are usually missing completely. For failures in the contractual agreements the client is responsible. He bears the burden to proof that the alleged granting of rights is covered by the contract. The special feature of agile programming lies in it´s individual programming and that rights of use can already be generated on partial results. Therefore it is important to differentiate and determine the exact time the rights were granted and their scope.

In addition, individual clauses – like in classical software contracts – are recommended.

In many companies, the agile process methods will be in future part of their daily operations. Therefore, it will be more and more important that companies develop good solutions for contractual settlements within the agile process methods.