Expert Panel on Agile Development (2nd)

Overview

Date and

Friday, November 7, 2025, from 13:00 to 15:00

US>

Online (Microsoft Teams)

Agenda

1. Opening
2. Greeting from the Chairman
3. Agenda
4. Review of the Previous Expert Panel
5. Sharing and discussing issues and hypotheses
6. Future Schedule
7. Closing and Communication

Material

Committee Members Present

Kano Troupe Chairman
Mr. Sugii, Member
Commissioner Okashima
Mr. Sano
Mr. Kimura, an

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.

Regarding "Identifying Constraints Specific to Government Offices (Budget, Quality Assurance, Decision Making, etc.)"

It is better to make a distinction between the constraints of Agile development in government agencies and the constraints that must be observed or the constraints that can be overcome. It is desirable to start discussing what to keep in mind at the budget request stage. In our past experience, when we prepared the service guidelines of our organization, the budget request was not sufficiently described, and we discussed what to do. In addition, I think it is necessary to determine whether or not to adopt Agile development at the time of budget request. (So that staff can properly judge whether the adoption and practice of Agile development methods are effective in the project to be procured) I think time series should also be included in documents such as the "Guide to Standards for Adoption of Agile Development (draft)".
The degree of constraints on agile development in government and public offices varies, and I think that it may be possible to eliminate the risk by showing a new interpretation, or it may be possible to make up for it by operating user organizations. I would like to make a concrete decision when we discuss the relevant issues.
In the past, when collaborating with local governments, there were differences in the budget request method between agile development and other methods. In requirements definition, it is necessary to estimate the value based on user stories. Although the scope of work of the project does not change significantly, there are differences in development methods, so we would like to continue discussing this point in the future.
Even if Agile development is possible, vendors may hesitate to bid or lower the priority because the actual situation is very different from the original Agile development.

Risks and Countermeasures of Hybrid Development Practice of Agile Development and Waterfall Development

I feel uncomfortable with the image of hybrid development in Document 2 (p. 11). I would like the committee members to give us their ideas, including practical knowledge, on which process agile development should be applied. There are various patterns of hybrid development, as there are examples in other countries where hybrid development is applied in the last test release.
Intra-team hybrid, a style that was frequently used in the private sector, is the image of a transition from waterfall development to agile development.
There is a concept of hybrid development in which a part of the same system is created by determining function requirements and another part is created by agile development.
Infrastructure, platform, etc., need to be shaped firmly in waterfall development, while user interface, etc., need to be rotated in agile development.
When technical risks have to be considered, hybrid development within a team (a case of agile development from basic design to integration testing in a V-shaped model) may be possible.
In the case of inter-team hybrid development (when it is necessary to promote development in collaboration and cooperation with other teams, the own team is in agile development, but other teams are in waterfall development), although it is imagined to be linked with other systems, it is necessary to pay attention to milestones in the schedule.
From the experience of the current project and the past hybrid development between teams, the information systems department tried to proceed with waterfall development, but there was a difference in perception with the agile team, and there was a difference in opinion at the time of deciding the interface specifications. However, even in agile development, it is possible to decide the specifications at an early stage and proceed with testing using mock-ups (prototypes). In the end, it is important to be flexible if there are changes during development. However, it is also necessary to note that the level of understanding and risk of the recipient will vary depending on how the guidelines are written.
There are some parts of the project that are good for agile development and some that aren't, and I think it would be helpful to have practical guidelines on how they can be separated by function.
Regarding "(1) Uncertainties in specifications" in the "Agile development adoption checklist (draft)" (for employees to appropriately judge whether the adoption and implementation of agile development methods are effective in the projects to be procured), when determining the KPI of the system, it is necessary to make continuous improvements even after the completion of function by using the utilization ratio, etc. as an indicator. Uncertainties may be those that cannot be controlled by ourselves.
I think the nuance of "addition / change / removal of function triggered by post-release feedback" is closer to the essence of agile than the uncertainties of "changes in specifications".
I think uncertainty is about making course corrections while exploring what the value is for the user, but I don't think there is the idea of changing something because there is a fixed specification and it is agile development.

Regarding the "Proposed Roadmap for Promoting Adoption of Agile Development"

Part of a large-scale agile framework is the perception that there is a mind-shift from management to the field. On the other hand, I have an impression that there is not much written about contracting, procurement, auditing, and other aspects of the system, and I don't know if it will be helpful.
For the past three years, my former organization has implemented various initiatives aimed at spreading agile development. Among them, there was a roadmap, but the outline is not much different from the sample in Reference 2 (p. 16). The main content was the development of guidelines and rules, and templates for contracts and budget requests. In addition, we are conscious of spreading the effectiveness of agile development to employees who are not familiar with it, and we think it would be good to add this perspective to this roadmap.
The Tokyo Metropolitan Government's "agile type Development Playbook" and the interview results are available for your reference.
By experiencing the effectiveness of agile development, you can change your way of thinking flexibly, such as tolerating risks if the effectiveness is high. It is desirable to promote human resource development on the ordering party's side at an early stage.
This is the same intention as the "team that supports each development team" in the development support system of the organization. However, it is desirable to form a so-called CoE centered on those related to the pilot (the ordering party), including a coach / advisor if necessary.
In administrative work, there is a mindset that it is difficult to make mistakes because taxes are used, so it is not compatible with agile development. However, the ability to place orders and training have become issues recently, and it is also important to promote a top-down awareness reform. When introducing agile development, it is also necessary to train the ordering party, so I would like to see human resource development and training / seminars that can play the role of product owner included in the roadmap.

Greater than or