Litigation Risks for Vendors in Agile Development and Practical Precautions in Japan – Part 1
Jul 01, 2025
1. Introduction: Legal Landscape of Agile Development in Japan
Agile software development, with its flexibility and adaptability to change, has become increasingly prevalent in Japan. Unlike the traditional waterfall model—which accounts for approximately 90% of projects and is typically governed by work contracts (ukeoi-keiyaku)—agile development accounts for about 10% and is commonly structured as quasi-delegation contracts (jun-inin-keiyaku). This iterative and incremental approach is characterized by not fixing detailed specifications in the initial stages, which allows vendors to respond flexibly to client needs. However, from a legal perspective, this very feature introduces new challenges and risks for vendors.
This note examines, as of April 6, 2025, the litigation risks that vendors may face in domestic agile development projects and practical measures to mitigate these risks.
(1) Challenges Unique to Software Development
Software development is inherently difficult for judges and end-users to fully grasp, which often leads to significant information asymmetry. As a result, even if vendors secure favorable contract terms, courts sometimes side with the user based on the imbalance of information. Some judges may equate software development with construction work, mistakenly believing it to be a self-contained process that requires little user interaction—while in fact, agile development is fundamentally distinct from traditional construction work.
Despite the recent spread of terms like “agile governance,” genuine understanding and correct application of agile principles are still rare. Unlike standardized construction work, software development is highly customized, and once requirements are defined, changes can create significant rework. In waterfall projects, rework is typically to be avoided; yet in agile, stakeholders sometimes mistakenly believe that rework is entirely avoidable, although small rework cycles do still occur.
Moreover, initial estimates in agile projects are inherently imprecise because the scope becomes clearer over time. Clients often provide limited information during the initial phases, leading to frequent “kick-start” situations where more details emerge only after development has begun.
In short, agile projects can become “breeding grounds” for disputes unless the vendor and the client have a mutually compatible working relationship. Short-term agile contracts are often renewed repeatedly, partly so that both parties can assess compatibility and exclude unsatisfactory vendors. For this reason, vendors must meticulously record what has been done and what is to be done, ensure regular payments, and manage client expectations through proactive explanation and project management. This helps address the information asymmetry that is inherent in such projects.
Importantly, while waterfall development is mainly governed by work contracts (ukeoi), agile development is generally governed by quasi-delegation (jun-inin). Nonetheless, vendors must remember that even in agile projects, a significant duty of care (zenkan-chuui-gimu) is imposed; agile is by no means a free pass for liability exemption.
(2) Legal Responsibilities
① Work Contracts (Ukeoi)
A work contract involves one party (the contractor) agreeing to complete a specific work product, and the other party (the client) agreeing to pay for the completed work. Its core feature is the clear obligation to deliver a completed product that meets the agreed specifications by the agreed deadline. Any nonconformity with contractual specifications may result in liability for contractual defects (previously known as warranty liability).
This contract type aligns closely with waterfall development, which proceeds sequentially through requirements definition, design, development, and testing, all based on upfront detailed specifications.
② Quasi-Delegation Contracts (Jun-Inin)
A quasi-delegation contract involves one party (the principal) entrusting a non-legal task to the other party (the agent). The agent’s main obligation is to handle the task with the due care of a prudent manager but not to guarantee the delivery of a completed work product.
Agile development, by its iterative and flexible nature, is generally understood to be closer to a quasi-delegation arrangement. Japan’s Information-technology Promotion Agency (IPA) also recommends using quasi-delegation contracts for outsourced agile development, as this structure better accommodates mid-project changes in functionality or priorities.
(3) Impact of Contract Type
Whether the arrangement is governed by a work contract or quasi-delegation significantly affects vendor obligations and potential legal liability. Under a quasi-delegation contract, the focus is on whether the vendor fulfilled its duty of care as a professional. Legal disputes often revolve around whether the vendor committed any negligence or breach of duty during the process.
By contrast, under a work contract, the vendor is strictly liable for delivering a product that conforms to specifications by the deadline. Since agile development inherently involves changing specifications, using a work contract may heighten the risk of disputes over deliverable conformity. With a quasi-delegation contract, the vendor is generally not responsible for the final deliverable’s completeness but is responsible for properly performing each iteration.
Courts will also consider the degree of information asymmetry between the vendor and the client when interpreting duties of care. If the client lacks technical knowledge, the vendor may be held to a higher standard of explanation and diligence.
3. Litigation Risks Vendors Face
One practical reality vendors must understand is that very few lawyers—even at major law firms—are well-versed in actual coding or agile methods. Similarly, plaintiffs often file lawsuits without fully grasping the technicalities. Legal fees can be significant if billed hourly. Therefore, the first goal should be to avoid litigation altogether through thorough communication and proactive dispute resolution. For listed companies, large settlement payments may trigger a need for formal litigation due to accountability requirements, but for other firms, early conflict management is vital.
(1) Risk 1: Disputes Over Scope Due to Ambiguous Specification Changes
Because agile projects do not fix all specifications upfront, estimates are inherently broad. As the project progresses, ambiguities in scope may give rise to disputes such as:
Scope disputes: Clients may argue that changes are covered under the original estimate and refuse additional payments for extra work.
Inadequate deliverables: Clients may claim that interim or final deliverables do not meet their expectations and demand unpaid additional development.
Rejection of “no results liability” arguments: Even if the vendor argues that they bear no final results liability under a quasi-delegation structure, courts may still find an implied obligation based on contract terms or project history.
Courts will heavily weigh communication records—minutes, emails, version-controlled specifications—to assess whether proper management and consensus-building took place.
(2) Risk 2: Breach of Duty to Provide Information
Courts tend to hold vendors in IT projects to a higher explanatory standard due to their technical expertise. In agile, this includes:
Explaining the nature of agile: Vendors must clearly communicate that agile entails flexible specifications, potential changes in costs and timelines, and the inherent risks involved.
Obtaining acceptance for each sprint: Vendors should ensure clients formally acknowledge and accept deliverables after each sprint, maintaining clear records of this.
Avoiding misunderstandings: Vendors must proactively clarify any client misunderstandings about the agile process or deliverables.
(3) Risk 3: Loss of Trust Due to Poor Progress or Issue Management
Agile development emphasizes “transparency” and “rapid issue identification.” Failure in these areas can damage vendor trustworthiness:
Superficial sprint reporting: If sprint reporting becomes mere formality, misalignments can accumulate.
Failure to share bugs or limitations: Vendors must communicate bugs or technical constraints early; hidden issues surfacing late can lead to liability.
Neglecting PO understanding: Vendors must not ignore gaps in the product owner’s understanding of agile; failing to address misunderstandings can worsen disputes. Meeting minutes should accurately reflect any disagreements.
4. Evidence Required in Litigation
If a dispute escalates to court, a contract, requirements definition, and specifications alone will not suffice. Vendors must present work reports, sprint and product backlogs, and analyze source code to demonstrate what work was done. Judges often lack familiarity with agile concepts or source code, so clear explanations are essential.
A major risk is losing access to development history when working on client-managed cloud environments. Vendors should proactively maintain backups. Without these, the burden of compiling evidence during litigation grows significantly.
Finally, engineers should not assume that lawyers can intuitively interpret technical discussions. Context matters, and external experts may also struggle without sufficient explanation. Vendors must clearly explain their actions and rationale to their lawyers to help judges understand the work’s validity.
In essence, vendors and managers must always anticipate potential disputes and maintain robust documentation accordingly. Early consultation with lawyers familiar with source code and agile practices can prevent costly litigation down the line.
You are welcome to contact us via the Contact Form to discuss and for more information.
