Expert Panel on Agile Development (5th)

Overview

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

Event Information

Date and Time:: Wednesday, December 24, 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.

Recommended Patterns for Quality Assurance in Agile Development in Public Sector

Internal quality improvement refers to the improvement of quality that is not directly visible to users, such as the removal of bugs (malfunctions and mistakes in specifications) and the enhancement of security measures. External quality improvement refers to the improvement of the usability of the screen and function and the addition of function based on feedback from users, which increases the value of the product. Thus, quality can be broadly divided into internal quality and external quality. Since the approaches to quality assurance are considered to differ between internal and external quality assurance, they should be discussed separately. Efforts related to quality assurance should also be different in the case of initial development (new development) and enhancement (maintenance and improvement of existing systems), which is a regular release. The priority of quality assurance should be different between internal development and external development, and between initial development and enhancement development.
I feel that the patterns listed in Document 2 (p. 17) have many elements related to internal quality. Although this is off the topic of patterns, it is important to conduct research interviews with people who can use the system widely (UX research), so it should be given higher priority.
Your previous organization strongly recommended user research and testing using user testing guidelines. It is important to establish these guidelines. There is also the issue of how to modify the contract if a problem occurs after the procurement is completed. However, the implementation of user testing should be planned at the initial stage.
Regarding user testing, in waterfall development, testing is almost always done at the end, but in agile development, testing can be done when the UI is more or less complete. The advantage of agile development is that testing can be done on something close to the finished product. Early testing has the advantage of being able to identify and address issues early.
QA to AQ (QA:Quality Assurance, AQ: Agile Quality) is a concept that is often referred to in the private sector. Regarding "Pattern 1: One Team including QA" on page 17 of Document 2, it is considered very difficult when it is accompanied by organizational or system changes. It should be examined based on whether it can be practically introduced as a pattern in government offices.
As an important point, in order to improve the internal qualities and the technical capabilities of the team, it is desirable to assign experts who are well versed in manufacturing near the site and create a system that enables them to notice mistakes at an early stage. There were cases where a team that performed non-local requirements such as performance tests and security tests every day noticed issues at an early stage and improved function. It is also important to create a team that has the spare capacity to perform such tests.
In the "Quality Control Checklist" in Pattern 5 on page 17 in Document 2, it is possible to clarify the required level by including an item such as "Perform all regression tests in each sprint." I think it is possible to organize a team that includes a vendor that matches the technical level required by Digital Agency by reflecting the minimum level of expected values for the qualities required by Digital Agency in the checklist.
The quality may be improved by combining "Pattern 1: One Team including QA" and "Pattern 2: Quality Sprint" described on page 17 of Document 2 so that a person in charge of QA joins the team and designs the comprehensive test and the user test in the quality sprint.
It is desirable to add a testing specialist as a person in charge of QA. It is ideal to make a proposal from the design stage and design based on it. Although there are QA persons on the contract company side, there is no image of them being on the ordering side.
One idea might be to include in the procurement requirements a requirement to assign a QA person to the development team.
If you don't have the right people on the development team, you may have to go outside. It's easy to follow Pattern 2: Quality Sprint on page 17 of Attachment 2, but if the quality sprint comes later, it might be better to do it later. You need to think about how to prevent it from happening.
It is also important to have people such as domain experts who have deep knowledge in specific business areas. Since public services and systems are complex, they cannot be covered by vendors alone. It is important to have human resources who are familiar with them because there are many transfers in government offices, and if the person in charge is not familiar, it will lead to omissions in specifications and tests.

Agile CoE Operationalization in Digital Agency by function, Roles and Phases

We generally agree with the outline summarized in Document 2, p. 24. One of the roles we look for in "change management" is to promote good practices in agile development.
Agile CoE is not limited to practical abilities. It is a group of people with motivation = human resources called champions. In order to spread it to many people, people with enthusiasm are desirable. We have no objection to the contents of the material (P. 24) for function.
Another requirement for the Agile CoE is to have expertise. In addition, it is desirable to have people who have practical abilities in each department across departments, and who are satisfied with agile development and can act independently. In my experience of supporting companies that want to develop the Agile CoE in the private sector, I find it very difficult to find people with both enthusiasm and expertise.
Both full-time and part-time patterns of Agile CoE organization are envisioned.
In the context of knowledge management, the Agile CoE also incorporates feedback from the field to update the checklist.
The roles of "Agile CoE" and "Responsible for Agile Governance and Knowledge Management" in the document are assumed by staff in Digital Agency, but considering that there are many transfers, it is difficult to assign a person who is familiar with agile development as a responsible person every time. Scrum Alliance (a non-profit organization established in 2001 for the purpose of spreading Scrum) is a similar organization, and it may be helpful in terms of organization.
Since there is a lot of turnover in government offices, one idea is to hire a private business operator as a person in charge. In addition, human resource development such as training is different from accompanying support, and it can be done without expertise in agile development, so it is considered that the person in charge can be divided. It is best to be enthusiastic about human resource development such as training, but even if there is none, it seems to be possible if roles and KPIs are clarified. It is also possible to hire an external lecturer for training.
Since accompanying support requires expertise, it would be realistic for general staff to be in charge of training as a default but also be in charge of accompanying support depending on their skills and experience.
Regarding "(C) Operation of CoE according to the Agile development maturity level phase" on page 25 of Document 2, it is hypothesized that a system will be established for each higher phase. However, it is necessary to communicate the effectiveness of Agile development and clearly establish organizational goals at the stage of creating a roadmap. The time base and number of people for the hypotheses depend on how the roadmap and the Digital Agency set goals.
As a method to establish a system step by step in a project of a private company, the same phase theory was used. It is also important to publicize and spread it, and public relations should be emphasized in the project expansion phase.
In the adoption and retention phase, when agile development becomes the norm, it is resolved in an evolutionary way, but when it becomes the norm, the quality of the team tends to decrease. I think that a support organization for the team is necessary.

System Auditing in Agile Development

Sprint planning, demonstrations, decision making, etc. When and by whom decisions were made was recorded so that it can be seen later. In particular, it is important that decisions are linked to contracts including specifications. Decisions are made from the perspective of governance, but it is also useful when undergoing system audits.
There is not much need to do a special response to a system audit in agile development, and basically there is no problem as long as the trail of what has been done throughout the project is maintained as a document and the work is done properly to make Scrum function.
In the agile development business of the organization I belonged to in the past, I asked the business operator to leave a trail of everything that was implemented through the project (how to create and update the product backlog, etc.).
In response to a major change in decision-making, a model contract for non-waterfall development issued by an external organization stated that the "Liaison Council" should keep minutes of meetings and agreements between the two parties, and they were carried out accordingly.

Greater than or