Expert Panel on Agile Development (3rd)

Last Updated:: May 27, 2026

Overview

For an overview of this panel, please refer to Expert Panel on Agile Development .

Event Information

Date and Time:: Wednesday, November 26, 2025, from 15:00 to 17:00
Location:: Online (Microsoft Teams)
Committee members present:: Chair: Mr. Kano, Member: Mr. Sugii, Member: Mr. Okashima, Member: Mr. Sano, Advisor: Mr.

Agenda

Opening
Message from the Chairman
Agenda
- Review of the Previous Expert Panel
- Sharing and discussion of issues and hypotheses
- Upcoming Schedule
Closing and Communication

Material

Summary of the proceedings

The Secretariat explained the review of the previous Study Group and the issues and hypotheses of the current Study Group, followed by discussion. The main opinions of the committee members were as follows.

Review of the Previous Expert Panel Meeting (Constraints Specific to Government Offices (Budget))

When it comes to the question of whether "flexibility of budget is essential" as a condition in agile development, I think we should sort out the fear factor that the scope will expand infinitely.
Specification changes and adjusting the scope of a project's work tend to occur more often in waterfall development. You should get rid of the preconception that agile development is change-intensive.
Agile development in the private sector has led to additional budgets in the past, but not because of it. On the other hand, I have seen inexperienced Product Owners and Contractors fail to make appropriate decisions and take action when problems arise, such as the product not meeting required quality standards, resulting in additional budgets. They need to carefully control the scope of work in the project and be ready to release at all times.
As for other factors that add budget, there are cases caused by misunderstanding between the ordering party and the contractor, and cases caused by a lack of skills of the contractor. To prevent them, the way of writing contracts and specifications is important, and the commitment of the contractor is necessary. The ideal form of agile development is to develop the scope flexibly within the budget.

How to Budget and Estimate Agile Development for Adoption in Procurement

Basically, I think you can use the same estimation method for agile development as you do for waterfall development. First, you need to estimate the overall effort.
It is a matter of how to estimate the number of man-hours. When requesting an estimate from a business operator, although there are changes in the specifications, the expected deliverables are required. In private companies, there are many cases in which estimates are made by organizing the product backlog and adding a buffer of several percent. On the other hand, in the case of quasi-mandate contracts, it is assumed that they will be unit-price contracts, and estimates including unit prices are required. There are cases in which standard unit prices are set in local governments, but if there is a deviation from market prices, it is considered to be a problem.
It is desirable for the project owner to make a rough estimate internally and have the project manager check if there is any discrepancy in the amount, but it is difficult to implement if the project owner does not have anyone with knowledge of agile development.
It may be a good idea to ask a business operator who provides consulting services for project support to organize the product backlog.
In the initial estimation, the product goal and mission vision are necessary, and the project is progressed within the budget to achieve the goal, and when there is a change in the specifications, the How part is adjusted. If the product goal itself changes, I think it should be budgeted again as a separate project. The product manager and product owner are required to have the skills to resolve the goal and reduce it to the backlog.
In order to improve the accuracy of the estimate under a small-amount contract equivalent to requirements definition before making a request for an estimate based on the product backlog, it is ideal to ensure that the same vendor is selected for the two stages of requirements definition and development after requirements definition.
In the case of a small-amount discretionary contract, there are many cases where a minimum viable product (MVP) is determined. On the other hand, there are cases where a contract cannot be obtained even after being involved in the MVP, so it is necessary to devise operations. In the case of proceeding as a bid-type project under a quasi-mandate contract, there is also a pattern of flexibly deciding what to create at the initial MVP stage and then shifting to procurement as usual. In addition, there are cases in Denmark where procurement is carried out after working together for several days to confirm the velocity of the vendor before procurement.
In order to obtain an appropriate estimate, it is important to share the understanding not only with the staff on the site but also with the related departments such as the upper management and the finance department. It is necessary to carefully input what is to be promoted in agile development in advance, and it is necessary to properly explain that the product to be created may change.
Vendors recognize that a product backlog is something that allows them to flexibly change the order of priorities and increase or decrease the number of man-hours, and it is necessary for the procurement staff, the upper management, the finance department, and the vendor to share the recognition of this nature.
As for measures to secure a flexible budget, there is no need to consider it as a major concern because the case where additional budget is required due to development failure can occur not only in agile development but also in other development methods.
It should be understood that in the case of quasi-mandate contracts, the ordering party is responsible to a certain extent and therefore cannot make additional requests to the operator.

Contracts fit for agile development

When adopting the implementation ratio type of quasi-mandate contract, it may be a good idea to clearly state at the time of bidding that the vendor cannot be held legally responsible for the completion of the contract, but that the vendor must make a commitment to the outcome of the contract. In this way, the number of bids from high-quality vendors will increase and the number of procurement options will increase. Specifically, it may be a good idea to have vendors' performance expressed at the time of bidding.
Since there are many similarities between the implementation ratio type of quasi-mandate contract and the dispatch contract, it is good to incorporate it as a reference.
In the case of a contract in an administrative agency, even if it was a subcontract contract, it was actually a quasi-mandate contract when analyzed legally. It is better to discuss all of them together rather than focusing on the form of the contract. In the first place, instead of choosing between a subcontract contract and a quasi-mandate contract, it would be more appropriate to choose a subcontract contract if you are making a product and a quasi-mandate contract if you are outsourcing business, and add elements as necessary.
Regarding settlement, we think that it would be good to stipulate that partial payment should be made for the performance ratio type of quasi-mandate contract, and that the part of the contract should be paid after completion.
There may be a conflict between the close cooperation of the team and the legal requirements. In addition, at the time of the quasi-delegation contract, it is not possible to interview or interview the engineer, so it is considered to be a risk that the technical capabilities of the outsourcing vendor cannot be appropriately identified.
Communication in the field is separated from command and control, and it is considered possible to set certain conditions for vendor selection.
Practically, the vendor manager was placed in the system as a Scrum Master, and the ordering party and the ordered party reached an agreement through a document called Product Backlog.
When comparing the fulfillment ratio type and the completion of results type in quasi-entrustment contracts, the fulfillment ratio type is less costly. Although it differs depending on the location of the risk, in the case of subcontract contracts and completion of results type, the business operator bears the risk, so there is a tendency to set up a buffer. On the other hand, in the fulfillment ratio type, the amount is lower because the ordering party has the risk, but there are cases where it is necessary to take measures such as an additional budget. I understand that in the end, it is a matter of which party has the risk or the buffer.

Inspection (acceptance inspection) under quasi-mandate contract (performance ratio type)

Regarding how to judge whether deliverables, etc. conform to the contents of the contract, it is ideal that the ordering party and the contractor agree on the acceptance criteria and the definition of completion. It is considered that appropriate acceptance inspection cannot be performed unless the ordering party has technical judgment ability and knowledge. Such a situation can be prevented if it is clearly stated at the time of procurement that technical support will be requested from the vendor.
It may be better for the ordering party and the vendor to work together to create the product. The vendor cannot create a product that is not realistic. On the other hand, I think it is a problem that the standards are loose. How about considering the appropriateness of non-local function requirements together with the vendor?
Sprint Review should have enough testing time to be able to test thoroughly including non function requirements.
Acceptance at the end of the contract is determined by the approval of the product owner for each sprint and the agreement on the testing process.
The final decision on whether a product should be reviewed by a third party should be made by the party in charge of inspection, but it is reasonable and an option for the vendor to make a proposal to reinforce the company's deficiencies.
In the case of agile development, the Product Owner determines whether or not the deliverables meet the acceptance criteria 1-2 weeks after the end of the sprint when checking the deliverables, such as how to mark the end of completion. Basically, it is possible to release at that time, but the timing of the release varies depending on the case. There are cases where non function parts and security parts are tested every sprint and released if there are no problems, and depending on the product, they are released all at once after a certain period of time.
As for the acceptance criteria, the vendor would submit a prewritten process for the employer to determine if it was correct. The skill sets of the employer and the vendor were matched early in the engagement.
They even prepared the content of the acceptance test and took the defensive measure of promising the settlement once it was cleared.
The ordering party is required to understand the test plan and the quality assurance plan.
In the case of public administration, evidence and documents are more important than in the private sector. It is not that documents are unnecessary because of agile, and it is important for the ordering party to develop the ability to select vendors with that sense of balance.

Greater than or