Everything is flowing smoothly – drafting contracts for agile projects

Particular problems of this conventional software development include the strong regulation and regimentation, as all the above steps must be organised and specified in detail (in writing) to allow monitoring of the development status and project progress. This naturally results in a significant documentation workload, above all. In addition to this, other difficulties include the complex requirements introduced at the beginning, which bring with them rapidly changing specific requirements, especially when many users work with the systems, who in turn have various different expectations of the project.

The idea behind agile software development, in contrast, is to create sub-processes that are as simple and flexible as possible in order to involve the software recipient more closely in the project as well as, above all, to ensure faster application of the development. The following principles serve as a basis for agile development:

• Working software is more important than comprehensive documentation
• Collaboration with customers takes priority over contract negotiations
• Responding to changes is more important than following a pre-set plan

For this purpose, trust should be placed in self-organised teams, which enables more intense collaboration with experts and developers and promotes the exchange of information through personal discussions.

The key feature of this type of program development is thus that the requirements and specifications are initially incomplete and can change during the project as well as after it is completed.

Here, the entire process of software development is not linear, but iterative in the sense that one also tries to approach the solution step by step. It is obvious that this, in turn, can only succeed if, as well as the previously addressed close and constant coordination between the involved persons or teams, there is a willingness on the part of the developers in particular to address changing customer requirements – including at short notice – even if this happens repeatedly. At the same time, this underlines the fact that close coordination and constant contact between the persons involved are essential minimum requirements, as this is the only way that the development process is even possible. Naturally, the physical proximity of the developers to the customers is closely related to this, to ensure an intensive and direct exchange of information.

For those who are familiar with the classic development process, a potential conflict for the development becomes apparent here: it will be almost impossible to name a specific price limit let alone to agree a fixed price. The basic principle of agile software development to implement desired changes even at short notice inevitably means the development effort and the required manpower are significantly higher, since it is not only necessary to keep programming services on stand-by, but it must also be possible to deploy these services individually for requirements at short notice. It will also not be possible to estimate an overall duration at the start of the project, and certainly no specific completion date, for practical reasons alone. Against this background, it becomes clear that agile programming can only be considered at all for selected projects and that both sides must be willing to move away from the previous classical specifications of program development.

For the specific contract design, this ultimately means that a defined goal in the sense of a contract for services cannot really be agreed. Although the basis of the collaboration is, of course, the ordering party’s requirement for a specific software development, because the design of the development work and the final result are both ultimately fully open, the focus is not on the concrete success but the programming services considering there is no list of specifications that must be worked through. As has already been described, in addition, it is almost impossible to agree a fixed price, meaning alternative invoicing methods will become established here, be it payment based solely on outlay or payment that is based on the use of the completed program.

It will also be particularly important to select and appoint specific people in a project team and to agree fixed discussion intervals and rules regarding how the results of such discussions are to be implemented.

It is clear even now that agile project developments will be much more significant in the future for extensive and complex projects.