IMPLEMENTING CONTINUOUS CODE QUALITY FOR CODE QUALITY DEVELOPMENT IN THE SCRUM TEAM

There are challenges and drawbacks that will be faced in implementing a Scrum method. One of the problems is in Code Quality because the team only has a short time in each sprint. This causes the team to not be able to conduct a thorough code review, resulting in the team having to increase their workload and pressure. Code review is necessary to identify defects in the code before it goes into the core of the project. But the cumbersome, time-consuming and labor-intensive nature of code review causes a barrier in adopting code review practices properly. To simplify and speed up code review, the researcher will try to implement Continuous Code Quality (CCQ) with the Scrum process by conducting empirical experiments. By examining the effect on the speed of the process and knowing the point of view of the development team. Based on the experiments conducted, the CCQ automation system helps the development team in speeding up the code review process and maintaining good code quality. The biggest influence on the speed of the process remains in the complexity of the system built in a running sprint. Even with an automated code review system, a manual code review process is still needed to ensure there are no errors that cannot be detected by the automated system.


I. INTRODUCTION
mplementation of the Scrum method has many advantages in teams [1]. Some of them are improving communication between team members, improving product quality, and being adaptable to changing requirements as the software development process progresses [2]. However, there are challenges and drawbacks that will be faced in the implementation of the Scrum method [2] [3]. One of the issues is in the Code Quality [3]. In the Scrum process, teams only have a short time in each sprint because Scrum demands speed in the process of each sprint [4]. This prevented the team from conducting a detailed code review, resulting in additional workload and pressure on the team [3]. Therefore, the Code Quality of the developed product decreases and produces critical problems, such as the program is not easy to maintain [3].
Code review is needed to identify defects in the code written before it goes into the core of the project [5]. But the complicated, time-consuming and labor-intensive nature of code review causes a barrier in adopting code review practices properly [5] [6]. To simplify and speed up code review, Carmine, et, al., [7] outlined the Continuous Code Quality (CCQ) method to address code quality related issues in general and speed up the code review process. In the study conducted by Carmine, he explained how CCQ works in general. CCQ provides analysis results related to the code quality of each build performed. From the results of the research conducted, it was noted that many practitioners rarely inspect code quality. And projects that use automation processes such as Continuous Integration, it is noted that not many practitioners conduct code inspections in every build process carried out. I Vipin [6] explained that code review can improve code quality but at the same time the code review process requires significant human labor. Vipin created Review Bot by combining several static analysis tools to perform code review automatically and conducting empirical studies. Based on the study conducted, integrating static analysis tools with the code review process can improve the quality of code review by finding issues in the source code automatically.
Reinhold et al [8] describe the Code Quality Monitoring Method (CQMM) which is similar to the CCQ method with the difference being in the monitoring process. CQMM is a systematic approach to assessing and improving the code quality of software products in the ongoing development project process. CQMM is extended with the idea to measure, evaluate and improve code quality continuously by automating repetitive processes.
The implementation of Scrum according to the Scrum guide [8] does not indicate any CCQ practices. Based on that, this research will focus on adding CCQ practices to the Scrum process and see the effect of CCQ implementation on Scrum and velocity in each sprint along the software development process by using planning poker as a way to collect story points. The research will be conducted empirically through a case study experiment in the software development of the Clinical Information System to answer the following Research Question:

II. RESEARCH METHOD
The research will be conducted empirically by raising a case study of creating a clinic information system using the Scrum and CCQ methods. The creation of a clinical information system was raised based on a case study in research conducted by Topan in the Sam Ratulagi Air Force Hospital [9]. The research will begin by conducting 2 phases of system development and continue with interviews with the development team regarding their experiences during the experiment. For the first phase, system development will be carried out using the scrum method in general [10] and will try to implement Modern Code Review(MCR). MCR is a lightweight process that involves few formal rules, a tendency to add support tools, and strives for more efficient and less time-consuming reviews [5] [11]. The first phase will be conducted for 4 sprints with each sprint running for 1 week. This needs to be done so that the perception of the development team has the same point of view and experience in conducting code review and the scrum process. MCR will be done asynchronously when the development team submits a pull request and will be checked by another development team [11], so that modern code review can be done at any time during the sprint [5]. The results of the code review will be revised in the next sprint if the current sprint time has been finished.
The second phase will develop the system using Scrum and replace the modern code review process with the CCQ automation process. CCQ is a continuous code inspection process by performing static/dynamic code analysis on every build performed, as a way to ensure code quality [12]. The second phase will be conducted for 4 sprints with each sprint running for 1 week. CCQ will replace the code review process with an automated system that will run with certain rules. The concept of CCQ implementation in general is mapped in fig. 4. below [7]:

Fig. 2. CCQ Automation System Flow
CCQ has the same concept as practical Continuous Integration (CI), so to implement CCQ, a development pipeline consisting of a repository, CI build server, and CCQ service is needed [7]. To run CCQ, the development team will make a merge request to the remote repository. The remote repository must be connected to the CI service to perform automatic builds. In CI service, special configurations can be made to connect with CCQ service to perform code review. The CCQ service will continue the process of the CI service by measuring, analyzing, and determining whether the received code meets the desired quality criteria. The good or bad results analyzed in the CCQ service will be stored as historical data and will be continued back into the CI service which produces the status of the build performed.
As the experiment phase continues, story points will be recorded in each sprint planning using planning poker to see the effect of code review on the scrum process using velocity charts [13][14] [15]. The determination of the story points score in the planning poker process is determined by considering all the efforts made by the development team [15], which is the effort in conducting code reviews and building applications during the sprint. Planning poker and story points are not a part of the Scrum framework [13]. Scrum framework only provides rules and freedom in estimating [13].
After the experiments have been completed, interviews were conducted with two development teams with the aim of knowing the response and perspective of the experiments that have been carried out by the development team. The interview questions directed the development team to give their opinions regarding the comparison of speed and effort made during the experiment.

A. Velocity Chart
Quantitative data was obtained from the results of estimating story points during the experiment using planning poker and formed into a velocity chart. The results showed significant fluctuations in the middle of the sprint due to under-estimation, unfulfilled commitments and hidden complexities [13] [16]. The development team has committed to a task and during the sprint process it is discovered that the work at sprint 4 to sprint 5 is too simple and at sprint 6 to sprint 7 the work is too complex.

Fig.3. Story Point Results in Velocity Chart
The overly simple work in sprint 4 and sprint 5 occurred due to an inappropriate estimate. The development team has committed to a sprint by assuming that the work is within the capabilities of the development team. After the development and actual story point data collection, there was a significant decrease according to the graph listed in Fig. 5 because the tasks performed were the development of features that were relevant or almost the same as the features that had been built in the previous sprint, resulting in the development team completing the work tasks faster and long before the sprint review activities were carried out. Whereas in sprint 6 to sprint 7 there was a significant increase in story points due to overly complex work. The development team is faced with working on new features that have never been created before, so when taking story points there is an increase in story points and work that has not been completed in sprint 6 will be continued in the next sprint which results in sprint 7 experiencing an increase in story points. To handle these problems, a scrum master is needed to be more descriptive, more active in communication with the team, and can direct the project more precisely and correctly.
. RQ1: What effect does associating Continuous Code Quality practices with Scrum have on the velocity of each sprint?
Based on the results of quantitative data obtained from the experimentation process, RQ1 can be concluded that the biggest influence on the speed of the process in a sprint remains in the complexity of the work performed. The CCQ process still affects the speed of the code analysis process before the system is released into production. This is proven in the data comparison between Table. I and Table. II which shows the comparison of the time required in the code review process carried out by Modern Code Review and using Continuous Code Quality (CCQ).

B. Interview
Before the interview was conducted, the researcher designed 5 interview questions to find out the point of view of the development team during the experiment.

Q1
What are the factors that make the work in a sprint hard?

Q2a
How is the velocity and effort in the modern code review process running in sprints 1-4? Was there an increase/decrease in code quality management?

Q2b
How does the modern code review process affect the effort put into a sprint in general? Is there an increase or decrease in terms of effort?

Q3a
How do you feel about the speed and effort of the automated code review process with Continuous Code Quality that runs in sprints 5-8? Was there an increase/decrease in code quality management?

Q3b
How much does the automated code review process affect the effort put into a sprint in general? Is there an increase or decrease in terms of effort?
The interview questions will be used in interviews with two development teams who have the backgrounds and tasks shown in Table. IV. Interviews were conducted individually with an estimated time of 1 hour. The interviews were recorded with the permission of the development team and will be used for analysis in the research results. The results of the video recording will be transcribed in text form and will be analyzed inductively to clarify the results and analysis of the research [17]. in the context of code review, the task is heavy but not too heavy (P1.Q1) checking thoroughly is not an easy activity (P1.Q1) It is directly proportional to the effort required because exploration is still needed to conduct code review as well as checking line by line carefully during code review (P2.Q2a). Effort CCQ So the effort put into code review decreases. (P1.Q3a) There is a significant reduction in effort, eliminating the need for manual checking and making the process much faster. (P2.Q3a) there is a decrease in code review effort, because it has been assisted by an automated system (P2.Q3b) there is a decrease in the effort to do code review (P1.Q3b) The velocity of Code Review

MCR Velocity
Regarding the speed in code review, it is not so long because I am used to and know the writing style of P2 Then, the effort began to decrease because they already knew and were accustomed to how the framework worked so that only a general review was carried out without having to learn again. (P1.Q2b) there was a general increase in effort at the beginning of the sprint, then there was a decrease in effort because the intensity of exploration to help code review began to decline (P2.Q2b).

Effort Sprint with Continuous Code Quality
There is an increase in effort because there is a new feature development that has never been made. So that learning is needed to help review and provide solutions to P2 (P1.Q3b) there is a decrease in the effort to do code review but there is an increase in general effort due to research or exploratory factors (P1.Q3b) There is a decrease in code review effort, because it has been assisted by there is a decrease in the effort to do code review but there is an increase in general effort due to research or exploratory factors (P1.Q3b) Quality in code improves

Code Quality
With code review, P2 experienced quality improvement in its code structure. (P1.Q2a) With the code review, the quality of the code that I write becomes better. (P2.Q2a) There is always an increase in code quality management. (P1.Q3a) There is an increase in code quality management, as the system automatically shows and suggests improvements. (P2.Q3a) RQ2: How does combining Continuous Code Quality practices with Scrum affect the performance of the development team?
Based on the results of qualitative data and analysis conducted in Table. V, it is found that the effort in sprints in general is more likely to be explorative of something new. Knowledge and experience in the tools used by the development team to be reviewed affect the effort in conducting code reviews. The more familiar the reviewer is with the language and tools used by other development teams, the easier it is for the reviewer to do a manual code review, and vice versa. However, with the automation of code review, the burden on the development team to conduct code review becomes lighter and the team can focus more on the system development process.
"Even with an automated code review system, there is still a need for manual checking to ensure there are no errors that cannot be detected by the automated system. (P1)" Using an automated system like CCQ will not be enough to cover all the flaws that can be found in the code structure. Such as code efficiency, code consistency, and code components that should be reusable cannot be analyzed automatically so manual review is required.

IV. CONCLUSION AND FUTURE WORK
In this research, an experiment has been conducted to try to use the CCQ automation method into the scrum process to determine the effect from the perspective of the development team. Based on the results of quantitative and qualitative data, CCQ has a positive response from the development team. With a system that can perform detailed checks, the development team can focus more on system development. However, a manual code review process is still needed to check the code structure such as checking code efficiency, code consistency, and code consistency.
By automating the process using CCQ, the code review process becomes faster than the manual code review process. But in the context of overall speed, the speed of the process within a sprint is still dependent and fixed on the complexity of the work done in that sprint.
This research was conducted with a development team consisting only of students. So that for further research it is hoped that this research can be carried out with a team of developers who are more professional in their fields.