Drafting contracts in the context of agile working methods: Scrum and Co.

Agile working and its importance

Agile working methods such as Scrum, Kanban and extreme programming have long been established approaches in software development and beyond. Companies are increasingly turning to iterative processes and flexible planning in order to achieve faster results and respond better to new requirements. As a lawyer specializing in IT contracts, I often see that this agility is not sufficiently taken into account in contracts and that uncertainties arise as a result. The basic idea of agile methods can certainly be captured legally, as long as the contract clearly reflects the iterative approach and the ongoing involvement of the client. An important point is to find the right balance between flexibility and legal certainty so that both parties can react to changes without being exposed to endless renegotiations.

Agile working relies on short development cycles (sprints) in which small, easy-to-implement steps are defined. This approach makes it possible to obtain regular feedback and immediately take requests for adjustments into account. In practice, this often leads to a higher quality end product because errors can be identified and corrected more quickly. On the other hand, it requires intensive communication and clear processes to ensure that iterative changes and contractual obligations do not contradict each other. In particular, the question of how the scope of services is defined and accepted is a key factor in avoiding disputes about the final state of the software.

For clients in particular, agility offers the advantage of being able to monitor costs and functions on an ongoing basis. There is no rigid project plan that is only reviewed at the end – instead, there are continuous interim results. However, companies must be prepared to actively participate and provide the development team with continuous feedback. If this willingness is lacking, the great advantage of high flexibility is lost and rapid iterations can come to nothing. As a lawyer, I therefore emphasize the need for a clear definition of roles and responsibilities in the contract so that no one can claim in an emergency that their involvement was not demanded or not contractually regulated.

If you want to integrate agility into a project in a legally compliant manner, you should regulate in the contract phase how sprint-related acceptances, changed functional requests and a dynamic prioritization of requirements are handled. This allows the process to be structured without stifling the basic iterative principle. Ultimately, such contractual integration also creates trust with the client, who can be sure that a binding framework exists despite the flexibility.

Importance of agile methods in the project environment

Agile working is characterized by frequent feedback loops, short iterations (sprints) and constant adaptation of the product backlog to current requirements. At first glance, the classic fixed-price contract, which is often used in the waterfall model, seems difficult to reconcile with an approach that is constantly evolving. However, my experience as a lawyer shows that agile projects are often very successful if both sides understand their role in the process and secure it contractually. The iterative way of working not only ensures faster partial results, but also promotes close communication between the development team and the client.

A major strength of agile methods lies in incremental development. Small work packages are processed in sprint cycles, usually lasting two to four weeks, and coordinated directly with the client (product owner). Requirements not only change, they are refined or reprioritized, which is difficult to map in rigid fixed-price contracts. However, this is precisely where the contractual sticking point comes in: If adjustments are to be possible at any time, it must be regulated whether and when this will result in additional costs or time expenditure.

In practical terms, agility can have the effect that a feature that was initially considered to be secondary suddenly turns out to be central, meaning that other tasks have to be postponed. In a purely waterfall-oriented project, this would be a classic “change” that would require a costly addendum. In an agile project, this change is noted in the backlog, reprioritized and taken into account in the next sprint. However, this raises the question of how remuneration and liability are regulated if the overall project has catalogs of objectives that are constantly changing.

The dynamic nature of agile projects must therefore not mean that the client loses all control over costs. Instead, regular sprint reviews can be included in the contract, in which the results are presented and the budget or functions are jointly evaluated. In this way, conflicts can be minimized and transparent decisions can be made without the agile approach being suffocated by lengthy formalities.

Question of contract type: service or work contract?

In German law, it is often decided whether an IT project is to be classified as a service contract (Sections 611 et seq. BGB) or a contract for work (Sections 631 et seq. BGB). In the case of a service contract, a diligent activity is owed, whereas in the case of a contract for work and services, a concrete result (work) must be delivered. In traditional development projects, contracts for work usually dominate because a finished software product is expected. In agile scenarios, however, a pure contract for work and services sometimes seems too rigid, as the scope is constantly changing. Nevertheless, agile elements can be anchored in a contract for work and services, for example by defining the core scope to be created, while additional features are considered optional packages.

Many of the clients I advise are surprised to learn that a combination of both types of contract can make perfect sense. For example, a minimum viable product (MVP) can be defined as part of the contract for work and services, for which the contractor owes a specific result. Any additional adjustments or new requirements could then be billed according to the service contract logic (time & material). In this way, the client receives a minimum level of planning security, while the developer retains the necessary flexibility to react quickly.

A common misunderstanding arises when the client believes that ongoing agile work automatically leads to a pure service contract and that they lose their right to an operational product. In fact, elements of a contract for work and services can be mapped in the sprint model: Each iteration delivers an “increment” that can be accepted, whereby part of the work owed is created successively, so to speak. This enables piece-by-piece completion without having to sacrifice agility.

The trick is to contractually define which sprints or features make up the work components and what individual acceptances look like. Especially when a project involves considerable sums of money, it is advantageous for both sides to clearly specify the legal consequences. This includes, for example, the question of what happens if a partial service is defective or a sprint is not completed as planned. A clear regulation preserves the advantages of agile methods while maintaining legal certainty.

Scope of services and scope definition

Describing the scope of services in an agile project is a tricky question. A purely agile approach provides for requirements – the product backlog – to be dynamically prioritized and continuously changed. There is often no comprehensive requirements specification because this could be outdated after just a few sprints. Nevertheless, it is important to define at least a rough “scope” when drafting the contract so that both sides know what goals are being pursued and where the limits lie. Such a scope can be formulated in the form of epics or main functions, for example, which are to be delivered in any case.

In the event of a dispute, a defined framework helps to clarify what was actually part of the agreed project and what is considered an innovation. If you skip this step, you risk ending up with disagreements about whether certain features are owed or not. Not every little detail needs to be written down; my clients in the tech sector in particular prefer to react flexibly to customer requests. Nevertheless, you should at least define which core requirements must be included in an MVP.

As soon as interim results exist, these can be contractually regulated as partial acceptances (“acceptance of sprint increments”). Each successfully completed iteration has the character of a partial service under the contract for work and services, which is reviewed separately. This procedure prevents ambiguities because each sprint review makes it transparent which requirements have been implemented and which defects may still exist. In addition, it creates a documentation basis that later serves as proof of the services provided.

As a lawyer, I recommend using the documentation of the sprints to monitor progress. This allows changes in the backlog to be fully tracked. If this is successful, subsequent accusations that a feature has been “forgotten” become much less likely. Instead, it becomes clear from the outset that changes are always part of a regulated coordination process that both parties actively help to shape.

Remuneration in agile projects

An important question concerns the remuneration structure, as the classic fixed-price contract is often diametrically opposed to the agile concept. In many agile projects, “time & material” (on a time and material basis) is billed because this allows changes and new ideas to be integrated immediately without having to conduct supplementary negotiations for every feature. However, this model can compromise the client’s budget security. Conversely, some clients want a fixed price in order to avoid financial uncertainty.

A common solution is a combination: a basic budget, which also contains a risk buffer, should cover the essential requirements, while additional requests or major changes are billed according to time & material. In this way, the project remains flexible without the client having to fear that all changes will lead to uncontrolled additional costs. In some cases, a fixed price is also agreed for a defined sub-area, such as the MVP, while extensions are developed in an agile manner.

Another approach is the cap price model, where billing is based on time and effort, but an upper limit (cap) is set that may not be exceeded. This preserves the greatest possible leeway in development, but still keeps the costs calculable. From a lawyer’s point of view, my advice is to regulate in the contract how exactly the working hours are documented and transmitted so that no discussions arise about billable activities.

In an agile environment in particular, it is also helpful to check at regular intervals, for example at each sprint, whether the expenses incurred are still within the planned budget. In this way, the issue of money does not only become a sticking point at the end, but flows continuously into project management. This is a great advantage for both sides because it prevents nasty surprises and contributes to realistic expectation management.

Possible liability issues

Liability risks arise in an agile context above all when one party assumes that a specific result is owed at a specific point in time without further agreements, while the other party considers the ongoing provision of development services to be sufficient. As a lawyer, I often see conflicts in which the client claims a finished product even though the specifications have changed several times during the sprints. To avoid this, a contract should contain clear provisions on acceptance and notification of defects.

If you divide an agile project into sprints, you can provide for a partial acceptance for each increment, after which a sprint result is officially accepted or reprimanded. In this way, poor performance is quickly noticed and can be rectified in the following sprint. This procedure reduces the risk of a confusing list of errors or open requirements appearing at the end of the project. A possible fiction of acceptance after a certain test period is also useful so that no sprint output remains in limbo indefinitely.

Another issue is unforeseeable difficulties, such as failures with third-party providers or unclear dependencies on external libraries. To avoid later disputes, it should be stipulated that the developer is only liable to a limited extent for such cases, provided that he is not responsible for the malfunction. It is also worth defining a defect classification (critical, important, minor) so that it is immediately clear how quickly problems need to be rectified.

Quick feedback is crucial, especially in an agile environment. For example, not reporting errors for months and only complaining about them at the end makes it more difficult to rectify defects and increases the potential for disputes. I therefore recommend establishing regular documentation and communication in order to address liability-relevant points early and clearly.

Service level agreements and duration

A major point of contention often arises after the core project has been completed, when maintenance tasks or ongoing support are required. In the agile approach, it is assumed that software will be continuously developed and adapted. However, if there is no clear provision for ongoing support in the main contract, the client may expect to receive continuous updates or bug fixes even after completion, while the developer wants a new fee for this. This dilemma can be solved with a separate service level agreement (SLA).

SLAs can define the timeframes within which disruptions of various categories are responded to and the level of remuneration for such services. This ensures transparency and prevents unclear expectations from leading to disputes after project completion. For example, a response time of a few hours can be defined for critical errors, while minor errors are processed in a cyclical update. You should also regulate whether patches and releases are included in the sense of a maintenance contract or whether each additional feature request is treated as a new order.

In my practice, I recommend that clients and developers alike address SLA rules early on, because the end of a project is not always clearly defined, especially in an agile context. If software is constantly being expanded, the core project can feel like it is “never” finished. Clear SLAs resolve this ambiguity by describing the point at which the development contract is considered fulfilled and ongoing maintenance begins. This not only ensures better planning, but also strengthens the relationship of trust because everyone knows which services will be delivered after the actual project.

Without such a separate regulation, the expectation can arise that developers and clients will remain in a permanent revision loop. This is neither efficient nor legally compliant. A separate SLA, on the other hand, makes the most of the agile basic idea, while maintenance is agreed as an independent service on fair terms.

Contracts between client and software development company: the problem of milestones and fixed prices

In my consulting practice, I regularly encounter projects in which the software development company wants to work in a consistently agile manner and therefore prefers not to commit to any specific milestones or fixed prices. For many clients, however, this is difficult to accept, as they want to at least have an overview of the scope and costs of a core package. This is precisely where a stalemate often arises, with the developer demanding flexibility and the client wanting certainty of costing. In most cases, it is highly problematic to completely dispense with milestones, as this leads to haphazard billing and the client fears having to pay a multiple of the original budget at some point.

However, this area of tension does not have to remain unresolvable. As a lawyer, I am currently working on a case in which we are aiming for a mixed calculation: A defined minimum scope of functions is regulated as a contract for work and services at a fixed price so that the client has a clear basis. At the same time, it is agreed that all additional desired features or significant changes to the functional scope will be billed iteratively and against time & material. This solution enables an agile approach and also ensures that the customer is not surprised by unforeseeable costs.

In this specific project, we have also introduced milestones that are based on sprints or comparable iterations, in line with agile thinking. Each milestone stands for a defined sub-goal that includes usable software. This allows the client to check how much has actually been created and, if necessary, make adjustments without having to renegotiate the entire project. This approach relieves the development house because it does not have to create a new calculation for every small change as long as the basic functions remain within the specified framework.

Transparency is the key to success, especially in complex projects. In the case mentioned, we have integrated an ongoing budget overview so that everyone involved can always see how far the project has progressed and how much budget is still available. This means that nobody loses track and a climate of trust is created. It helps immensely that the development company discloses its agile processes and explains how sprints are planned, how the backlog is organized and at what intervals reviews take place.

Most clients welcome this approach because it gives them both a minimum level of security and the benefits of agile development. As a lawyer, it is important to me to ensure that both the contractual objectives of the work character (certain ready-made core elements) and agility (ongoing adaptation, time & material for extensions) are regulated in a legally binding manner. In this way, agility does not become an incalculable risk, but a methodical advantage that is reflected in the contract design and represents a win-win for both sides.

Conclusion and recommendations for action

Integrating agile methods such as Scrum into contracts is by no means a contradiction in terms, but it does require careful agreements. A precise definition of the contractual parameters – from the rough scope and iterative partial acceptances to change request procedures and SLAs – prevents misunderstandings and creates legal certainty. Service and work contract elements should be combined in such a way that both the flexible approach is taken into account and clear results are achieved that can be measured and accepted immediately.

Those who choose an agile approach enjoy the advantage of fast feedback cycles and continuous optimization. At the same time, this increases the demands on communication, as clients must regularly prioritize and make compromises if there is not enough budget or time for all ideas. Liability issues can be elegantly resolved by providing for interim acceptances for each sprint or increment, reporting defects promptly and working on systematic documentation. This makes it possible to track what has already been implemented and which new changes have been added.

For me as a lawyer in the IT sector, agile projects show time and again how important it is to map the methodology clearly in the contract so that both sides have a common understanding of objectives, obligations and responsibilities. An underestimated point is the distinction between the development and operational phases in order to clarify whether and how maintenance or support services are provided. If you regulate all of this, you can concentrate fully on the benefits of agility and avoid legal pitfalls.

Ultimately, agility is not a panacea, but it does offer a dynamic process model that brings clear advantages, especially in fast-moving industries. To ensure that these advantages are not overshadowed by mistrust or legal uncertainty, it is worth seeking legal advice at an early stage. A solid contractual basis ensures that iterative methods do not end in confusing chaos, but in responsive and successful project implementation.