Expert Panel on Agile Development (6th)

Overview

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

Event Information

Date and Time:: Thursday, January 8, 2026, from 10:00 a.m. to 12:00 p.m.
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.

Points in Large-Scale Agile Development Practices

In the review meeting so far, we have discussed that it is difficult to develop a product owner (PO) and that agile development does not work easily even if the development scale is small (it does not mean that agile development works well if the development scale is large). We cannot help but think that it is difficult to introduce agile development even in the case of large-scale development conducted by multiple teams in cooperation. If we adopt the discussion of large-scale development, it is desirable to first summarize the necessary requirements and conditions in a step-by-step manner, such as a roadmap for large-scale development.
It is important to design the contact points between teams and the interfaces in the system to be simpler and as few as possible to create a structure that is easy for each team to move. Like "Conway's Law," it is desirable to design the structure of the team and the loose coupling of the system as much as possible.
It is a difficult task for PO whether multiple teams are oriented in one direction. Isn't it important to proceed while being aware of the product goal with everyone?
In order to create a large-scale system, there are many points that need to be considered from a broader perspective than the Architecture of the entire system (system design), etc. In the case of agile development, it is necessary to have a practical perspective such as who will take charge of the entire Architecture.
Since the activities will span multiple teams, it is important to have an overview of the flow of information so that the scope of impact can be understood. The technical consistency of each team is also important, and the selection of technology and examination of Architecture should be decided in advance.
We believe that the combination of team units and contract procurement units may be a problem. If teams are divided for each system and orders are placed in installments, the locus of responsibility will be unclear and confusion will occur. In addition, if multiple business operators participate across teams, it is necessary to organize the locus of responsibility at the contract stage.
In a private company, for example, when building an EC system, if Scrum teams are loosely coupled, the front-end Web services of the EC site and the back-end data analysis infrastructure are ordered separately for agile development. As data flows between the two as loosely coupled, they cooperated in agile development, such as conducting tests on both sides while paying attention to the increase and decrease of data. The two teams had one person responsible for the project and one PO for each team, and had opportunities for the POs to talk to each other on a regular basis. When ordering, due to different technical elements, each team promoted agile development while paying attention to the flow of data and taking into account the differences in individual services and users, while placing orders to businesses in their respective fields of expertise. In addition, in order to maintain a state in which teams could cooperate with each other, each PO created a backlog and made a request. Although it was not specified in the contract, they told them that they would cooperate during the test and that they would cooperate appropriately including the scope of technical impact.
Regarding the sharing of project examples, in the system of the project I am currently involved in, more than one company is involved in the system part, and all teams are composed of more than one company. The team composition varies, but while a team in which one company is more than a majority is fast to start up, problems may occur if it does not match with the management side or the domain being created. In addition, there is a concern for the management side that they have to do a regular meeting with many companies when they hold a monthly regular meeting. The contract does not state matters regarding cooperation with other companies or team cooperation. It is important to have a mechanism for horizontal cooperation in which teams (between domains) regularly cooperate and test.
Regarding "Scrum @ Scale," "LeSS," and "Nexus," which are described on pages 14 and 15 of Document 2, Nexus and LeSS are frameworks for advancing the development of one large system by multiple teams, and Scrum @ Scale is a framework aimed at improving the agility of the entire organization. Since the nature of each is different, it is necessary to note the difference when preparing the document.

Assessment of Scrum Teams

When they were working at a private company, they did not measure the velocity (the total value of story point completed by the development team in one sprint) as described in the materials, and they reported the number of releases, deployments, and bugs because they were often asked by management "What is the situation of the team?" They also measured each team's ① development operating hours that lead to improving product value (positive operating hours), ② operating hours that do not lead to product value such as failure response and recurrence prevention measures (negative operating hours), ③ operating hours that are necessary but should be reduced as much as possible such as release work and data collection work (reduced operating hours), and ④ operating hours for regular meetings, etc., in order to show them to management.
In terms of providing justification and reassurance for agile development, the kind of evaluation and reporting that is done depends on what is shown during the development period before the release and what is shown after the release. Since the pre-release period is long, especially for large-scale development, there is a tendency to focus on whether it will be completed by the release date, and it is thought that velocity and story point will be tracked. After the release, it is thought that system utilization rates, etc. will be tracked according to the purpose. These are considered to be necessary indicators for both government agencies and the private sector.
The product is evaluated by having some users use it in the sprint review to measure whether the work time has been reduced, but the content reported to the management seems to be mostly velocity and story point.
It is recommended to clarify the intention to use the word "evaluation" in the document in order to give the impression that evaluation = evaluation of the vendor and give a severe impression. In the case of Agile, it should be used in a non-misleading way so that giving feedback and continuing evaluation can be conveyed as one of the roles of the ordering party.
I don't have much experience in the pattern that people outside the project such as CoE enter the sprint review and evaluate the situation. In the private sector, the product manager and the development manager often reported the situation to the management. On the other hand, there are difficult aspects such as the fact that it is often difficult to convey the evaluation of the vendor by the ordering party. I often held a regular meeting (headquarters meeting) with one or two people from the ordering party, the sales manager of the vendor on the receiving party, and several development leaders, and had frank communication.
For example, a CoE outside the team does not participate in the Sprint Review to make an evaluation. Instead, it is considered to be a timely explanation to stakeholders to solve issues and to form a consensus. Therefore, the expression "evaluation" seems strange.
As a PMO, I have participated in sprint reviews for each team, but I was giving feedback rather than evaluating. It is very important to check the situation as information gathering to give feedback. It is necessary to collect figures, but velocity is difficult to deal with, so when working with multiple teams, it is advisable to state that velocity should not be simply compared to other teams.
Based on the discussion to date, it is considered more appropriate to use the term "feedback" instead of "evaluation."

Agile Development Systems in Digital Agency

In the example where multiple vendors were on the team, there was a regular time for cross-domain communication, but the PO team did not exist clearly. As the roles of the PO team, the PMO was responsible for "adjusting the release plan" and "sharing the development status of each team" in "Roles of the PO team" described on page 22 of Material 2 (Epics are not prioritized). In this example, it was like a PO community, and it was necessary to gather first because there was no purpose and horizontal cooperation was necessary. On the other hand, the PO team was different in that they gathered with a purpose. Originally, I wanted to include the elements of Scrum @ Scale, LeSS, and Nexus as the situations and conditions for gathering with a purpose, but the timing of the start of each team was different, and it was difficult to form a PO team. If it is possible to coordinate the start, it is ideal to create a PO team instead of a PO community.
Diagramming an Agile development structure as a pattern is a bit confusing and difficult, and even a detailed guide with a well-defined function and roles is not very general. Shouldn't we think of Agile development structures only in terms of communication and management requirements?
With the limited amount of material available, it is difficult to cover all aspects of the agile development system in Digital Agency, such as large-scale development and hybrid development. Therefore, it is important to consider how much detail you need to cover.
Successful patterns are not reproducible, but unsuccessful patterns are reproducible. It would be helpful for readers to include anti-patterns such as "This must never be done," and points that must be kept in mind. In addition, in general, it is sometimes written that "There must be one PO" and "Priority must be decided by one person," but there should be concerns about whether it can actually be operated with that. Therefore, I think it will be very helpful for readers and practitioners to include even points such as "There is one PO, but in such cases, such problems are assumed, so it is good to deal with it in this way, but it will be quite difficult."
The expression "large-scale system agile development" may be a mixture of "large-scale system" and "large-scale agile development." Therefore, the expression should be reconsidered.
The role of an expert who is familiar with the business domain such as the legal system is one of the most important roles of a PO. If the PO cannot play the role, it is an idea to include an external expert in the team or as an advisor. It is recommended to incorporate the role of an expert on the business domain into Pattern 1 described on page 21 of Document 2. As a supplement, it is necessary to establish a basis for the determination of the priority of product backlog items because administrative agencies are expected to be accountable.
Since there are many private sector personnel in addition to administrative personnel such as Deputy Director and subsection chief in Digital Agency, it is necessary to sort out how to incorporate private sector personnel into the team. In addition, PO and assistant PO are also assumed to be played by Deputy Director and subsection chief, but they should be sorted out after consultation with Digital Agency because of the heavy workload.

Greater than or