Agile Development: Lawsuit Risks and Legal Preparations

1. Introduction: The Legal Landscape of Agile Development in Japan

Agile development is widely adopted in Japan for its flexibility. Unlike traditional waterfall development, it features an iterative approach. Detailed specifications are not fixed in the early stages.

This characteristic offers significant benefits to vendors (contractors). It allows for a flexible response to customer needs and speeds up development. However, from a legal perspective, it also creates new challenges and risks.

This article analyzes the lawsuit risks vendors face in agile development. We will also explain practical, real-world preparations to mitigate those risks.

1-1. The Unique Difficulties of Software Development

Information Asymmetry Creates Vendor Disadvantages

Software development requires specialized knowledge. This makes the content difficult for judges and users to understand. This creates “information asymmetry.”

As a result, situations often become disadvantageous for the vendor. Even if the contract favors the vendor, a judge may side with the user. Citing the information gap, they may pass harsh judgment on the vendor.

Some judges view development as being the same as general construction. They misunderstand, thinking it can be completed without user dialogue. However, agile development is completely different from construction. While the word “agile” has spread, it is doubtful whether it is correctly understood.

The Essential Difference from Waterfall

Software development is not standardized construction. It always involves customization. Therefore, changing requirements definition once it’s set is very difficult. Changes cause significant rework and cannot be easily undone.

However, users do not want to solidify specifications from the beginning. The main reason is, “I don’t have a concrete image yet.” In waterfall development, such rework is not permissible.

It is wrong to think that agile eliminates rework. In reality, rework can still happen. Agile is a mechanism that minimizes the risk of rework by repeating development in small cycles.

The Mindset Required for Both Vendors and Users

Agile development is structured in a way that makes disputes likely. It’s not uncommon for users to produce a large volume of materials *after* the project starts. Therefore, disputes may be unavoidable unless the user is cooperative and meticulous.

Projects generally take the form of renewing short-term contracts. This is also for the user to gauge compatibility with the vendor. Vendors must be thorough in recording their work. What they agreed to do, and what they did. Records are crucial for ensuring payment.

Users expect “something to be completed.” The vendor must understand and properly manage that expectation. It is necessary to control expectations through project management. Agile is fundamentally based on a quasi-mandate contract, but this does not mean exemption from liability. One must not forget that a heavy “duty of care as a good manager” (zenkan chūi gimu) is imposed.

1-2. Legal Responsibility

The type of contract for software development greatly affects legal liability. Agile and waterfall methods are suited to different contract types.

① Contract for Work (Ukeoi Keiyaku)

A “Contract for Work” is a contract that promises the “completion of work.” The vendor is obligated to deliver a product with specified requirements by a deadline. If the product is defective, they can be held liable for non-conformity.

This contract has a high affinity with waterfall development. Because specifications are fixed before development, the definition of “completion of work” is clear. Therefore, legal disputes tend to focus on “whether it meets specifications.”

② Quasi-Mandate Contract (Jun-I’nin Keiyaku)

A “Quasi-Mandate Contract” is a contract to entrust specific administrative processing. The vendor is obligated not to complete a product, but to perform the work properly. This is called the “duty of care as a good manager.”

Agile development is considered to have properties close to a quasi-mandate contract. This is because specifications change flexibly during development. Japan’s Information-technology Promotion Agency (IPA) has also expressed the view that a quasi-mandate contract is appropriate for agile development. (Source: IPA)

1-3. Legal Impact of Contract Types

The vendor’s responsibility changes significantly depending on whether the contract is for work or quasi-mandate. The main issue in a quasi-mandate contract is the presence of “breach of the duty of care.” It questions whether the vendor faithfully performed their duties as a professional.

On the other hand, a contract for work mandates the “completion of the product.” If the delivered item does not match the contract, the vendor will be held responsible. Signing a contract for work in agile development increases risk. Because specifications keep changing, it is easy to dispute the conformity of the deliverables. With a quasi-mandate, it is generally interpreted that the vendor is not responsible for final completion.

2. Lawsuit Risks Vendors Face in Agile Development

First, you must know that few lawyers are familiar with IT. Even the party filing the lawsuit may do so without understanding the development process. Legal fees also tend to be high.

Therefore, the top priority is to avoid litigation. Aim for a resolution through discussion first. However, listed companies and other organizations may be forced to choose litigation from the perspective of accountability.

2-1. Risk 1: Disputes Over Scope of Performance Due to Vague Change Orders

The most common lawsuit risk in agile development is the scope of the contract becoming unclear due to ambiguous agreements on specification changes. This can lead to disputes where the user claims “it should be within the original budget,” refuses to pay additional costs, or demands additional development free of charge.

In agile, it is assumed that specifications will change as development progresses. However, if the initial estimate is vague, the scope of performance under the contract also becomes unclear. This becomes a source of conflict.

Common Dispute Patterns Arising from Specification Changes

• Disputes over the original estimate’s scope: Cases where the user insists, “The additional specifications should also be within the original budget,” and refuses to pay extra.
• Disputes over the evaluation of deliverables: The risk of being required to perform additional development free of charge, claiming, “The product does not meet expectations.”
• Disputes over the existence of outcome-based responsibility: Even if you argue “there is no responsibility for completion” based on a quasi-mandate contract, the court may recognize a certain level of responsibility for results. “Agile = no liability” is false.

In court, the exchanges during development are emphasized. Minutes, emails, and specifications become evidence. From these records, the appropriateness of the work process is judged. The agreement process for specification changes is especially important. Leaving clear records is the best weapon to protect yourself.

2-2. Risk 2: Potential for “Breach of Information Provision Duty”

As an expert, the vendor has a heavy burden of explanation. A particular risk is the “breach of the duty to provide information.” If you fail to explain in advance the possibility of cost fluctuations or the importance of confirming the results of each sprint, you may be held responsible for leaving the user’s misunderstanding unaddressed.

Courts tend to impose a heavy duty of explanation on the vendor, who is the expert. In agile development, the following points are particularly prone to dispute:

Specific Explanations Required of the Vendor

• Did you explain the agile process beforehand? Specifications are fluid. You must explain to the user that costs and timelines may change.
• Did you get “acceptance” for each sprint’s results? A mechanism to get clear acceptance confirmation from the user for each sprint’s deliverables is essential. Leave evidence of this agreement.
• Did you leave the user’s misunderstanding unaddressed? If you feel the user misunderstands the process, you must actively resolve it. If left unaddressed, it risks being judged as the vendor’s responsibility.

2-3. Risk 3: Loss of Trust Due to Negligent Progress/Issue Sharing

“Transparency” is critical in agile development. Neglecting to share progress or problems erodes trust with the user and increases dispute risk. If a serious problem is discovered late in development, it is more likely to be seen as negligent progress management and a breach of the vendor’s duty of care.

While “transparency” is key, trust can be lost in the following situations, leading to conflict:

• Is the completion report just a formality? If sprint completion reports become purely formal, a gap in understanding between the vendor and user will grow.
• Did you fail to share bugs or technical constraints? Bugs found during development should be shared early. If the report is delayed and the problem becomes serious later, the vendor’s responsibility will be questioned. It is important to explain transparently, at an early stage, why it is difficult to grasp the man-hours.
• Did you ignore the Product Owner’s (PO) lack of understanding? If the user’s PO does not understand agile, the vendor must not ignore it. You may be seen as having encouraged the misunderstanding. Do not placate them; state what needs to be said clearly in the minutes.

3. Required Documents and Countermeasures in a Lawsuit

3-1. Evidence Deemed Critical in Court

In court, contracts and specification documents alone are insufficient. The judge is not an IT expert. Therefore, the “development records” themselves—such as work reports, backlogs, and source code analysis that concretely show the appropriateness of the work process—become the most critical evidence.

In a lawsuit, contracts and specifications are not enough. Work reports, backlogs, and source code analysis will be requested. You must show the judge what the vendor did in an easy-to-understand manner.

However, judges are not IT experts. Many are not even familiar with terms like “agile” or “source code.”

3-2. The Importance of Preserving and Backing Up Development Materials

The biggest risk is having no evidence on hand. This is especially true if development was done in the user’s cloud environment, which may become inaccessible after the contract ends. In preparation for a dispute, you must preserve backups of work records and development environment materials internally.

The biggest problem is having no development materials at all. This happens when you develop in the user’s cloud environment and have no records on hand. Always back up your work records in preparation for disputes. Without materials, you will be at a severe disadvantage in court.

3-3. Gaining an Advantage in Disputes by Cooperating with Experts

Even if you have evidence, you will be at a disadvantage if the judge does not understand the validity of the development. Engineers should not just “dump” materials on their lawyer, assuming “they’ll get it.” You must work with an IT-savvy lawyer and patiently explain the development history. Early consultation also helps avoid litigation.

After gathering evidence, you must compile it into a report that is easy for the judge to understand. Engineers tend to hand everything over to their lawyer, thinking, “This should be enough.” This mindset is extremely dangerous.

Only the parties involved know the background and history of the development. Conversations between developers are usually incomprehensible to third parties. This is true even for external experts.

Engineers must patiently explain the appropriateness of the work to their lawyer. Due to the information gap, the judge is not necessarily on the engineer’s side. It is crucial to always be aware of the risk of disputes and prepare for them. And consult with a lawyer who is strong in IT as early as possible. This increases the chance of avoiding a lawsuit altogether.