Filetype PDF | Posted on 30 Jan 2023 | 2 years ago
Authentication
digital resources
146x Filetype PDF File size 0.40 MB Source: iacis.org
https://doi.org/10.48009/2_iis_2008_188-195
ISSUES AND CHALLENGES OF AGILE SOFTWARE DEVELOPMENT WITH
SCRUM
Juyun Cho, Colorado State University-Pueblo, joey.cho@colostate-pueblo.edu
ABSTRACT (ASDMs) including Scrum, eXtreme Programming
(XP), Crystal, and Adaptive Software Development
Agile software development methods have been (ASD), have been developed and evolved since
developed and evolved since early 1990s. Due to the 1990s to embrace, rather than reject, high rates of
short development life cycle through an iterative and change [24]. Such new approaches focus on iterative
incremental process, the agile methods have been and incremental development, customer
used widely in business sectors where requirements collaboration, and frequent delivery [18] through a
are relatively unstable. This paper explains the light and fast development life cycle. Although many
differences between traditional software development positive benefits of agile approaches including
methods and agile software development methods, shorter development cycle, higher customer
and introduces the characteristics of one of the satisfaction, lower bug rate, and quicker adaptation to
popular agile methods, Scrum. Finally, the paper changing business requirements have been reported
illustrates issues and challenges discovered through [3], there have been few empirical field studies on
an in-depth case study in a company which has issues and challenges of ASDMs. Therefore, the aim
employed Scrum for many projects. The insights of this research paper was to discover the issues and
presented in the paper can be used in organizations challenges of one particular agile method in practice,
that are in the process of agile software development Scrum, through an in-depth case study in a mid-sized,
using Scrum. web-based development projects for government.
Keywords: Scrum methodology, traditional software The remainder of this paper discusses the differences
development, agile software development, empirical between traditional methods and agile methods, and
process. then presents a brief history, framework, and
empirical process of the Scrum methodology. Finally,
INTRODUCTION the paper discusses issues and challenges of the
Scrum methodology discovered through an in-depth
Traditional Software Development Methods case study.
(TSDMs) including waterfall and spiral models,
utilize extensive planning, codified process, rigorous TRADITIONAL SOFTWARE DEVELOPMENT
reuse, heavy documentation and big design up front METHODS (TSDMs)
[2]. Due to these characteristics, TSDMs are often
called heavyweight development methods. The One of well-known traditional software development
TSDMs are still widely used in industry because of methods is the waterfall model. The waterfall model
their straightforward, methodical, and structured utilizes a structured progression between defined
nature [6], as well as their predictability, stability, phases: planning, analysis, design, implementation,
and high assurance [3]. and maintenance. The planning phase which occupies
typically about 15% of total Systems Development
Though many TSDMs have been developed since the Life Cycle (SDLC) is the fundamental process to
waterfall model to provide significant productivity identify the scope of the new system, understand why
improvements, none of them are free from major a system should be built, and how the project team
problems including blown budgets, missed schedules, will go about building it through technical,
and flawed products [3, 4], and they have failed to economical, and organizational feasibility analysis.
provide dramatic improvements in productivity, in The analysis phase, which occupies about 15% of
reliability, and in simplicity [4]. Due to constant SDLC, analyzes the current system, its problems, and
changes in the technology and business then identifies ways to design the new system
environments, it is a challenge for TSDMs to create a through requirements gathering. The design phase
complete set of requirements up front. (35%) decides how the system will operate in terms
of hardware, software, and network infrastructure.
As a remedy for the shortcomings of TSDMs, a The implementation phase (30%) is the actual
number of Agile Software Development Methods programming. The maintenance phase (5%) focuses
VOL IX, No. 2, 2008 188 Issues in Information Systems
Issues and Challenges of Agile Software Development with Scrum
on go-live, training, installation, support plan, percentage of projects (16.2%) that used traditional
documentation, and debugging [5]. Figure 1 and methods were completed on-time and on-budget with
table 1 below show a typical waterfall lifecycle and all features and functions specified. However, 52.7%
deliverables respectively. As we can see in the figure of the projects were completed either over-budget,
and the table, each phase must be accomplished over the time estimate and/or offering less features
before the following phase can begin and each phase and functions; 31.1% of projects were canceled at
cannot go back to the previous phase like water in the some point during the development cycle [17] (see
waterfall cannot climb up once it reaches to lower Figure 2).
position.
Planning (15%)
Analysis (15%)
Design (35%)
Implementation (30%)
Maintenance (5%) Figure 2 Project resolution (Source: The Standish
Group [17])
Figure 1 Waterfall model lifecycle To overcome these shortcomings, several
practitioners developed agile software development
methods including Scrum, eXtreme Programming
Phases Deliverables (XP), Crystal, and Adaptive Software Development
(ASD). The next section explains the characteristics
Planning Phase Planning Specifications and principles of agile software development
Analysis Phase Analysis Specifications methods.
Design Phase Design Specifications AGILE SOFTWARE DEVELOPMENT
Implementation Phase Completed Product METHODS (ASDMs)
Table 1 Waterfall model deliverables The manifesto for agile software development which
was created by seventeen practitioners in 2001
Over the past four decades, traditional waterfall-style (http://www.agilemanifesto.org), reveals which items
software development methods have been widely are considered valuable by ASDMs. As shown in
used for large-scale projects in the software industry Table 2, ASDMs concentrate more on 1) individuals
and in the government sector due to their and interactions than processes and tools, 2) working
predictability, stability, and high assurance. As software than comprehensive documentation, 3)
mentioned earlier, however, TSDMs have a number customer collaboration than contract negotiation, and
of key shortcomings, including slow adaptation to 4) responding to change than following a plan.
constantly changing business requirements, and a
tendency to be over budget and behind schedule with More Valuable Items Less Valuable Items
fewer features and functions than specified [2, 6, 16, Individuals and Processes and tools
19, 21]. Boehm and Phillip [22], and Jones [23] both interactions
reported that during their project development Working software Comprehesive
experience, requirements often changed by 25% or documentation
more. Williams and Cockburn [24] also mentioned Customer Contract negotiation
that one of problems of TSDMs is the inability to collaboration
respond to change that often determines the success Responding to change Following a plan
or failure of a software product.
Table 2 Manifesto for agile software development
One interesting research study conducted by the
Standish Group of 365 respondents and regarding The twelve principles behind the agile manifesto also
8,380 projects representing companies across major present the characteristics of ASDMs
industry segments, shows that only a small (http://www.agilemanifesto.org/principles.html). As
VOL IX, No. 2, 2008 189 Issues in Information Systems
Issues and Challenges of Agile Software Development with Scrum
shown in Table 3, ASDMs 1) satisfy the customer There are many different characteristics between
through early and continuous delivery of software, 2) ASDMs and TSDMs. Boehm [2], for example,
embrace changing requirements, even in late reports nine agile and heavyweight discriminators
development cycle, 3) deliver working software (See Table 4). He believes the primary objective of
frequently, 4) work daily with business people, 5) ASDMs is on rapid value whereas the primary
facilitate motivated people, provide them with good objective of TSDMs is on high assurance. He also
environment and support, and trust them, 6) assist believes that ASDMs should be used for small teams
face-to-face conversation within a development team, and projects. If the size of the team and projects are
7) use working software as a primary measure of large he suggests TSDMs.
progress, 8) promote sustainable development and
keep sponsors, developers, and users moving at a Project Agile Heavyweight
constant pace, 9) pay attention to technical excellence Characteristics discriminator Discriminator
and good design, 10) maintain simplicity, 11)
promote self-organizing teams, and 12) foster Primary Rapid Value High
inspections and adaptations. objective Assurance
# Principles Requirements Largely Knowable
1 Our highest priority is to satisfy the customer emergent, rapid early, largely
through early and continuous delivery of change, stable
valuable software. unknown
2 Welcome changing requiremts, even late in
development. Agile processes harness change Size Smaller teams Larger teams
for the customer’s competitive advantage. and projects and projects
3 Deliver working software frequently, from a Architecture Designed for Designed for
couple of weeks to a couple of months, with a current current and
preference to the shorter timescale. requirements foreseeable
4 Business people and devlopers must work requirements
together daily throught the project.
5 Build projects around motivated individuals. Planning and Internalized Documented
Give them the environment and support they Control plans, plans,
need, and trust them to get the job done. qualitative quantitative
6 The most efficient and effective method of control control
conveying informaiton to and within a
development team is face-to-face conversation. Customers Dedicated, As needed
7 Working software is the primary measure of knowledgeable, customer
progress. collaborated, interactions,
8 Agile processes promote sustainable collocated focused on
development. The sponsors, developers, and onsite contract
users should be able to maintain a constant pace customers provisions
indefinitely.
9 Continuous attention to technical excellence and Developers Agile, Plan-oriented;
good design enhances agility. knowledgeable, adequate skills
10 Simplicity—the art of maximizing the amount collocated, and access to
of work not done—is essential. collaborative external
11 The best architectures, requirements and designs knowledge
emerge from self-organizing teams.
12 At regular intervals, the team reflects on how to Refactoring Inexpensive Expensive
become more effective, then tunes and adjusts
its behavior accordingly. Risks Unknown risks, Well
Table 3 Principles behind the agile manifesto Major Impact understood
risks, Minor
The ASDMs have the potential to provide higher impact
customer satisfaction, lower bug rates, shorter Table 4 Differences between ASDMs and TSDMs
development cycles, and quicker adaptation to (Source: Boehm [2])
rapidly changing business requirements [3, 10, 12].
VOL IX, No. 2, 2008 190 Issues in Information Systems
Issues and Challenges of Agile Software Development with Scrum
reviewers’ comments and suggestions should be
SCRUM METHODOLOGY reflected in the code (adaptation).
The Scrum software development process is an agile Framework of Scrum
process that can be used to manage and control
complex software and product development using The framework of Scrum consists of three
iterative and incremental practices [1] and is an components including roles, ceremonies, and artifacts
enhancement of iterative and incremental approach to [25]. There are three distinct roles in the Scrum
delivering objected-oriented software [13]. The process: the Product Owner, the Team and the
origin of term “Scrum” came from the popular sport ScrumMaster. The Product Owner is responsible for
Rugby, in which fifteen players on two teams getting initial and on-going funding for the project by
compete against each other. Takeuchi and Nonaka creating the project’s overall requirements, return on
[20] first used rugby strategies to describe hyper- investment (ROI) objectives, and release plan [25].
productive development processes in Japan. Three The Team is responsible for implementing the
strategies from rugby including a holistic team functionality described in the requirements. Teams
approach, constant interaction among team members, should be self-managing, self-organizing, and cross-
and unchanging core team members are adopted into functional to maximize team performance. All of the
Scrum management and control processes. team members are responsible for both the success
and the failure of sub-systems and of entire systems
The Scrum process was developed by Schwaber and [25]. The ScrumMaster (SM) is responsible for
Sutherland [15]. The former developed and ensuring that Scrum values, practices, and rules are
formalized the Scrum process for system enacted and enforced. The SM represents
development while he was at his company, Advanced management and the team to each other [15]. SM
Development methods (ADM), in the early 1990s. also tries to remove any impediments imposed on
The latter developed many of the initial thoughts and developers.
practices for Scrum when he was at Easel
Corporation as a vice president of Object Technology There are several ceremonies in the Scrum process
in 1994. By a joint effort of both Schwaber and including the Daily Scrum Meeting, the Daily Scrum
Sutherland, the Scrum process was first introduced to of Scrums Meeting, the Sprint Review Meeting and
public at the conference of Object-Oriented the Sprint Planning Meeting. The Daily Scrum
Programming, Systems, Languages and Applications Meeting (TDSM) is a 15-minute status meeting to talk
(OOPSLA) in 1996 [13]. about what has been accomplished since the last
meeting, what items will be done before the next
Empirical Process Control meeting, and what obstacles developers have.
TDSMs facilitate communications, identify and
The co-founder of the Scrum process, Schwaber remove impediments to development, highlight and
argues that the Scrum process employs an empirical promote quick decision-making, and improve
process control which has three legs underlying all of transparency (visibility) as explained in the previous
its implementations: transparency (visibility), section. The Daily Scrum of Scrums Meeting
inspection, and adaptation [14, 25]. Transparency or (TDSSM)
is another short daily meeting and follows
visibility means that any aspects of the process that the same format as a regular TDSM. The main reason
affect the outcome must be visible and known to for having TDSSM is to synchronize the work
everybody involved in the process. Inspection between multiple Scrum teams. The Sprint Planning
requires that various aspects of the process be Meeting (TSPM) is a monthly meeting, where the
inspected frequently enough so that unacceptable Product Owner and Team get together to discuss
variances in the process can be detected. Adaptation what will be done for the next Sprint which lasts
requires that the inspector should adjust the process if usually for 30 days. In TSPM, team members break a
one or more aspects of the process are in an project into a set of small and manageable tasks so
unacceptable range. that all the tasks can be completed in one Sprint. The
Sprint Review Meeting (TSRM) is another monthly
A code review can be analyzed with the empirical meeting which is held at the end of the Sprint. TSRM
process control described above. Any code written by is usually a four-hour time-boxed meeting, where
developers should be visible to everybody team members present what was developed during
(transparency). The most experienced and the Sprint to the Product Owner and stakeholders.
knowledgeable developers can review the code
(inspection). If there is a room to improve the code,
VOL IX, No. 2, 2008 191 Issues in Information Systems
no reviews yet
Please Login to review.
