How to legally manage agile development without unnecessary disputes

Agile software development (Scrum, Kanban) allows you to respond flexibly to changes and deliver results quickly. However, this flexibility comes up against the limits of traditional contracts, which do not take into account the changing scope of work, budgets, or deadlines. Without legally binding rules, there is a risk of misunderstandings, delays, and legal disputes. ARROWS lawyers have extensive experience with IT projects and disputes arising from agile development – they will help you identify risks from the outset and create a stable framework for successful software delivery.

Author of the article: ARROWS (JUDr. Jakub Dohnal, Ph.D., LL.M., office@arws.cz, +420 245 007 740)

Typical legal issues in agile projects

Agile methodology itself does not cause conflict – problems arise from inconsistencies between the agile approach and poorly drafted contracts or expectations. Below, we describe the most common problem areas to watch out for and how to address them. For each point, we also provide recommendations (“solutions”) on how to mitigate the risk.

ARROWS lawyers are familiar with these situations and can help you prevent them in your contract and resolve any disputes that may arise.

1. Contract vs. constantly changing scope of work (scope creep)

Problem: Agile development is iterative – requirements for software features and functionality may evolve during the course of the work. If you have a traditional contract for work with a fixed scope, price, and deadline, you will encounter difficulties. The client often only discovers what they really need during development, and the supplier encounters new technical obstacles. A fixed contract at the beginning may therefore not correspond to reality a few months later.

This often results in delays and budget overruns—studies show that the vast majority of software projects face client dissatisfaction, often due to an improperly drafted contract. Perhaps you have also had the experience of not being completely satisfied with the development of externally developed software because everything was clear “on paper,” but the reality turned out to be different.

Real-life example: A company requested the development of a new application with a fixed scope for a flat fee. However, during the project, the company's management realized that several important features needed to be added. The supplier incorporated them, the work increased, and suddenly the project was twice as expensive and the deadline was not going to be met. Both parties found themselves in a dispute over who would bear the additional costs. Lesson learned? An overly rigid contract did not allow for flexibility in responding to changes.

Solution: An agile contract instead of a traditional contract for work. In an agile development contract, it is advisable to define the change process – for example, agree on regular reviews of the assignment after each sprint and a procedure for approving changes to the project. Instead of a detailed fixed description of the final work, the contract describes the product vision, the method of cooperation, and so-called “user stories.” It is important to agree on how the “Definition of Done” (a set of criteria for when a subtask is complete) and acceptance criteria for each feature will be specified.

These micro-agreed criteria function as small contracts within the project – they help to clearly define what is to be delivered and thus reduce the risk of disputes about completion. It is also recommended to agree on a mechanism for how both parties will handle scope changes (e.g., change sheets, approval meetings). ARROWS lawyers will be happy to prepare a contract tailored to your agile project, including clear provisions for the change process, so that your expectations and the reality of development are aligned.

2. Unclear intellectual property (IP) rights and open-source components

Problem: Who will own the resulting software and source code? This question is a source of surprisingly frequent disputes. In an agile project, development is gradual and different libraries or open-source components are often used. If the contract does not address ownership and licensing rights, you may be in for an unpleasant surprise: the supplier may claim that it retains the copyright to the work (and only grants a license to use it), or that it cannot transfer certain parts of the code to you because they are open-source under a specific license.

More than 70% of disputes in software development stem from unclear IP rights – typically when both parties have interpreted differently who owns the resulting code and whether it can be freely modified. Imagine investing in development, only to find out that you cannot develop the software with anyone else without the supplier's consent – a very undesirable situation.

Solution: The contract must clearly regulate the intellectual property of the software being developed. The safest option for you as a customer is to negotiate the transfer of copyright or an exclusive license to the software upon its completion. This will give you full control over the source code. If this is not possible, then at least insist on an extensive license for use and transfer of source codes after payment – without source codes, the software is difficult to expand and you would be at the mercy of the supplier. It is also necessary to address how open-source or third-party components are handled.

The contract should specify which open-source licenses are permissible (e.g., exclude components whose license would require you to publish your entire software). For components supplied by the client or open-source libraries, it is advisable to agree in advance who is responsible for them and what guarantees apply. Otherwise, code with legal defects (e.g., violating someone's license) could be integrated into your product, and a dispute could arise. ARROWS lawyers will help you precisely set up licensing agreements—from securing the transfer of rights or exclusive licenses, through the obligation to release source code, to addressing risks associated with open source.

3. Quality of delivery, defects, and liability for them

Problem: Every development project has bugs (errors) or unfinished work. The difference is how they are handled contractually. In traditional contracts for work, it is customary to provide a warranty for the work – for a certain period after delivery, the customer has the right to have any defects removed free of charge. In agile development, however, delivery is usually divided into many smaller units and the final “delivery of the work” as such may not even occur (the project may move smoothly to the next phase of development). If the contract does not contain provisions on liability for defects, warranty, and service support, there is a double risk: either you will not be clear about what you are entitled to when a problem arises, or each party will assume something different.

A typical trigger for a dispute is when the client discovers errors in the system and demands that they be corrected within the original price, while the supplier argues that this is beyond the scope of the agreed work. Without a contractual agreement, a stalemate situation arises – the client feels aggrieved by poor performance and the supplier does not want to work for free.

Solution: Clearly agree on the terms of liability for defects and subsequent services. A specific warranty service can be included in the contract – for example, that the supplier will repair any reported significant defects free of charge for a period of X months after the system is deployed. We also recommend agreeing on any long-term support and maintenance (e.g., in the form of a service contract or SLA).

Think about what will happen after deployment: will the supplier be available for repairs and updates? Under what conditions? All of this should be in the contract. A well-written warranty and service provision will help you avoid misunderstandings and disputes in the future. In other words, when both parties know where they stand—for example, that critical errors will be corrected within 14 days, less serious ones in the next version, etc.—you avoid conflicts arising from unfulfilled expectations. ARROWS lawyers regularly help clients set realistic warranty terms and defect complaint processes in contracts so that the quality of deliveries is enforceable and the supplier knows where their responsibility ends.

Who can you turn to?

[AUTHORS 6.23]

4. Data protection and regulatory compliance (GDPR)

Problem: Modern software often works with customers' personal data or other sensitive data. In agile development—with an emphasis on functional software over detailed documentation—there is a risk that aspects of data security and protection will not be sufficiently documented or addressed. For example, the development team may use real data for testing without permission, or it may not be clear who is responsible for security measures.

Data leaks or GDPR violations then lead not only to reputational damage but also to legal penalties. Did you know that violations of GDPR obligations can result in fines of up to $20 million or 4% of a company's annual turnover, whichever is higher? Such penalties can be devastating for a medium-sized company. A large proportion of incidents stem from underestimating security during development – up to 63% of data leaks are caused by inadequate security measures on the part of people and processes. Agile teams sometimes don't want to be “held up by paperwork,” but the absence of clear rules and documentation regarding data handling can have legal consequences.

Solution: Make sure to include data protection rules in the contract and in the development process. The contract should contain confidentiality clauses, clearly define who is the controller and processor of personal data, and impose security obligations on the supplier (encryption, backups, access, etc.). We also recommend agreeing that the supplier complies with the GDPR and is liable for any leaks caused by a breach of security on their part. In addition to the contract, it is also advisable to think about “Privacy by Design” during development – for example, include security and compliance criteria in the Definition of Done for individual tasks. Agile does not mean ignoring documentation completely – sensitive matters (such as the handling of personal data) should be properly recorded and approved by both parties. You can even arrange regular security audits after certain phases. ARROWS lawyers also specialize in IT compliance – they will help you set up a contract and internal processes so that development is in line with GDPR and other regulations, minimizing the risk of penalties.

5. Pricing model and financial uncertainty of the project

Problem: How much will development cost? – This is a question that company management wants a clear answer to, but in an agile project, the answer is not straightforward. Agile contracts are not usually flat-rate contracts with a fixed price for the entire project, because the exact scope of all requirements is not known at the outset. This can lead to tension: the client (the customer) expects a certain price level, while the supplier points out that the work may become more expensive due to changes.

If this is not agreed in advance, there is a risk of the budget getting out of control and a dispute over who will bear the additional costs. The client may feel that they are “paying more than they expected,” while the supplier may feel that they are “doing extra work for free.” Agile projects sometimes start with an optimistic promise of a quick, inexpensive basic version, but the gradual addition of features can multiply the final bill if there are no limits in place.

Solution: Set up the right pricing model and transparent financial rules. There are several models that can be used in agile contracts, e.g.:

• Time & Materials: You pay on an ongoing basis according to the hours worked and actual costs. This model is very flexible—you pay for what is actually done. Disadvantage: uncertainty of the final price, requires trust and control of the process.
• Fixed price with scope management: Combines the advantages of a fixed price and agility. You agree on a maximum price for a certain scope of functionality, but the scope can be adjusted – if something extra is added, something else must be removed to stay within budget.
• Target cost: You agree in advance on a target budget and, if necessary, a risk-sharing mechanism – e.g., if the project is completed more cheaply, you split the difference, and if it is more expensive, the supplier pays the excess. Both parties then have an incentive to work together effectively.
• Progressive delivery with ongoing financing: The project is divided into stages (milestones, sprints) and you pay a pre-agreed amount for each completed part. The client thus invests gradually and can stop the project at any time if they are not satisfied – losses are limited. The supplier, on the other hand, has the certainty of partial payments and the option to continue only if they deliver quality.

There is no universally best model – it depends on the nature of the project and preferences. Sometimes a combination is chosen, such as a budget cap in a Time & Materials contract, which reassures the client that the project will not exceed a certain amount unless an increase is additionally approved. It is important that you, as the client, have an overview of the financial drawdown and the ability to react in time if the project becomes more expensive. The contract should include mechanisms for reporting work performed and ongoing budget checks (e.g., monthly time reports, the right to audit the process, milestone meetings on the budget).

ARROWS lawyers will help you choose a suitable pricing model and clearly describe it in the contract, including protective elements such as price caps or retention amounts. This will help you avoid unpleasant surprises on your invoice later on.

When a dispute arises: litigation and alternative dispute resolution

Despite all preventive measures, a dispute between you and your supplier may sometimes arise. An agile environment is complex and different interpretations of the contract or expectations may arise. If disagreements escalate into an open conflict, there are several ways to resolve them – it is not always necessary to go to court right away. In fact, litigation is more of a last resort. First, try to reach an agreement; if that doesn't work, consider the options below. ARROWS lawyers always advise clients to assess which method of dispute resolution is the fastest and most effective for the situation at hand.

• Mediation: Out-of-court settlement with the help of a neutral mediator. The parties sit down at the negotiating table and, with the support of the mediator, seek an amicable solution. The advantages of mediation are speed, lower costs, and confidentiality – nothing takes place in public. In addition, you can maintain your business relationship; often, after successful mediation, companies continue to work together.

Mediation is particularly suitable if there is a misunderstanding regarding a contract, the quality of a delivery, or payment obligations. ARROWS lawyers can act as your representatives in mediation – they will advise you on strategy and ensure that the proposed agreement protects your interests.

• Arbitration (arbitration proceedings): A more formal procedure in which the dispute is not decided by a court but by an arbitrator (or arbitration panel) on the basis of an arbitration clause in the contract. Arbitration is faster than court, is not public, and you can choose an arbitrator who understands IT issues. The arbitrator's decision is legally binding and enforceable, similar to a court judgment.

Arbitration is often chosen for more complex technological disputes where the expertise of the arbitrator is an advantage. ARROWS lawyers will help you negotiate a fair arbitration clause when concluding a contract and will represent you before the arbitrator in a professional manner in the event of a dispute.

• Court proceedings: The classic route of taking a case to court is the last resort if agreements and faster methods fail. The disadvantages are longer timeframes (court proceedings can drag on for years), higher costs, and the public nature of the proceedings (the dispute may become public, which is not ideal for a company's image). On the other hand, only a court can issue a final judgment that, for example, compels the other party to fulfill its obligations if all other options have failed.

Sometimes, the mere threat of court action is enough to compel a defaulting or dishonest supplier to act. ARROWS lawyers have extensive experience in IT litigation – if litigation is necessary, we will provide you with comprehensive representation and protection of your rights in court.

Prevention is key: Practical tips for agile development clients

The best way to resolve a dispute is to avoid getting into one in the first place. Here are some practical recommendations on how to minimize risks before a problem arises. These recommendations are based on the experience of ARROWS lawyers who have been monitoring the field of agile development for a long time:

• Involve a lawyer from the start of the project: Don't consider legal oversight as something to be dealt with “when things go wrong.” Prevention is always cheaper than resolving a dispute. An IT law expert will help you set up an agile contract—covering specific terms (sprint, backlog, user story, etc.), handling the change process, and setting up the option to terminate the cooperation in case of dissatisfaction.

For example, a “for convenience” termination clause can be included in the contract after the completion of each phase, giving you the option to leave the project if it is not progressing well. ARROWS lawyers are familiar with proven agile contract templates and will ensure that the contract meets all legal requirements.

• Emphasis on communication and cooperation: Agile development relies on close communication between you (the client) and the supplier. Take advantage of regular meetings (stand-ups, sprint reviews, etc.) and insist that key decisions be confirmed in writing (e.g., in an email summary or minutes). This is not extra bureaucracy, but a way of ensuring transparency – if a dispute arises later, clear communication and records will prevent “he said/she said” arguments.

Build a partnership with your supplier, but also have healthy control mechanisms in place. ARROWS lawyers often advise clients to involve a steering committee or regular management status meetings in larger projects – such arrangements can also be included in the contract so that the other party is obliged to meet and resolve any issues on an ongoing basis.

• Internal processes and documentation: Even though the Agile Manifesto proclaims “working software over extensive documentation,” from a legal perspective, you need certain documentation. Make sure you have internal processes in place for versioning requirements, archiving source code, and backing up communications with the supplier. Have every change to the assignment confirmed. Create an audit trail – it may be useful in the future to prove what you have agreed upon.

For sensitive areas (security, architecture), feel free to request formal document approval even in agile mode. Modern tools such as Jira or Confluence can serve as living documentation – when used correctly, you have everything essential recorded. ARROWS lawyers can help you set internal documentation standards so that they are not overly bureaucratic, but at the same time provide sufficient evidence and clarity in the event of a dispute.

Conclusion: Be cautious but fearless with agile innovation

Agile software development can bring huge benefits to your business – faster time to market, higher customer value, and the ability to respond flexibly to change. At the same time, however, you must not underestimate the legal aspects. As we have shown, unclear contracts, unaddressed rights or obligations, and underestimating legal risks can lead to project cost overruns, loss of investment, and protracted disputes. Prevention and setting the right rules are absolutely essential in an agile environment.

The main idea is that agility and legal certainty are not mutually exclusive. With a properly drafted contract and adherence to the above principles, you can reap the benefits of agile development without fear of being surprised by a court summons or an unpleasant dispute. ARROWS lawyers have extensive experience in resolving disputes arising from agile projects and in preventing them. They will be happy to cover your back – whether in preparing a contract, consulting during a project, or representing you in a dispute.

Don't let legal uncertainty jeopardize your innovation. If you develop software agilely (or plan to) and are unsure whether you have everything covered, contact ARROWS. We will discuss your situation, review your contracts or draft new ones, and make sure that your development is not hampered by legal issues. By working with us, you can confidently use an agile approach, minimize risks, and focus fully on growing your business. Leave your legal worries to us – the ARROWS law firm team is here to ensure that your projects run smoothly and without legal disputes.

More than 2,000 clients already trust us, and we have been named Law Firm of the Year 2024. Join them – we are ready to help you on your path to agile success!

Don't want to deal with this problem yourself? More than 2,000 clients trust us, and we have been named Law Firm of the Year 2024. Take a look HERE at our references.