Available via license: CC BY 4.0
Content may be subject to copyright.
Received: 02-01-2024 | Accepted: 13-05-2024 | Published Online: 22-06-2024
401
Accredited SINTA 2 Ranking
Decree of the Director General of Higher Education, Research, and Technology, No. 158/E/KPT/2021
Validity period from Volume 5 Number 2 of 2021 to Volume 10 Number 1 of 2026
Published online at: http://jurnal.iaii.or.id
JURNAL RESTI
(Rek a yasa Siste m dan Tekn o logi Info r masi )
Vol. 8 No. 3 (2024) 401 - 412
e-ISSN: 2580-0760
Recommendation for Scrum-Based Software Development Process with
Scrum at Scale: A Case Study of Software House XYZ
Ahmad Jalaluddin1*, Eko K. Budiardjo2, Kodrat Mahatma3
1,2,3Department of Information Technology, Faculty of Computer Science, Universitas Indonesia, Jakarta, Indonesia
1ahmad.jalaluddin11@ui.ac.id, 2eko@cs.ui.ac.id, 3kodrat.mahatma12@cs.ui.ac.id
Abstract
Software House XYZ employs Scrum as one of its software development processes. However, the company faces several
challenges in the implementation of Scrum, leading to delays in their product releases. Two specific problems are the control
of a large-scale Scrum team and the management of team commitments. In addressing these issues, the Scrum at Scale
framework has been chosen as a solution. Before implementing Scrum at Scale, an assessment of the current Scrum maturity
level at Software House XYZ is deemed necessary. The Scrum Maturity Model, adapted to the Scrum Guide 2020, is selected
as the method to evaluate how effectively the company is implementing Scrum. A questionnaire comprising 81 practices was
distributed to development teams, with 10 valid responses collected. Based on the assessment using the Scrum Maturity Model,
the current Scrum implementation maturity at Software House XYZ is rated at level 1, Initial. A total of 61 practices are
proposed for improvement in the Scrum process. Scrum at Scale can be implemented once the suggested Scrum process
improvements have been made. These recommendations are structured following the framework outlined in the Scrum at Scale
Guide 2022. Validation of the Scrum at Scale recommendations has been conducted by us through interviews with
representatives from Software House XYZ. From the validation results, the company expresses interest in trying to implement
Scrum at Scale. However, the company agrees to enhance the existing Scrum process within the organization before fully
adopting Scrum at Scale.
Keywords: scrum at scale; scrum; scaling agile method; agile; maturity level
How to Cite: Ahmad Jalaluddin, Eko K. Budiardjo, and Kodrat Mahatma, “Recommendation for Scrum-Based Software
Development Process with Scrum at Scale: A Case Study of Software House XYZ”, J. RESTI (Rekayasa Sist. Teknol. Inf.),
vol. 8, no. 3, pp. 401 - 412, Jun. 2024.
DOI: https://doi.org/10.29207/resti.v8i3.5646
1. Introduction
One of the approaches to developing products and
services is Scrum [1]. Scrum is also a framework within
the Agile methodology. This framework will serve as
the foundation for companies to innovate and create
products or services. Scrum involves processes starting
from Sprint Planning to Sprint Retrospective [2]. This
methodology has been widely adopted by numerous
companies worldwide.
Software House XYZ is a software development agency
founded in 2015. Since 2016 to the present, the
company has been offering boot camps with a case
study-based learning approach, preparing participants
to undertake real project development. Selected
bootcamp participants actively contribute to ongoing
projects within the company.
The company uses Scrum as its software development
process. In each project within the company, there is a
dedicated Project Manager involved from the project's
initiation to its completion. The company maintains the
role of Project Manager even within the Scrum
framework they apply. There is a study that surveyed 97
software practitioners from 31 different countries
regarding the presence of Project Managers in
development teams implementing agile [3]. The
research findings indicate that nearly 67% of projects in
their respective companies involve Project Managers.
The company also has a specialised team, the Principal
Team, comprising selected individuals. In every
project, this team is responsible for elaborating the
jointly designed product backlog with the Product
Owner into a set of tasks within a Sprint. The Principal
Team is also accountable for determining the number of
story points for each task to be undertaken by the
development team. The Principal Team is formed so
that the development team can maintain the quality of
the company's services.
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 402
The development team is expected to complete each
task within the designated time set by the Principal
Team. However, the reality often deviates from the
company's expectations. The story points assigned to
each task by the Principal Team are frequently
challenging for the development team to adhere to,
leading to the necessity of postponing several tasks to
subsequent Sprints. While the development team has
the option to propose changes to the initially assigned
story points, supported by reasons and relevant data, in
practice, such requests are infrequently made and
considered.
One of the projects at Software House XYZ is the
Expedition Application project, which was initially
planned to be completed in 5 months. The company
initially assigned a Scrum team of 12 individuals to
develop this project. However, several issues in the
software development process led to a delayed product
release. The development team managed to complete
the project in 7 months. Additionally, there was an
increase in team members by 8 individuals, resulting in
a total of 20 members in the Scrum team for the
Expedition project. This situation is not in line with the
recommended maximum team size by the Scrum Guide
2020.
Based on the data provided by the company to us,
similar issues also occurred in other projects at Software
House XYZ, such as the logistics application project
and the health application project. The task planning
devised by the Principal Team cannot be effectively
executed by the development team. The company adds
members to the development team during ongoing
development. However, this does not prevent product
release delays; instead, it adversely affects other
projects being undertaken by the additional team
members. The company desires projects to be
completed on time; however, the reality does not align
with the company's wishes. The issue is elaborated in
Table 1.
Table 1. Problem Definition
Expectation
Realization
Problem
Maintaining the company's
development speed
standards is crucial to
ensuring that the delivery
process to clients aligns
with the established
agreements.
The completion
of work
commitments
does not align
with the agreed-
upon schedule.
The product
release is
delayed by
38.33%
from the
initial
planning.
There are other issues present in the company's software
development process. We employed a fishbone diagram
to analyze these problems [4]. The issues were obtained
through interviews with several individuals at Software
House XYZ. In the interview, we asked about the
factors contributing to product release delays. They are
categorized into four domains: people, measurement,
management, and method [5]. They are explained in
Table 2.
Table 2. Problem Domain
Domain
Problem
People
The technical proficiency of some team
members is inadequate.
Measurement
No notification is provided when there are
changes in tasks from the client team.
Changes in task priorities during an ongoing
sprint.
Addition of tasks during an ongoing sprint.
Difficulty in realizing the determined story
points.
Sudden changes in product requirements.
Management
Control over the commitments that the team
needs to achieve in each sprint is insufficient.
The large size of the Scrum team
(approximately 20 people) makes it
challenging for the lead to monitor teamwork.
Method
Product requirements are not clearly described
by the product owner.
In the Management domain, we have successfully
identified two root problems within the company. These
two root issues are the inadequate control over
commitments that the team needs to achieve in each
Sprint and the large size of the Scrum team
(approximately 20 people), causing difficulties for the
lead in monitoring teamwork. One of the Principals
believes that the most frequent hindrance to the
development process is the lack of control over work
commitments by team members. Not all development
teams are proficient in managing their work effectively.
The Pareto principle states that 80% of problems can be
generated from only 20% of the total causes [6], [7]. Out
of all problem domains, the Management domain only
accounts for 22% of the total root causes. However,
based on the data collected by us, issues within the
Management domain have been identified as the
primary problems causing delayed product releases.
Therefore, this research will concentrate on resolving
issues within the management domain.
Scrum is designed for teams of four to ten individuals
[2]. However, teams with a larger number of members
can adopt scaling agile methods [8]. Several previous
studies have shown that the implementation of scaling
agile methods can be applied in various cases across
different companies. From the findings of prior
research, scaling agile methods assist companies in
facilitating information exchange among teams,
enhancing trust among teams, and providing a
framework capable of adapting to the company's
organizational structure [9]. These factors drive many
companies to adopt scaling agile methods. AlMutairi's
study proposes scaling agile methods to enable
companies to distribute large projects [10]. The
compatibility of the selected scaling agile method with
the company's conditions is a crucial factor for the
success of large-scale agile implementation.
Scaling agile methods assist organizations in involving
more people in a team and eliminating silos in
teamwork [11]. Nevertheless, if a Scrum team is unable
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 403
to effectively implement Scrum, they cannot
successfully scale Scrum within the organization [12].
Previous research has shown that Scrum maturity can
be measured using a maturity model [13]. This model
offers recommendations for best practices within
Scrum, enabling companies to enhance the maturity of
their Scrum implementation. An evaluation of the
Scrum process is necessary for a company to ensure its
readiness to scale its Scrum processes. With these issues
in mind, the research questions posed in this study are
as follows:
RQ1: How are the results of the evaluation and
recommendations for improving the implementation of
Scrum for Software House XYZ?
RQ2: How is the implementation of the Scaling Agile
method at Software House XYZ??
2. Research Methods
The approach that can be employed in this research is
the explanatory sequential approach. This mixed
methods approach begins with the collection of
quantitative data. Subsequently, the collected
quantitative data will be analysed. The precise
quantitative approach is appropriate for research that
involves evaluation [14]. The next phase in this
approach involves the collection and analysis of
qualitative data based on the quantitative data that has
been previously analyzed. The collection and analysis
of qualitative and quantitative data in this approach are
interrelated [15].
There are several methods available to measure the
maturity level of a framework. These methods are
referred to as maturity models. Maturity models assist
organizations in assessing team performance,
motivating them to enhance their performance.
Additionally, maturity models help bridge the gap
between clients and service providers [16].
Hidayati's research compares several Maturity Models
such as the Capability Maturity Model Integration for
development (CMMI-Dev), Agile Maturity Model
(AMM), and Scrum Maturity Model SMM [17].
CMMI-Dev has a very broad assessment scope as it can
encompass multiple divisions within an organization.
[18]. AMM and SMM have narrower scopes. AMM
assists organizations in assessing the maturity processes
of teams implementing agile methods in their
development processes [19]. Meanwhile, SMM is
specifically designed for evaluating the maturity
processes of Scrum [16].
We use SMM as the model to assess the maturity of the
software development processes at Software House
XYZ. This choice is driven by the focus of this study on
the implementation of Scrum at Software House XYZ.
Data processing in this research will utilize the KPA
rating.
The questionnaire in this research is utilized to assess
the maturity level of Scrum implementation at Software
House XYZ. The questionnaire is structured based on
the SMM adapted to the Scrum Guide 2020. Figure 1 is
the theoretical framework of this research.
Figure 1. Theoretical Framework
The Scrum teams in Scrum at Scale adhere to the
guidelines outlined in the Scrum Guide. Therefore,
improvement recommendations from SMM will be
utilized for Scrum teams within Scrum at Scale. Scrum
at Scale can assist Scrum teams in addressing more
complex problems [12].
The SMM comprises three stages: Pre-Appraisal,
Appraisal, and Post-Appraisal [16]. The first step is the
Pre-Appraisal. In this stage, we will elucidate the
ongoing research to the participants through a Google
Form. We will explain the formulated problem, the
reasons behind conducting this research, and the SMM
theory. Subsequently, We will present questions via
Google Forms to the participants regarding their
expectations regarding the maturity level of Scrum
implementation that should exist within their company.
The participants are representatives who serve as one of
the Leads in the company.
The next stage is the Appraisal stage, which is the
primary phase of SMM. We formulate questions to be
presented in the questionnaire using Google Forms.
This questionnaire consists of 81 questions organized in
accordance with the SMM practices adapted to the
Scrum Guide 2020. The respondents for this
questionnaire are the development team members from
Software House XYZ.
The sampling method employed by us is Purposive
sampling. Purposive sampling is a technique that relies
on our judgment to select research samples [20]. This
technique has several types that can be utilized in
research, and we opt for the homogeneus sampling type.
Homogeneous sampling is a sampling technique that
requires selected samples to possess specific similar
characteristics. This research gathers data from the year
2023. The selected sample consists of individuals
working with Scrum in teams of no more than 10
people.
The questionnaire appraisal respondents consist of
Leads, Senior Software Developers, Project Managers,
application development teams, and Principals. All
these respondents will fill out the same questionnaire,
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 404
despite having different roles. Project Managers are
required to understand the product to be created by the
client. In this company, the Project Manager serves as
the internal Product Owner for the company's Scrum
team.
Data processing will be conducted using the KPA
rating. In KPA rating, respondents can provide four
answers to the posed questions: "yes," "no," "partially,"
and "not applicable." "Yes" is selected when the
practice is implemented, while "no" is chosen when the
practice is not implemented. "Partially" is the chosen
answer when only some aspects of the practice have
been successfully applied. "Not applicable" is selected
when the queried practice cannot be applied to the
team[19]. Subsequently, the research will calculate
each goal area using Formula 1.
(1)
Yn is a number of "yes" responses, Pn is the number of
"partially" responses, Tn is the number of question
responses, and NAn is the Total "not applicable"
responses. The obtained results will be interpreted into
four assessment levels illustrated in Table 3.
Table 3. KPA Rating Assessment Level
Interpretation
Requirement
Fully Achieved
>85% and ≤100
Largely Achieved
>50% and ≤85
Partially Achieved
>15% and ≤50
Not Achieved
≥0% and ≤15
Next, we conduct a post-appraisal. This stage is the final
step in the SMM. We provide a questionnaire to the
participants to obtain feedback, suggestions, and
critiques regarding the Scrum Maturity Model
Appraisal results. The outcomes of this stage will serve
as recommendations for future research.
Scaling the agile method becomes a solution to meet the
organizational needs by aligning multiple teams and
facilitating developers to connect with other teams
within the company, such as the finance and legal
divisions [21]. Furthermore, scaling the agile method
helps organizations reach more individuals within the
team, eliminate silos in work, and remain competitive
in the current market [11]. There are several scaling
agile methods available today, including Large-Scale
Scrum (LeSS), Disciplined Agile Delivery (DAD),
Nexus, Scaled Agile Framework (SAFe), Scrum at
Scale, and Spotify [22].
All the scaling agile methods mentioned above have
available documentation. In several projects, Software
House XYZ assigns around 20 individuals to a team.
Nexus, LeSS, DAD, and Scrum at Scale are suitable
choices given the company's conditions. These four
scaling agile methods can adopt Scrum.
Projects commence with discussions between the
customer and the team from Software House XYZ,
consisting of the Project Manager and Principal. The
purpose of these meetings is to understand the system
requirements the customer wants to develop. As the sole
team member communicating intensively with the
customer, the Project Manager is required to be
knowledgeable about the product the customer wants to
develop. If the development team has questions about
the product requirements, they can inquire with the
Project Manager.
Among the scaling agile methods described above,
Scrum at Scale is the most suitable framework for
implementation at Software House XYZ. In Scrum at
Scale, each Scrum team has one Product Owner [12]. In
the current framework, the Project Manager can take on
the role of Product Owner if Scrum at Scale is
implemented. The development team can inquire with
the Product Owner in the Scrum team about the product
being developed without having to ask the customer
directly. This is what led us to recommend the use of
Scrum at Scale as the recommended improvement
framework for Software House XYZ.
When the improvements to the Scrum process have
been formulated, we will recommend the software
development process using Scrum at Scale. We have
attended Scrum at Scale courses and studied the Scrum
at Scale Guide 2022 to gain a thorough understanding
of the framework.
3. Results and Discussions
We conducted an interview with the Lead Project
Manager as the company representative. From the
interview results, the company expressed a desire for
Scrum within the organization to reach level 5 -
Optimizing. Through this research, we provide
recommendations for improving the Scrum process to
achieve level 5 Optimizing maturity in Scrum.
3.1 Evaluation of Scrum Process
We distributed the SMM questionnaire to individuals
who have previously implemented Scrum while
developing software at Software House XYZ. There
were 40 individuals with Scrum experience in the
company. Out of these 40 individuals, only 10 applied
Scrum with a team size of no more than 10 members.
The SMM assessment in this study did not collect data
from individuals who had experience with Scrum in a
larger team size. Ten respondents were provided with
the SMM questionnaire prepared by us, and all selected
respondents answered the questionnaire.
We assessed the maturity level for each objective within
the SMM. Subsequently, we compiled a summary for
each goal. The table below presents the summary of the
maturity level assessment for the implementation of
Scrum at Software House XYZ.
The KPA rating for Basic Scrum goals at level 2 was
73.08% (largely achieved), and the KPA rating for
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 405
Requirements Management at level 2 was 75.56%
(largely achieved). The recommended practices are
those with values not exceeding 85%. Currently,
Software House XYZ is at level 1 Initial.
Table 4. Scrum Maturity Level Assessment Results Recapitulation
Level
Goals
Total
practices
Interpretation
2
Basic Scrum (BS)
24
Largely
Achieved
2
Software
Requirements
Engineering (SRE)
18
Largely
Achieved
3
Customer
Relationship
Management (CRM)
7
Largely
Achieved
3
Iteration
Management (IM)
17
Largely
Achieved
4
Standardized
Projects
Management (SPM)
1
Largely
Achieved
5
Performance
Management (PM)
14
Largely
Achieved
Out of the 64 practices that have not yet reached the
'Fully Achieved' status, we propose 61 practices as
recommendations for improving the Scrum process at
Software House XYZ. However, it is noted that three
practices cannot be implemented due to company
policies. The following is the number of practices that
the company needs to implement to achieve each level
of Scrum maturity.
Table 5. Scrum Maturity Level Assessment Results Recapitulation
Level
Number of
Improvement
recommendations
Cumulative Number of
Improvement
Recommendations
2
32
32
3
18
50
4
1
51
5
10
61
To achieve level 5, Software House XYZ needs to
enhance 61 practices, which is an accumulation of
practices at level 2, level 3, level 4, and level 5.
Improvement recommendations start with level 2. Level
3 cannot be achieved unless level 2 is attained by the
company, level 4 cannot be reached without achieving
level 3, and level 5 cannot be attained unless level 4 is
accomplished by the company.
Scrum has several crucial elements, namely Scrum
roles, Scrum events, Scrum artefacts, and Scrum values
[2]. Additionally, Scrum encompasses rules and
techniques that constitute best practices within the
Scrum maturity model. We present recommended
practices grouped into six categories: role, event,
artefact, value, rule, and technique. We present
recommended practices in Tables 6, 7, 8 and 9. Each
table contains recommended practices at Level 2, Level
3, Level 4, and Level 5. The following is a table of
recommendations for improving Scrum implementation
for SMM level 2:
Table 6. Recommendations for Improving Scrum Implementation
for SMM Level 2
Goal s
Categories
Practices Recommendation
BS
SRE
Role
Artifact
Event
Rule
Technique
Value
Rule
An individual is serving as the Product
Owner, not a Project Manager.
There is an individual serving as the
Scrum Master.
Providing knowledge about the role of
the Team (developers) in Scrum.
There is a clearly outlined Product
Backlog.
Release Planning is conducted at least
once.
Sprint Planning is conducted once every
Sprint.
There is a Daily Scrum.
Sprint Review is conducted once every
Sprint.
Sprint Review takes place after the
development process in one Sprint is
completed and before Sprint
Retrospective is conducted.
Sprint Retrospective exists and is
conducted once every Sprint.
A Sprint concludes with Sprint
Retrospective.
There is the appropriate use of Sprint in
accordance with Scrum regulations.
The Daily Scrum is attended by the
development team.
The Release Burndown is updated
according to the progress reported by the
Team.
The Sprint Burndown is updated
according to the progress reported by the
Team.
The Product Backlog is updated by the
customer or Product Owner.
Sprint Review is attended by the Scrum
team and stakeholders.
There is a Release Burndown.
There is a Sprint Burndown.
There is a Product Goal in the Product
Backlog.
The Product Owner has the authority to
determine priorities in the Product
Backlog.
The Product Owner can communicate
directly with the Team (developers) and
Scrum Master.
The Product Owner communicates
directly with stakeholders from the
customer side.
The top Product Backlog Items are
determined based on business value.
Some of the top Product Backlog Items
have already been estimated.
Some of the top Product Backlog Items
are small enough to fit into a single
Sprint.
The Product Owner understands the
objectives of all Product Backlog Items.
The Product Owner participates in Sprint
Planning.
The Product Owner presents the latest
Product Backlog in each Sprint Planning.
The entire Scrum team participates in
Sprint Planning.
The entire team is confident that the
planned work can be completed entirely
within one Sprint.
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 406
Goal s
Categories
Practices Recommendation
The Product Owner is satisfied with the
priorities to be worked on.
There is no artefact category in Table 6. The artefact or
the event category includes practices that state that
Scrum Artifacts or Scrum Events are present in the
software development process of the company.
Meanwhile, rules in the implementation of Scrum
Artifacts or Scrum Events will fall into the rule
category. Then, the Product Goal is one of the
commitments in Scrum. Commitments will fall into the
value category.
Table 7. Recommendations for Improving Scrum Implementation
for SMM Level 3
Goals
Categories
Practices Recommendation
CRM
IM
Value
Rule
Value
Rule
Technique
The Definition of Done is defined and
approved by the entire Scrum team.
The Definition of Done is achieved in the
increment performed in each iteration.
Demonstrating a working product at the
Sprint Review.
Stakeholders and the Product Owner
provide input or feedback on the
conducted demo.
The maximum duration of the Sprint
Review meeting is 4 hours for a Sprint
duration of 1 month.
The Sprint Goal is defined in the Sprint
Backlog.
The Sprint Backlog is updated every day.
The Sprint Backlog is exclusively owned
by the selected Scrum team.
The Sprint Backlog is broken down into
Sprint Backlog Tasks during the Sprint.
The Sprint ends according to the pre-
established schedule.
Iterations that are failing are immediately
stopped.
The team is not disturbed or controlled by
external sources, affecting the team's
work.
The team delivers the product according
to the agreed-upon commitment.
All tasks in the Sprint planning are
estimated.
The Sprint Burndown Chart is visible to
all Scrum team members.
The Sprint Burndown Chart is updated
every day.
Velocity used is only from completed
tasks.
The Product Owner uses velocity in
Release Planning.
The practice of Sprint Goal falls into the value category
because the Sprint Goal is a commitment in Scrum.
Velocity falls into the technique category because
Velocity is used as a performance metric to help the
Scrum team understand how much work they can
complete in one sprint. Other recommended practices
fall into the rule category.
To reach level 4, all practices at levels 3 and 2 must be
implemented effectively. Furthermore, all Scrum teams
at Software House XYZ must adhere to the same
standards in the application of their Scrum practices.
The company should monitor the implementation of
Scrum regularly
Table 8. Recommendations for Improving Scrum Implementation
for SMM Level 4
Goals
Number
Practices Recommendation
SPM
Rule
All projects utilizing Scrum are managed
with the same adherence to all goals,
objectives, and practices from all the
previous levels.
.
Table 9. Recommendations for Improving Scrum Implementation
for SMM Level 5
Goals
Number
Practices Recommendation
PM
Rule
The Daily Scrum is conducted every
working day, at the same time and place.
The Product Owner participates in the
Daily Scrum several times a week (not
necessarily every day).
The maximum duration of the Daily Scrum
is 15 minutes.
The maximum duration of the Sprint
Retrospective is 3 hours for a 1-month
Sprint.
The results of the Sprint Retrospective are
formulated as proposals containing
concrete improvements.
At least some improvement proposals from
the Sprint Retrospective have been
implemented.
All Scrum team members participate in the
Sprint Retrospective.
Overtime is rare, and if it occurs, it is
voluntary.
There is a constructive criticism discussion
within the Scrum team.
The Scrum team conducts experiments
aimed at improving the development
process with Scrum.
The successful enhancement of the company's Scrum
processes is anticipated to facilitate more effective
implementation of the Scrum at Scale processes. Scrum
training is also necessary for the development team of
the company. Some individuals still do not fully
understand how Scrum should be implemented. In
addition, the Project Managers of the company need
training on how to become effective Product Owners so
that the Product Owner role in Scrum can be executed
successfully. Furthermore, some Senior Developers or
Leads can be provided with training to become Scrum
Masters, helping the company ensure that the
development team can effectively implement Scrum.
3.2 Scaling Agile Method Recommendation
Currently, scaling agile methods are not only applied in
IT companies but also in non-IT companies such as
manufacturing firms [9]. The scaling agile method
serves as a solution to organizational needs to align
multiple teams and assist development teams in
connecting with other teams within the company, such
as finance and legal divisions [21]. Non-agile teams and
agile teams can connect with each other to achieve
common goals.
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 407
In Scrum at Scale, there is a team that can be filled by
representatives from non-IT divisions. This team is
called the Executive Action Team and is part of the
Scrum Master Cycle in Scrum at Scale. We include the
Principal team in this Executive Action Team.
According to us, the tasks of the Principals in Software
House XYZ will be assigned to this Executive Action
Team. By including the Principal team from Software
House XYZ in the EAT, you're essentially bringing in
high-level decision-makers who can provide valuable
insights and strategic direction. The Principals can
contribute their expertise in guiding the organization
towards its goals and objectives, ensuring that the
Scrum implementation aligns with broader business
priorities.
Presently, the company employs Scrum methodology
for product development, notwithstanding a team size
that surpasses the conventional 10-member threshold.
The fact is, Scrum is designed for small-sized teams.
The ensuing sections outline the existing Scrum process
implemented within the company.
Figure 2. Scrum in Sofware House XYZ
Figure 2 depicts the current Scrum implemented by the
company. We have formulated recommendations for
the implementation of Scrum at Scale for Software
House XYZ. Fundamentally, the Scrum at Scale
process aligns with the Scrum framework. In this
research, we made several adjustments to the proposed
Scrum at Scale framework to align it with the conditions
of this research case study. Figure 3 shows the steps
undertaken by us in developing the Scrum at Scale
framework for Software House XYZ.
We incorporate Principals into the process outlined in
the recommendation for implementing Scrum at Scale
for Software House XYZ. Additionally, the Project
Manager's role is renamed as the Product Owner. This
design is tailored to the specific case study conditions
of this research. Therefore, the design recommended by
the researcher may not necessarily be applicable to
other companies. Figure 4 is the recommendation for
Scrum at Scale proposed by us.
Figure 3. The stages of developing the Scrum at Scale design
Figure 4. Scrum at Scale Recommendation
In the recommended Scrum at Scale, several additional
events are introduced, namely Scaled Sprint Grooming,
Scaled Sprint Planning, Scaled Daily Scrum, Scaled
Sprint Review, and Scaled Retrospective. These events
are collectively referred to as Scaled Events within the
Scrum at Scale framework. Meanwhile, other Scrum
events remain unchanged.
The effective implementation of Scrum at Scale hinges
on the prerequisite of a well-established Scrum
foundation within the organization. The applied Scrum
should adhere to consistent standards across all Scrum
teams within the company. Scrum at Scale serves as a
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 408
framework that scales both Scrum teams and Scrum
Events. The initial step in designing the implementation
of Scrum at Scale involves scaling the Scrum teams. A
Scrum team with an expanded scale in the Scrum at
Scale framework is denoted as a Scrum of Scrum.
The Scrum of Scrum (SoS) is a mechanism designed to
facilitate effective communication and coordination
among multiple Scrum teams collaborating on a single
project. According to the Scrum Guide 2020, the
recommended maximum team size is 10 individuals.
However, Harvard research suggests that the optimal
team size averages around 4.6 members [23]. Scrum of
Scrum functions as a team. Therefore, the
recommended size for Scrum of Scrum is 4 or 5 teams.
In Software House XYZ, the Project Manager fulfils the
roles of both Product Owner and Scrum Master within
the Scrum framework they adopt. In our
recommendation, we propose that the Project Manager
assume the role of Product Owner. Additionally, we
suggest eliminating the Project Manager position in the
company and replacing it with a dedicated Product
Owner. Therefore, in the recommended Scrum of
Scrum setup, there will be no Project Manager role.
Figure 5. Scrum of Scrum
Figure 5 illustrates a single Scrum of Scrum (SoS). In
Scrum at Scale, each Scrum team has its own dedicated
Product Owner and Scrum Master. In each team, there
will only be one Product Owner and one Scrum Master.
The Team is composed of individuals possessing the
necessary skills to develop the product. Despite being
divided into three teams, they collaborate on the same
project and operate within the same Sprint to achieve
the agreed-upon Sprint Goal.
Figure 5 features three Product Owners and three Scrum
Masters. We recommend that each Product Owner
should be assigned to only one team to optimize the
outcomes of each team. However, there is no
prohibition for a Product Owner to be involved with
multiple teams simultaneously. The same principle
applies to Scrum Masters. The organization has the
flexibility to determine the arrangement of Scrum teams
according to their preferences. Certainly, with only one
team to oversee, the Product Owner can devote more
focused attention to the tasks and responsibilities of that
team.
The Scrum Master for the Scrum of Scrum is referred
to as the Scrum of Scrum Master (SoSM) [12] is shown
in Figure 6. This role is responsible for ensuring the
effective execution of Scaled Scrum events by the plan.
The SoSM is appointed from one of the existing Scrum
Masters within the Scrum of Scrum.
The SoSM is preferably not replaced during the
ongoing project. Scrum of Scrum collaborates with the
Chief Product Owner to ensure that increments can be
delivered at the end of each Sprint. The SoSM leads the
team to foster collaboration and assists in removing
team impediments.
Figure 6. Scrum of Scrum Master
In addition to the Scrum Masters, a crucial role in the
Scrum Master Cycle is the Executive Action Team
(EAT) as shown in Figure 7. The EAT is a group
consisting of executive leaders and high-level business
owners responsible for strategic decisions and the
implementation of the company's vision. The EAT
ensures the continued utilization of the Scrum at Scale
framework and provides support to ensure the success
of Scrum at Scale implementation. The EAT serves as
the liaison for a collection of SoS, SoSoS, or more
complex structures.
Figure 7. Executive Action Team
The EAT serves as the central hub for the SoS team.
EAT members can be drawn from any stakeholder with
an interest in the development team. We recommend
that EAT members consist of the CTO, Principal,
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 409
Engineering Manager, a representative from Project
Management, and a representative from Technical
Fellow. The company has the flexibility to add or
reduce EAT members as deemed necessary. In addition
to ensuring the smooth implementation of Scrum at
Scale, the responsibilities of the EAT include resolving
impediments that cannot be addressed by the SoS team,
serving as a liaison between the development team and
non-development teams such as finance, HR, and
others, ensuring that process improvements in the form
of practices from the SMM are implemented by the
Scrum team, conducting classes to educate
development teams not yet using Scrum on the
implementation of Scrum and Scrum at Scale
frameworks, supporting various experiments deemed
beneficial for the development process, holding
periodic meetings among EAT members to refine the
development process within the company, ensuring that
the delivered product to the client is of tested quality,
and maintaining a strong client relationship.
We recommend including Principal members in the
EAT. Principals are comprised of experienced
individuals responsible for ensuring the smooth
progress of projects. Their role is to assist in finding
solutions to challenges encountered by the development
team. Principals possess qualifications suitable for
undertaking various tasks within the EAT.
In the Product Owner Cycle, the Product Owners
assemble into a team known as the Executive
MetaScrum (EM), led by the Chief Product Owner can
be seen in Figure 8. The team is responsible for tasks
typically carried out by Product Owners, including
creating the Product Backlog, prioritizing the Product
Backlog, collaboratively establishing the Definition of
Done with the Scrum Master, conducting Release
Planning, and other related activities.
Figure 8. Executive Metascrum
The Chief Product Owner serves as the source of
product information for the project and is appointed by
the client. The client, being aware of the desired
product, fulfils this role. The Project Manager, acting as
the Product Owner, collaborates with the Chief Product
Owner within the Executive MetaScrum (EM). The
Chief Product Owner does not need to be directly
involved with any Scrum team; instead, Product
Owners from Software House XYZ will be part of the
Scrum teams.
The Chief Product Owner is required to comprehend the
product vision. Knowledge about the product is
conveyed to the Product Owners during EM meetings
to discuss the product under development. The Chief
Product Owner facilitates EM members for each EM
meeting.
Scrum at Scale also introduces Scaled Events tailored
for large-sized teams. In the Scaled Events version,
there are several adjustments from the typical Scrum
Events. The following is an explanation for each Scaled
Event.
Scaled Sprint Grooming is an event attended by the EM.
Principals may also attend if their expertise is required
as seen in Figure 9. The Chief Product Owner presents
the product requirements for development.
Figure 9. Scaled Sprint Grooming
During this meeting, the Chief Product Owner reassures
the quality and prioritization of the top items in the
Product Backlog. Any changes communicated by the
Chief Product Owner will be relayed by the Product
Owners to their respective teams during Sprint
Grooming. If there are no changes to the Product
Backlog, this event may be skipped.
Scaled Sprint Planning is an event attended by the EM
and Scrum Master as seen in Figure 10. Principals may
also attend if their expertise is required. The Chief
Product Owner is the individual most knowledgeable
about the product to be developed.
Figure 10. Scaled Sprint Planning
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 410
The participants in the meeting will select the Product
Backlog Items to be worked on during the ongoing
Sprint. Then, the Product Owners will choose tasks for
their respective teams. The Scrum Master and Principal
have a deep understanding of the team members'
capacities within the company. Therefore, the Scrum
Master and Principal can assist in this process. Once the
Product Owners have determined the tasks for their
teams, the meeting concludes. Afterwards, the Product
Owners will commence Sprint Planning within their
respective teams.
Scrum at Scale facilitates communication and
collaboration among Scrum teams in Scrum Events. By
scaling Scrum Events, Scrum teams can carry out their
work more effectively. Scaled Daily Scrum (SDS) is an
activity conducted after the Scrum team's Daily Scrum.
In SDS, each Scrum team attending the SDS at the SoS
level must send at least one team representative. If there
are team members with specific interests in the SDS,
those members are also obligated to attend.
Figure 11. Scaled Daily Sprint
In Figure 11, SDS is attended by 4 individuals from 3
teams. Team C sends 2 representatives because one of
them is deemed important to be present at the meeting.
We recommend that each team sends the same
representative to every SDS to facilitate communication
and collaboration among Scrum teams.
SDS takes place after each Scrum team conducts its
own Daily Scrum, which has a maximum duration of 15
minutes. We suggest conducting Daily Scrum for all
teams simultaneously for time efficiency. After the
Scrum team completes their Daily Scrum,
representatives from each team will engage in SDS with
a maximum duration of 15 minutes.
Scaled Sprint Review is an event attended by the EM
and Scrum Master. Scrum teams may send team
representatives if needed in the Scaled Sprint Review.
Figure 12 is an illustration of the Scaled Sprint Review.
Before the Scaled Sprint Review is conducted, each
Scrum team will first hold its own Sprint Review. The
outcomes of this Sprint Review will then be revisited by
each Product Owner in the Scaled Sprint Review.
Feedback provided by the Chief Product Owner will be
documented by the Product Owner and communicated
to each team.
Figure 12. Scaled Sprint Review
Scrum Retrospective is the final event within a Sprint
before the Scrum team starts a new Sprint (Rubin,
2012). During the Sprint retrospective, each team
member provides insights into the team's work, any
arising issues, and potential solutions to address those
issues. Improvements gathered from the Sprint
retrospective can be applied in the subsequent Sprint.
A scaled Retrospective (SR) is an activity conducted
after each Scrum team holds its Scrum Retrospective.
This event is attended by the Scrum Master from each
team. In this event, participants will discuss the
experiments conducted by each team to improve team
performance.
Figure 13. Scaled Retrospective
In Figure 13, all three teams send a Scrum Master as a
team representative. The Scaled Retrospective practice
follows the best practices outlined in the Scrum
Retrospective section of the Scrum Guide 2020. By
sharing information about the experiments conducted
by each team to enhance the process, other teams can
improve their processes if the information is applicable.
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 411
Scrum at Scale has two essential components: the
Scrum Master Cycle and the Product Owner Cycle.
After scaling the Scrum teams, we designed both cycles
separately, but these cycles will intersect in the
activities of Team Process and Product and Release
Feedback. The following will describe both
components.
We conducted a validation regarding the recommended
Scrum at Scale in Software House XYZ. The validation
process involved interviewing the Lead Project
Manager as a representative of Software House XYZ.
Based on the validation results, we concluded that the
proposed Scrum at Scale can address the challenges
associated with working with a large Scrum team. The
Lead Project Manager expressed the opinion that the
current capabilities of the development team in the
company are not yet sufficient to fully implement
Scrum at Scale. The Lead Project Manager agreed that
the development team in the company should first
improve its Scrum processes and then consider
implementing Scrum at Scale comprehensively.
However, the Lead Project Manager mentioned that
they might experiment with scaling aspects for Scrum
teams, Product Owners, or Scrum Masters. They also
expressed the intention to try implementing some
Scaled Events when the development team is deemed
ready. Positive feedback was obtained from this
validation, leading us to decide against making further
adjustments to the proposed Scrum at Scale.
4. Conclusions
The aim of this research is to address the challenges of
managing large Scrum teams and controlling the team's
commitment to work faced by Software House XYZ,
both of which contribute to delayed product releases.
Based on the analysis conducted, we concluded that the
company needs to implement Scrum at Scale for teams
exceeding 10 members. However, before adopting
Scrum at Scale, the existing Scrum implementation in
the company needs to be assessed. The Scrum Maturity
Model was chosen as the framework to evaluate how
well the company implements Scrum. The Scrum
Maturity Model was adjusted according to the Scrum
Guide 2020 to align the practices with the latest Scrum
guidelines at the time of the research. The evaluation
using the Scrum Maturity Model revealed that the
current maturity level of Scrum implementation in the
company is at level 1, referred to as 'Initial.' The adapted
Scrum Maturity Model questionnaire comprised 81
practices, and the KPA rating method was chosen for
data processing. All 10 respondents provided answers
to the SMM questionnaire. Data processing revealed
that many practices at Scrum Maturity Model level 2
were not well-implemented. The KPA rating for Basic
Scrum goals at level 2 was 73.08% (largely achieved),
and the KPA rating for Requirements Management at
level 2 was 75.56% (largely achieved). Goals with KPA
ratings below 85% were considered immature. We
interviewed the Lead Project Manager to understand the
company's expectations regarding the maturity level
that Scrum teams at Software House XYZ should
achieve. The company aspires to reach Scrum maturity
levels 4 and 5. To attain this, the company must address
practices that have not been fully achieved. A total of
61 practices were identified that need improvement for
the company to reach level 5 in Scrum maturity.
Subsequently, we devised recommendations for
implementing Scrum at Scale for Software House XYZ,
following the framework outlined in the Scrum at Scale
Guide 2022. This step was chosen to resolve issues
related to managing large Scrum teams and controlling
team commitments. We validated the recommendations
through interviews with representatives from Software
House XYZ. From the validation results, the company
expressed interest in trying Scrum at Scale. However,
the company agreed to enhance its existing Scrum
processes before fully implementing Scrum at Scale.
Scrum at Scale is a framework that does not impose
limitations on the size of its teams. As the number of
team members increases, Scrum at Scale becomes more
complex. Subsequent research could employ case
studies with larger teams to derive recommendations for
more intricate Scrum at Scale.
References
[1] K. S. Rubin, Essential Scrum: A Practical Guide to the Most
Popular Agile Process, 1st ed. Addison-Wesley Professional,
2012.
[2] K. Schwaber and J. Sutherland, “The Scrum Guide The
Definitive Guide to Scrum: The Rules of the Game,” 2020.
[Online]. Available:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-
Guide-US.pdf.
[3] Y. Shastri, R. Hoda, and R. Amor, “Does the ‘Project
Manager’ Still Exist in Agile Software Development
Projects?,” Sep. 2016. doi: 10.1109/APSEC.2016.019.
[4] M. Coccia, “The Fishbone diagram to identify, systematize
and analyze the sources of general purpose technologies,”
2017, doi: 10.1453/jsas.v4i4.1518.
[5] Marchewka, “Information Technology Project Management
Providing Measurable Organizational Value - Fifth Edition,”
2015.
[6] J. C. Wood and M. C. Wood, Joseph M. Juran : Critical
Evaluations in Business and Management. Routledge, 2005.
[7] V. Pareto, Cours d’Economie Politique Professe a
l’Universite de Lausanne, no. v. 1. F. Rouge, 1896.
[8] I. Sommerville, Software Engineering, 10th ed. Pearson,
2016.
[9] O. Uludag, M. Kleehaus, N. Dreymann, C. Kabelin, and F.
Matthes, “Investigating the Adoption and Application of
Large-Scale Scrum at a German Automobile Manufacturer,”
Proceedings - 2019 ACM/IEEE 14th International
Conference on Global Software Engineering, ICGSE 2019,
pp. 22–29, 2019, doi: 10.1109/ICGSE.2019.00019.
[10] A. M. AlMutairi and M. R. J. Qureshi, “The Proposal of
Scaling the Roles in Scrum of Scrums for Distributed Large
Projects,” International Journal of Information Technology
and Computer Science, vol. 7, no. 8, pp. 68–74, 2015, doi:
10.5815/ijitcs.2015.08.10.
[11] A. Putta, O. Uludag, S. L. Hong, M. Paasivaara, and C.
Lassenius, “Why do organizations adopt agile scaling
frameworks?-A Survey of practitioners,” in International
Symposium on Empirical Software Engineering and
Measurement, IEEE Computer Society, Oct. 2021. doi:
10.1145/3475716.3475788.
Ahmad Jalaluddin, Eko K. Budiardjo, Kodrat Mahatma
Jurnal RESTI (Rekayasa Sistem dan Teknologi Informasi) Vol. 8 No. 3 (2024)
This is an open access article under the CC BY-4.0 license 412
[12] J. Sutherland, “The Scrum At Scale® Guide. The Definitive
Guide to the Scrum@Scale Framework: Scaling that Works,”
2022, [Online]. Available:
https://www.scrumatscale.com/wp-
content/uploads/2020/12/official-scrum-at-scale-guide.pdf
[13] K. C. Abimaulana, E. K. Budiardjo, K. Mahatma, and A.
Hidayati, “Evaluation of Scrum-Based Software
Development Process Maturity using the SMM and AMM: A
Case of Education Technology Startup,” 2021 International
Conference on Advanced Computer Science and Information
Systems, ICACSIS 2021, no. October 2021, 2021, doi:
10.1109/ICACSIS53237.2021.9631308.
[14] P. Leavy, “Research Design: Quantitative, Qualitative, Mixed
Methods, Arts-Based, and Community-Based Participatory
Research Approaches,” 2017.
[15] J. W. Creswell and J. David Creswell, “Research Design:
Qualitative, Quantitative, and Mixed Methods Approaches,”
2018.
[16] A. Yin, S. Figueiredo, and M. da Silva, “Scrum Maturity
Model,” Aug. 2011.
[17] A. Hidayati, E. Budiardjo, B. Purwandari, and H. Edison,
“MATURITY MODEL OF SCRUM TEAM’S
COMPETENCIES IN GLOBAL SOFTWARE
DEVELOPMENT.” Sep. 2023. doi:
10.22541/au.168014883.36849555/v1.
[18] M. B. Chrissis, M. Konrad, and S. Shrum, CMMI for
Development: Guidelines for Process Integration and
Product Improvement, 3rd ed. Addison-Wesley Professional,
2011.
[19] C. Patel and M. Ramachandran, “Agile Maturity Model
(AMM) Agile Maturity Model (AMM): A Software Process
Improvement framework for Agile Software Development
Practices,” 2009.
[20] P. Salant and D. A. Dillman, “How to conduct your own
survey,” John Wiley and Sons, 1994.
[21] K. Dikert, M. Paasivaara, and C. Lassenius, “Challenges and
success factors for large-scale agile transformations: A
systematic literature review,” Journal of Systems and
Software, vol. 119, pp. 87–108, Sep. 2016, doi:
10.1016/j.jss.2016.06.013.
[22] F. Almeida and E. Espinheira, “Large-Scale Agile
Frameworks: A Comparative Review,” Journal of Applied
Sciences, Management and Engineering Technology, vol. 2,
pp. 16–29, Aug. 2021, doi:
10.31284/j.jasmet.2021.v2i1.1832.
[23] J. R. Hackman, Leading teams: Setting the stage for great
performances. Harvard Business Press, 2002.
