Expert Panel on Agile Development (7th)

Overview

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

Event Information

Date and Time:: January 28, 2026 (Wednesday) 15:00 to 16: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.

Considerations for Accounting Audits and Inspections in Agile Development

Currently, the organization to which I belong is developing a core system. When explaining that work is being carried out appropriately, the president and executives often point out the efficiency of progress, team performance, etc. In doing so, I explain that velocity should not be compared and the concept of story point in relative estimation, but it is often not understood. Therefore, in large-scale projects with multiple teams, it is desirable to be able to compare and explain the story used as the basis for estimation and its size together. Doing so will result in important activities in obtaining budgets and fulfilling accountability. Therefore, I think it is better to separate the numbers used in the field from the numbers to be reported. Matching the story and size means that all teams should set standards with the same story point. For example, when making a purchase on an e-commerce site, even teams that do not make e-commerce sites should match the standards and match the amount of work of each team. As a result, it will go smoothly. This may be a method that is difficult to understand from the field perspective, but from a project management perspective, I feel that appropriate explanations to upper management can be made and costs can be reduced in the end. However, please note that this is not an absolutely correct method.
As in the case explained by another committee member, I had several experiences in returning to the topic of the amount of money and man-hours of the order and proceeding with it. The topic of the velocity of the field and the topic of reporting to upper management and cost effectiveness were discussed separately.
In agile development, if the requirements are not communicated well to the business operator, and the development that was developed in Sprint 1 needs to be corrected, and the development that should have been done in one sprint takes two sprints, there is a possibility that it will be pointed out in an audit, etc. because the records of the sprint are kept.
Not only in agile development but also in waterfall development, it is possible to miss requirements. Therefore, it is one idea to treat them as defects or bugs. Different requests may come out in response to user feedback, and if they are addressed appropriately, they will be able to explain them.
If Agile development is inspected in the same way as the content of work in quasi-delegated contracts, I think there is only qualitative evidence that demonstrates that a duty of care is being exercised.
In the private sector, in order to prove that the duty of care of a good manager is being fulfilled, tasks are assigned to individuals and the history of tickets is kept, so there was no particular problem. In the quasi-delegation contract, since the operation report is conducted on a weekly or monthly basis, the operation status of each member can also be proven. When managing tasks and backlogs with tickets, it is important to keep a record and make it easy to track the work history, such as handing over to Sprint 2 as a new ticket, because if you transfer the unfinished task from Sprint 1 to Sprint 2, you will not know what you did in Sprint 1 later.
As a reminder, it's important to keep bug fixes in the ticket so that you can track your regular task management later.

Preparation items before the start of the first sprint

In particular, in the case of a system with design elements, it is necessary to discuss when to design the activities that should be given priority input. Although the timing of procurement and the status of staff who can be assigned are also involved, it is important to examine the design in advance because work cannot proceed unless the design is decided when a screen is suddenly created. In the case of the organization to which I belong, many of them were no-code, so they focused on team building. If design and Architecture are included, they cannot proceed smoothly unless they are created first. Therefore, it is important to decide the preparatory period and what to do so that team members can start work all at once as advance preparations. Since high skills are required to build the foundation and common parts, the person in charge is carefully selected.
When laying the foundation for team building, senior engineers and architects carried out technical verification, including the preparation of the development environments, while building the buildings. In page 18 of Document 2, it is stated that the preparation period is two weeks, but depending on the team situation, the preparation period may exceed two weeks, so it is necessary to be careful not to let the two week period go by itself.
As preparation, it will go smoothly if the design system is used and the image of the screen and the verification of the Architecture, etc. are completed before the system development. In addition, I think that the risk can be reduced by seeing the actual working thing in the Architecture verification. Based on that, it may be possible to proceed efficiently by working on what is written as hypotheses in Document 2, p. 18. As a preparation example of the inception deck, the tradeoff slider (an indicator to return to when selecting the necessary function in the project) should be included. By doing so, quality problems are less likely to occur.
As with the statements of other members, attention is paid to prevent the risks of standby design of the system. The preparatory period varies depending on whether the development is done in a hybrid or pure agile manner. It may be easier to understand if the preparatory matters are expressed in the form of differences or additions to the conventional process. I think there are preparatory matters that should be required as requirements at the time of procurement, regardless of agile development and Scrum. In the case of agile development and Scrum, it may be better to add examples of preparatory matters on page 18 of Material 2 in a balanced manner based on them.
Although it is possible to create a pattern of successful practices in preparation matters before the start of a sprint, it is important to select an appropriate vendor who can do project planning regardless of whether it is Agile development or not.
Important aspects should be clearly described, and if they are not described, the evaluation should be lowered. If there are absolutely necessary lines (conditions), they should be indicated.
As a supplement to the important perspective that should be shown in the remarks of other committee members, the difference between the inception deck and traditional waterfall development is important, such as what the inception deck is made for and what kind of project risks are eliminated. The inception deck part is done to deepen the understanding of the product goal with the vendor side, and if there is a discrepancy, it will not work well. Unlike traditional team building, the challenge and concern is that closer communication is required. It is better to select important items after judging what should be done for each project's challenges, risks and concerns.
Other than that, it would be good to be able to express it from the perspective of what kind of state it should be before the start of the Sprint. When starting the Sprint, it is important to select and implement means toward the "state in which you can proceed with peace of mind."

Greater than or