What are the Legal and Contractual Issues Surrounding Agile Development?

There are methodologies for advancing system development. The most classical and common is the Waterfall model, and many legal books dealing with system development also discuss based on this model. In this article, we will explain the legal issues related to system development based on the Agile development model, which is difficult to obtain information from books and other sources.

Agile Development Model and Legal Affairs

What is a Model in System Development?

In system development projects, there is something called a development model, which serves as a framework for understanding the overall progress. The most representative of these is the so-called “Waterfall Model”. This model is similar to a waterfall, where water flows from “upstream” to “downstream” in one go, and involves completing each stage of requirements definition, design, implementation, testing, etc., in one fell swoop. The aim is to minimize backtracking and duplication of steps, making it a suitable approach for systematically advancing work.

On the other hand, the Agile development model involves repeatedly implementing small programs and testing them. Through this iterative process of implementing and testing small programs, a larger system is gradually built. For a more detailed explanation of these system development models and a comparison of the merits and demerits of both development models, please refer to the following article.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Characteristics of the Agile Development Model

The major advantage of development using the Agile development model is the ability to quickly get into the actual work. Because the “upstream” tasks such as requirements definition and design document creation and the implementation of the program are not separated, it is suitable for flexibly steering the project, including responses to additions and modifications of functions and changes in specifications. From a legal perspective, the key to successfully guiding the Agile development model is how to manage documentation and change. In the Agile development model, roles and responsibilities are not as clearly divided as in the Waterfall model. Also, because it is a method that emphasizes “speed” to execution rather than “management”, it is prone to incomplete design documents, specification documents, and minutes.

Furthermore, in relation to change management, the Agile development model is smooth in responding to changes, but there is a risk that the project may go up in flames as a result of bypassing the approval process for decision-makers and responding to specification change requests at the field level. If this happens, the merit of the development model, which is “smooth in responding to post-change”, could itself become a risk of project combustion.

Document and Change Management in Agile Development

The Importance of Document Management

In development projects based on the Agile development model, a legal concern is that verbal exchanges accumulate, leading to a lack of documentation. We have detailed why document management is important in system development projects in the following article.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

In the article, we explain the importance of document management in system development projects from two perspectives: pre-dispute prevention (i.e., “preventive legal affairs”) and evidence preservation in the event of a dispute (i.e., “crisis management”).

Establishing a Communication Council is Effective for Document Management

When adopting the Agile development model, unlike the Waterfall model, there is no clear plan prepared in advance. Therefore, it is not enough to simply manage the deviation between the plan and the actual results, and there is a concern that costs will inflate both financially and time-wise if left to the field.

Therefore, it is effective for the person in charge to hold regular communication council meetings to ensure the smooth progress of the project. In the case of small-scale development, it is indeed often preferred to gather the responsible parties as needed rather than holding regular communication council meetings. However, in the case of the Agile development model, there is a greater risk of missing timely issues in meetings. Therefore, it is safe to include regular communication council meetings in contracts and other documents. The method of stipulation is shown as follows in the METI Model Contract.

(Establishment of Communication Council)

Article 12 Party A and Party B shall hold a Communication Council to discuss the progress of the project, risk management and reporting, joint work and the implementation status of each party’s assigned work, confirmation of the contents to be included in the system specification document, discussion and resolution of issues, and other necessary matters to ensure the smooth execution of the project until its completion. However, (omitted in the middle).

2. The Communication Council shall be held regularly at the frequency stipulated in the individual contract, and in addition, it shall be held at any time when Party A or Party B deems it necessary.

3. The Communication Council shall be attended by the responsible persons and chief persons in charge of both Party A and Party B, as well as those whom the responsible persons deem appropriate. In addition, Party A and Party B may request the other party to have persons necessary for the discussions at the Communication Council attend, and the other party shall comply with this request unless there are reasonable reasons.

4. Party B shall prepare and submit a progress management report in a format separately agreed upon between Party A and Party B at the Communication Council, and shall confirm the progress status based on the progress management report, the presence or absence of delayed items, the reasons and countermeasures for delayed items, the need for changes in the promotion system stipulated in this chapter (changes in personnel, increases or decreases, changes in subcontractors, etc.), the status of security measures, the presence or absence of reasons for changes in the individual contract, the contents of the reasons for changes in the individual contract, and other matters as necessary, and shall confirm the decided matters, matters for continued consideration, and the schedule and parties for consideration in case of matters for continued consideration. 

(Items 5, 6, and 7 are omitted.)

The key point is that the existence of the Communication Council is given a certain legitimacy in the contract clause, and it is given a different meaning from other ad hoc meetings.

Path to Utilizing the Communication Council for Change Management

In Agile development, it is a premise that matters agreed upon by both parties initially will be changed afterwards. Therefore, how to manage the situation of post-hoc specification changes is also very important.

At this time, if the Communication Council is held regularly, the method of change management will be very smooth. For example, change discussions are held at the Communication Council, and if one party requests a change discussion, the obligation to respond to the discussion is included in the contract. (The following is an excerpt from the METI Model Contract.)

(Change Management Procedure)

Article 37 Party A or Party B, when receiving a change proposal from the other party (omitted in the middle), shall deliver a document (hereinafter referred to as the “Change Management Document”) containing the following items to the other party within ○ days from the date of receipt, and Party A and Party B shall discuss the acceptability of the change at the Communication Council stipulated in Article 12. (The items to be described are omitted)

The points of the above provision can be organized as follows:

• The method of accepting change requests is unified in the format of a “Change Proposal”.
  
• A deadline is set for the date from the receipt of the proposal to the discussion on it. → It can also be replaced with words such as “promptly” instead of “within ◯ days”.
  
• The place for discussing the acceptability of changes is unified in the “Communication Council”.
  

In other words, to prevent misunderstandings such as “I made a change request, I didn’t,” “I responded to the change, I didn’t,” the procedure is clarified.

Understanding the Duty of Good Faith and the Principle of Trust

So far, we have introduced model contract clauses related to “communication councils” and “change discussions”. However, it is important to understand the essence of these matters, such as the “duty of good faith” and the “principle of trust”. The Agile development model, in particular, tends to be difficult to proceed without a trust relationship between the ordering party and the contractor. This is because it prioritizes the speed of starting actual work, and the procedures leading up to the start are usually minimized. Therefore, it is common in practice to include clauses imposing a “duty of good faith” on the other party.

Article 4, Paragraph 3: In the change discussion, the parties shall sincerely discuss whether to make the change, considering the subject of the change, the possibility of the change, and the impact of the change on the price and delivery date.

This is to prevent a sudden betrayal of the other party with a formalistic legal argument, such as “whether or not to agree to a contract change is solely at the discretion of the party receiving the request, and there is no obligation to comply with the compulsion”, in negotiations that have been proceeding on the basis of an initial trust relationship. This also reflects the principles of law that apply to transactions between private individuals, not just system development.

Article 1, Paragraph 2 of the Japanese Civil Code

The exercise of rights and the performance of duties must be carried out in good faith and sincerity.

The law does not necessarily prioritize the “contents of the contract” or the “wording of the articles” that are formalistic. Especially in transactions with the other party, it should be used flexibly while incorporating substantial “trust” and “sincerity”. In addition, we have detailed explanations in the following article about the point that the “duty” imposed by law is not necessarily based on the procedure of “contract”.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Summary

In system development projects based on the Agile development model, it is of course important to understand the risk of administrative procedures and management systems becoming haphazardly sloppy. However, not only that, it is also considered important to understand the flexible personalityistics inherent in the law, such as the ‘principle of good faith’, and to adopt an attitude of utilizing them in practical work.