2015 Asia-Pacific Software Engineering Conference
Risks, Challenges and Issues in a Possible Scrum and
COBIT Marriage
Necmettin Ozkan
IT Governance Division
Turkiye Finans Participation Bank
Istanbul, Turkey
necmettin.ozkan@turkiyefinans.com.tr
AbstractTodays turbulent business environment is
compelling software development providers to face several
challenges. As a response to this case, adoption of Scrum methods
is increasing. COBIT, on the other side, has domination in
information technology (IT) and is a de-facto standard providing
an IT governance model with international set of generally
accepted IT control objectives. Considered the coverage of
SCRUM and COBIT (version 4.1 in this case), a coexistence of
them in a same organization has a possibility of emergence for
organizations that want to use SRCUM in their COBIT
environments. While a rationalized, engineering-based approach
has dominated software development almost since its inception
and has a co-occurrence and similarities with COBIT, melting
COBIT and Scrum in an organization is very new and can be an
intriguing subject. This study holds the aim of shedding light on
organizations by focusing on the identification of risks, challenges
and issues of Scrum implementation within a COBIT
environment. This study works as a risk map for organizations
that have opportunity to tailor COBIT. It also exhibits a list of
challenges for organizations that must fully comply with COBIT
framework.
Keywords Agile; Scrum; COBIT; software development
CHALLENGE OF COEXISTENCE
Todays turbulent business environment is compelling
software development providers to face several challenges.
Adapting to rapid and unpredictable changes in appropriate
ways has caused a movement towards reengineering current
software development methods [10], [11]. As a response to
this case, adoption of agile systems development is increasing
[33]. Agility principles value individuals and interactions over
processes and tools, working software over comprehensive
documentation, customer collaboration over contract
negotiation, and responding to change over following a plan
[1]. As the most prominent and used agile method, Scrum is
the subject of this study [18], [22], [23].
On the other side, COBIT (Control Objectives for
Information and Related Technology) has domination in
information technology with its more than 40 integrated
standards worldwide and is itself a de-facto standard providing
information technology (IT) governance model with
international set of generally accepted IT control objectives to
help in delivering value from IT and understanding and
managing the risks associated with IT [2]. Many countries
listed in [4] including USA, Canada, Australia, India, Japan,
1530-1362/15 $31.00 2015 IEEE
DOI 10.1109/APSEC.2015.29
Philippines, UAE-Dubai, Brazil, Colombia, Costa Rica,
Guatemala, Mexico, Paraguay, Uruguay, Venezuela,
Botswana, Greece, Israel, Lithuania, Mauritius, Nigeria,
Poland, Romania, South Africa, Turkey, Zambia facilitate
COBIT for their public sector, governmental agencies and
regulatory bodies.
Considered the coverage of SCRUM and COBIT, a
coexistence of them in a same organization has a possibility of
emergence for organizations that want to use SRCUM in their
COBIT environments. While a rationalized, engineering-based
approach has dominated software development almost since
its inception [28] and has a co-occurrence and similarities with
COBIT, melting COBIT and Scrum in an organization is very
new. And, it can be an intriguing subject when considered the
following points:
While COBIT is process-centric and designed to
standardize people to the processes, SCRUM relies on
people and their creativity rather than processes, thus,
people trump process in agile methodologies [27].
Instead of over-optimized processes targeting best-
practices in COBIT, just enough principle is enacted
in Agile, to reduce any unnecessary effort towards
over-optimization [10].
Conformance to plan is important in COBIT processes,
supporting the belief that sources of variations are
identifiable and may be eliminated, but SCRUM
asserts that demanding certainty in the face of
uncertainty is dysfunctional [27], and uncertainty is a
part and parcel of software development [9]. Therefore,
Scrum concentrates on responding to change rather
than on creating a plan and then blindly following it
[1].
COBIT regards documentation as a means of storing,
sharing, conveying, replicating and backing-up
knowledge, planning, codifying and standardizing for
practice, and creating logs for further use. Agile
methods discourage heavy documentation and prefer to
invest time in producing working software rather than
in producing comprehensive documentation [6], [28].
Planning and control accomplished by a command and
control style of management are practices of COBIT,
but, agile teams are characterized by self-organization
and intense collaboration, within and across
111
 organizational boundaries [27]. Scrum encourages
teams with the resources they need and then trust them
to do their jobs well [6].
Instead of managing risks with high assurance in
COBIT, agile development confronts risks to tackle
them empirically [10].
At this point, if COBIT is regarded as a best practice and
baseline, this study produces the gap and risk analysis of
Scum. If Scrum is regarded as a good practice, this work
shows how much COBIT is suitable to support being agile.
The first option was selected in this study, deeming COBIT as
a baseline, and exposing the major gaps of Scrum from the
baseline. Thus, this study holds the aim of shedding light on
organizations which may face this COBIT and Scrum
coexistence. The focus is on the identification of risks,
challenges and issues of Scrum implementation within a
COBIT driven environment. This study works as a risk map
for organizations that have opportunity to tailor COBIT. It
also exhibits a list of challenges for organizations that must
fully comply with COBIT framework, as in the example of
organizations from banking sector in Turkey. From another
point of view, the study addresses the point stated by COBIT
control practice AI2.7.8 that recommends to consider the
effect of dynamic, non-sequential development techniques
(e.g., rapid application development, extreme programming)
on the monitoring of the application development progress and
approval of application software by stakeholders.
In the next section Scrum is introduced. Then, the research
methodology and the results are delivered. It is assumed that
the reader is already familiar with the COBIT structure and
content; hence a dedicated title for COBIT introduction was
not devoted.
I. WHAT AND HOW OF SCRUM
Scrum teams deliver products via iterative and incremental
model [17] allowing early and continuous delivery of valuable
software. Incremental design means organic growth of the
system being developed [20]. In iterative models, rather than
visiting each step only once, all steps are iterated through until
the system is deemed complete [20]. Projects are divided into
brief and snappy work cadences, typically fixed in duration
from one week to four weeks, known as sprints. A sprint
typically involves planning, development, integration, testing,
and delivery [28]. Developers and customers (or their
surrogates) are actively involved in the development process
and dynamically prioritize features in the sprint planning
meeting (the beginning of each iteration). Each sprint ends
with a working system as a deliverable at the end [17]. During
the sprint, intense 15 to 30 minute daily meetings allow
participants constantly adjust to the realities of high-change
projects [27]. Stakeholders including developers and end users
go through repeated cycles of thought-action-reflection at the
end of each iteration that foster an environment of learning
and adaptation [28]. These sprint review meetings provide an
opportunity facilitating feedback and reflection on what
worked and what did not [32]. Sprint retrospective occurs after
the sprint review and prior to the next sprint planning to
112
inspect the development team itself and create a plan for
improvements to be enacted during the next sprints.
A scrum team consists of a product owner, a development
team, and a scrum master [17]. Scrum master is an enabler for
the team [20]. He/she is responsible for the meetings and for
resolving impediments encountered during the sprints in order
to assure smooth running of the development process [25].
Product owner serves as the mediator between the customer
and the development team and is responsible to maximize the
value of the product by managing the product backlog [20]
[17]. The development team consists of professionals who do
the work of delivering a potentially releasable increment of
done product at the end of each sprint [17]. Scrum
encapsulates the development effort in the development team
with self-organizing and cross-functional principles [10]. Self-
organizing teams, with no hierarchical constraints, choose how
best to accomplish their work, rather than being directed by
others outside the team [24] [10]. Cross-functional teams have
all competencies needed to accomplish the work without
depending on others not part of the team [17]. Scrum
recognizes no titles for development team members other than
developer, no sub-teams in the development team and gives
accountability to the development team as a whole, regardless
of particular domains [17].
II. RESEARCH METHODOLOGY
For the Scrum side, the pure Scrum is used meaning that
the study is free of extended and costumed version of Scrum
models or implementation issues of any kind of Scrum. For
that, related Scrum resources of Scrum creators and ones based
on them were chosen. Plus to this, findings regarding the agile
principles were considered same as for Scrum in account of the
fact that Agile holistically and inherently affects Scrum in a
way. For the COBIT side, while the newest derivative is
COBIT 5, COBIT 4.1 was selected to guide the organizations
that use and practice this version. Among the COBIT products,
COBIT framework 4.1 [2] and COBIT Control Practices [3],
that sustains each related control objectives with detailed
control practices, were chosen in line with the context of this
study. Related processes in COBIT were selected according to
their direct and intense relevance with points that Scrum
touches. It was then checked with other works results studying
Scrum and COBIT together for any purpose.
For the notations used in this study, corresponding control
objectives are remarked as in the example of AI2.1 and
control practices as in the example of AI2.1.3 and related
ones are expressed between parentheses in appropriate places
in the text . COBIT intentionally repeats some control
objectives to ensure appropriate coverage of IT controls [2].
Nevertheless, this study was kept away from such repeats,
preferably mentions the related control objectives and practices
only in the proper places.
III. RELATED WORKS
In order to reach a set of related works, a search with the
keyword of scrum cobit was conducted throughout of
libraries of Google Scholar, IEEE Xplore, DBLP, arXiv,
Microsoft Academic Search, Springer, ACM, and
ScienceDirect in the date of 05/29/2015. Among 245 total
results returned in English, three of them are related to this
study. In the study [25], and similarly in [34], the authors use
only the indicators of COBIT for measuring Scrum-based
software development. The study [26] maps SOX (Sarbanes
Oxley) regularity requirements with Scrum practices. Similar
to COBIT, SOX is a regulation for all public listed companies
in the United States and provides controls over financial data
and its access.
ISACA first released COBIT in 1996, and Jeff Sutherland
and Ken Schwaber conceived the Scrum framework in the
early 90s. As far as the researcher knows, it is the first meet of
Scrum and COBIT now in a study in this context.
IV. COEXISTENCE OF SCRUM WITH COBIT
It is a fact that Scrum more or less touches all COBIT
processes that are 34 in number, with 210 control objectives
and 990 control practices. As COBIT presents a huge area to
work with, it is a must to focus on the processes that Scrum
affects directly. The following provides the selected COBIT
processes and the reasons to select.
Raison dtre of Scrum, first and foremost, is to manage
and direct all IT resources in line with the business strategy and
priorities, to provide optimal value from project and service
portfolios. The same concern is explicitly conveyed in COBIT
process PO1 (Define a Strategic IT Plan). A change to agile
methodologies also entails major alterations to several aspects
of an organization including its structure, processes,
communication channels, roles of people, management style
and culture [5],[28]. That is the subject of COBIT process PO4
(Define the IT Processes, Organization and Relationships). The
focus in Scrum shifts from process to people which is the
subject covered in COBIT process PO7 (Manage IT Human
Resources).
Definitely, Scrum brings fundamental changes to project
cycle and development model of SDLC [28]. These are the
subjects of COBIT process PO10 (Manage Projects) and some
AI (Acquire and Implement) processes. From the list of AI
processes, AI1 (Identify Automated Solutions), AI2 (Acquire
and Maintain Application Software), AI4 (Enable Operation
and Use) and AI7 (Install and Accredit Solutions and Changes)
were selected and collected under the same title in this study as
they are correlated. Contents related to process AI5 (Procure IT
Resources) were mentioned in other corresponding processes
and this process was excluded from the list, same as AI6
(Manage Changes). Acquisition, implementation and upgrade
of the technology infrastructure are out of the scope in this
study as Scrum does not have a direct effect on these matters. It
is also assumed that Scrum does not have a direct relation to
any of Deliver and Support (DS) or Monitor and Evaluate
(ME) processes. Thus, the list of processes studied in this work
consists of:
PO1 (Define a Strategic IT Plan)
PO4 (Define the IT Processes, Organization and
Relationships)
113
PO7 (Manage IT Human Resources)
PO10 (Manage Projects)
AI1 (Identify Automated Solutions)
AI2 (Acquire and Maintain Application Software)
AI4 (Enable Operation and Use)
AI7 (Install and Accredit Solutions and Changes)
In order to cross-check the list with other studies results,
the results from the related works were considered. It was
recognized that two of the studies explicitly lists the COBIT
processes in their works. Among these two, study [25]
considers and contains the processes in [26], the other one, and
provides a suitable basis for comparison. The differences
between study [25] and this study in terms of the process
coverage are the followings:
PO8 (Manage Quality) governs all COBIT processes in
terms of quality ingredients. Corresponding contents
derived from this process were addressed in other
appropriate COBIT processes in this study.
AI6 (Manage Changes) relevant matters related to
Scrum development model were also concerned in
other corresponding processes and this process was
excluded from the list.
DS5 (Ensure Systems Security) was excluded because
it is included in [25] based on ISACA IS Auditing
Guideline for System Development Life Cycle (SDLC)
Reviews [14]. The audit focus, one way or another,
should cover systems security regardless of the
development model. Thus, it is believed that this
COBIT process has not enough priority to be included
in this study as it has a weak relevance with Scrum.
DS10 (Manage Problems) mostly designates the
procedural approach including identification and
classification of problems, root cause analysis and
resolution of problems. PO1, and IA processes give
enough place to maintenance activities if the occasion
arises.
PO1 (Define a Strategic IT Plan) and PO4 (Define the
IT Processes, Organization and Relationships) were
added to the content of this study for the reasons
mentioned before.
A. PO1 Define a Strategic IT Plan
In this process, there are two relevant and important topics
to discuss addressed in PO1.1 (IT Value Management) and in
PO1.2 (Business-IT Alignment).
PO1.1 put forwards that it is required to establish fair,
transparent, repeatable and comparable evaluation of business
cases. It stresses the importance and criticality of a steady,
consistent and fair evaluation method that maximizes business
value and serves for a common understanding of business
valuation of both project requests and requests in projects.
Defining business value of a project cannot always create
tangible results, may include subjectivity issues, and
dependence on the observer perception, leading to win-lose
satiations at the end [10]. The issue in the project selection
phase becomes deeper especially when the full project scope is
not defined in advance of project initiation. Even with an
intensive customer involvement, with these challenges
mentioned, finding consensus on prioritizing projects based on
their clear values, in the abundance of the uncertainty may
propel organizations to some hardships.
When it comes to the business-IT alignment and
integration, PO1.2 states that reciprocal involvement in
strategic planning should be established. Scrum paves the way
of customers to align IT to the business by providing more
involvement in processes and a closer position to IT. To be
integrated, differently, reciprocal and bi-directional channel
from IT to the business and the business to IT is needed. IT in
Agile is prone to be utility/commodity provider for the
business [10]. To make contributions for the integration in
Scrum, a platform is needed in decision making and
governance processes to give idea and feedback from IT
specialists to the business.
B. PO4 Define the IT Processes, Organization and
Relationships
This process draws the border line between Scrum teams
and senior executives. It points out a strategy committee to
ensure board oversight of IT, and one or more steering
committees in which business and IT participate to determine
the prioritization of IT resources in line with business needs
[2]. Albeit Scrum teams have a freedom inside the team, they
one way or another still have an interaction with the remaining
parts of organizations which have authorities over the same
subject which is maximizing the value. Scrum should gain
recognition throughout the organization, and be applied
appropriately. Otherwise, conserving and protecting the natural
structure and mechanism of the teams becomes a challenge.
While the Scrum teams have a voice and right to say on
projects to maximize the value during the development, at the
top, the major effects of boards in selecting projects may easily
overwhelm their relatively minor effects. Thus, Scrum should
put forward who constitutes such boards, who directs them
how and their relationships with the Scrum organization and
processes. The fair position of PO and fair operations of
processes under his/her reasonability, in this manner, plays
very critical role as well. PO4.4.2 (Organizational Placement of
the IT Function) emphasizes the similar concern by saying
define and fund the IT function in such a way that individual
user group departments cannot exert undue influence over the
IT function and undermine the priorities agreed upon by the IT
steering committee.
PO4.4.3 entails to ensure that the IT function is
appropriately resourced to support the business. The workload
and resource capacity management among and inside the
Scrum teams has not been detailed out in terms of who is
responsible for deciding on the staff capacity of the teams, in
order to response adequately to business needs. Inside the
teams, the team pulls a static set of items of projects for a sprint
with their initiatives. However, for the volume regarding to
software maintenance activities (AI2.10.1), the product
114
backlog list can be very dynamic in a way not allowing a
proper workload management during the sprint. PO.4.5.2
extends this resource management approach with flexible
resource arrangements to support changing business needs,
such as the use of external contractors and flexible third-party.
The question comes in when to work with external contractors
and third-parties that do not have Scrum capabilities. The issue
becomes stronger with the consideration that customers in
organizations regard IT as monolithic unit and expect
consistent methodologies across in-house and third-party
teams. AI2.7.5 concerns the same point by stating that when
third-party developers are involved with the applications
development, establish that they adhere to contractual
obligations and organizational development standards
Scrum recognizes no titles for development team members
other than developer [17]. Therefore, there is no specific tester,
business analyst or coder roles; instead Scrum gives
accountability to the development team as a whole [17]. The
roles of the team members are interchangeable, and developers
can choose roles that are not in their area of specialty [35]. This
level of role description means that the roles for analyst, tester,
coder, and so on disappears for inside and outside of the teams.
This approach of Scrum allows a person to make functional
tests for the functions he/she codes. From the window of
COBIT, this restricts the controls to preclude full segregation
of duties as mentioned in PO4.11. Similarly, AI7.6.1 clearly
states that ensure that the testing is designed and conducted
by a test group independent from the development team.
Decision-making in Scrum is entirely at the hands of the
teams [6]. It brings the advantages of flexibility and human
initiative, yet opens gates to the diversity and unpredictability
of people which at the end may inhibit to achieve a level of
consistency and quality with repeatable processes perceived to
contribute to the maturity of an organization [6], [21]. As
another criterion of maturity, documentation is one of
important items for COBIT. COBIT regards documentation as
a means of storing, sharing, conveying, replicating and
backing-up knowledge, planning, codifying, and standardizing
of practice, and creating logs for further use. Scrum software
development methods, on the other hand, suggest just
enough documentation on projects. However, for practitioners
of these methods, it still remains unclear how much just
enough documentation is [8]. The aspects of documentation
and process approach are just two examples. Eventually, Scrum
should develop its own process maturity model to guide
organizations and PO4.1 (IT Process Framework) already calls
for a process maturity model in place.
C. PO7 Manage IT Human Resources
Scrum development focuses on the talents and skills of
individuals, molding the process to specific people and teams,
and people trump process in Scrum [27]. Adversely, the focus
migrates from people centric management to product centric
management by Scrum methods. The structure of Scrum
shapes around the product concept. Line managers, who have
primary responsibilities over people, disappear. However, still
someone should watch over people who are prone to be
forgotten somewhere in the product lines, aggressively
designed for continuous and unremitting delivery. Furthermore,
findings by [31] and [30] stress the importance of competency
management and assert that there is little evidence to suggest
that agile principles will work in the absence of competent and
above-average people. Accountabilities and responsibilities of
functions of teams related to personnel recruitment, retention
(PO.7.1), termination (PO.7.8), competencies management
(PO7.2), adhering to codes of ethics (PO7.3), performance
evaluation (PO7.7) and administrative operations directed and
managed by line managers in the traditional methods should be
addressed in Scrum as well. Furthermore, for the teams that are
expected to trust each other, the concept of codes of ethics
plays a critical role for the success of agile methodologies and
deserves a special attention, especially considered that politics
(as one of the twelve most common factors for project failure
[15]) may trump people [27]. And, organizations should be
aware of that it may take enormous effort, time, and patience to
build a culture of trust and respect among the employees [28].
For the continuity of organizations functions, dependence
upon key individuals should be minimized through knowledge
capture (documentation), knowledge sharing and staff backup
(PO.7.5). As an advantage, rotation of development team
members ensures that knowledge is not monopolized by a few
roles [28]. On the other hand, documentation as useful artifacts
for the backup of information is discouraged in Scrum [1].
Thus, much of the knowledge in agile development resides in
the heads of the development team members [28]. This may
make the organization heavily dependent on some development
team members who accrete knowledge in their sides.
Therefore, the team still requires defining and identifying key
IT personnel and minimizing reliance on a single individual
performing a critical job function (PO4.13). Plus to the
development team, in Scrum team PO is a critical person
because of three reasons: (1) He/she performs a critical job
function like maximizing the value (PO4.13). (2) He/she has
accountability to manage relationships between IT and key
stakeholders effectively (PO4.15.2). (3) He/she must be a sole
person according to the Scrum framework. For such a critical
individual, as pointed out in (PO4.13.4), Scrum should
additionally assure this critical persons appropriate availability
during time-off periods, vacations and leaves of absence
(PO7.5).
Scrum development relies on teamwork, as opposed to
individual role assignment. Performance measurement (PO7.7)
and reward systems, therefore, must be suitably designed [28]
team based, where collective goals supersede individual
accomplishments [32]. Plus to this, Scrum metrics are in
general designed from product point of view, and a special
attention should be paid in using them for the personal
performance assessment. Otherwise, it may damage the teams
transparency for the sake of personal favors.
In general, it is a challenge for Scrum to adapt its unique
human resource management practices compatible with the
organizations human resources process and policies.
Specifically speaking, career path development, mentioned in
PO7.2.4, as an opportunity for personal advancement and
promotion, is a field to study for Scrum which provides a flat
115
structure of organization rather than a hierarchy including steps
to managerial positions. Put organization wide perspective
aside, for sectors that regard people management experience
valuable, Scrum does not provide this opportunity via its
practices in this flatness.
D. PO10 Manage Projects
COBITs general approach for project management as
plan and control is altered in Scrum to collaborative efforts
of those involved in development, thus ensuring that the
creative ideas of all participants are reflected in decisions [29].
Scrum encourages supplying developers with the resources
they need and then trusts them to do their jobs well [6].
There are some models in practice in order to support
project management framework with details of practices.
Scrum excludes these models; however it does not dispel the
presence of the need. Therefore, one of the other huge study
areas for Scrum adopters is to fulfill the blankness in how
side of project management (PO10.2).
According to [7], Scrum starts with the premise that
software development is too complex and unpredictable to be
planned exactly in advance. The nature of this assumption, in
some degree, precludes assessing whether the project is on
schedule, within budget and aligned with the agreed-upon
scope (PO10.6.3) and reviewing and approving cost, schedule,
scope and quality changes in the project baseline (PO10.11) by
key stakeholders and project sponsors (PO10.5.2). Moreover,
customers may be uncomfortable with the flexible budgets and
schedules and may prefer an up-front contractual obligation to
deadlines, and costs [32] that allows making and following
their usual plans. After all, if the customers need and want to
know estimates of what timescale and at what cost the product
will be delivered, it burdens to significant regular ongoing
planning and reporting process in the Scrum project
management.
PO10.7 entails an integrated project plan including
resources required, time requirements for all individuals
involved in the project, clear work breakdown structures, and
identification of a critical path. Other involved parties, such as
finance, legal, procurement, human resources, internal audit,
compliance departments and other IT specialists should also be
considered in this plan (PO10.8.3). For such an integrated
project plan, steps in forming and acquiring a project team with
its competent staff members (PO10.8), in such a dynamic and
adaptive environment, should be work on, with a consideration
of that resource conflicts are possible especially when keeping
the same core team members during a Scrum project [36].
PO10.3 calls for a project management approach
commensurate with the size, complexity and regulatory
requirements of each project. However, scaling issues
(continually identifying and removing dependencies created by
increased complexity) can arise in Scrum. In the case of
occurrence of corporate or organization size distributed area,
subcontracting, developing large and complex systems, there
are some limitations with respect to the nature of Scrum [24].
The study [13] has also shown that organization of large
development efforts, variability factors in scaling, inter-team
coordination, key performance indicators in large development
efforts, scaling agile practices and agile contracts are still the
hot topics of the area. Control objective PO10.3 also anticipates
a project governance structure including project office and
project manager roles which have no place in Scrum model.
For organizations that must comply with this item it is a clear
challenge.
When it comes to project risk management the team must
eliminate or minimize specific risks associated with individual
projects through a systematic process of planning, identifying,
analyzing, responding to, monitoring and controlling the areas
or events (PO10.9). According to [7], assessment, classification
and prioritization of risks occur in a casual way in Scrum
without detailed practices for defining sources, parameters to
analyze, risk management effort and policies for critical risks.
E. AI1 Identify Automated Solutions, AI2 Acquire and
Maintain Application Software, AI4 Enable Operation and
Use and AI7 Install and Accredit Solutions and Changes
The diversity and unpredictability of people who engage in
software development process exhibits some challenges in
terms of requirement management [28]. The unpredictability is
further compounded by the complexity of software
development activities [27]. As a result, requirements present
some degree of variability on the course of a project. The
reasons behind this may be listed as the following:
The nature of software development is so complex that
allowing upfront requirement gathering is not feasible.
Things change on the way because of highly volatile
business environments.
Human use distortion, deletion and generalization to
express their thoughts and such cognitive issues may
cripple requirements elicitation process [12].
Incapacity of people involved in the corresponding
processes may cause things change when things get
closer.
Scrum brings proposals to the first and second items. The
last two still stay there as bigger issues to deal within Scrum
models. Using an agile approach entails formidable
responsibility on the clients part [32]. Customers actively
shape and guide the evolution of the software product [9] by
identifying and prioritizing features, providing feedbacks, and
guiding change through the course of the development [32].
Empowering incapable customers with more initiatives on
software development, and regarding customers change
requests born of distortions, deletion and generalization as
absolute, innocent and harmless demands may danger the
quality, cost and time scale of projects. Therefore, the success
of agile development relies on finding customers who are
expected to be collaborative, representative, authorized,
committed, and knowledgeable (CRACK) [30]. And, it is not
an easy task to find such persons, especially for complex
systems [28]. This highly dependence on customers may also
cause failures if the customers are misaligned with the
stakeholders goals [32]. For the same concern, control
practices AI1.4.2, AI2.1.6 and AI1.4.1 explicitly call for
business sponsors approval for the proposed solution approach
116
and high-level design specification and involvement of
business sponsors and other stakeholders in quality reviews of
project increments. It is also the case for product owners who
are the customer representative and expected to identify and
prioritize the stakeholders most success-critical expectations
and potential sources of business value [10]. Realizing what
Scrum promises to bring for organizations rests heavily on
capable and successful POs. Thus, great Scrum needs great
product owners as well [19].
The requirement elicitation process in any software
development may hide some difficulties like in identifying and
analyzing second and sometimes third level effects, outflanking
their cognitive barriers [10], and anticipating how the
requirements will evolve on the course of the project [16].
Scrum presents a risk of losing creativity somewhere among
small pieces of repeatable works without a big picture of the
system being designed. It makes hard for business and IT to
identify and analyze dependencies, constraints, assumptions,
issues and second and sometimes third level effects across the
requirement (AI1.4.1) and software maintenance (AI2.10.1)
developments. Additionally, customers, in general, are prone to
neglect or not to see non-functional requirements of systems
like performance and system security requirements (AI1.1.3 in
relevant).
Clarity, completeness and comprehensiveness of
requirements play an important and critical role in designing
architecture that meets specifications derived from
requirements. Instead of trying to understand users needs with
upfront requirements gathering, requirements in Scrum are
emergent discovered during the project. Architecture in Scrum
designed for current requirements may exhibit some degree of
issues because not all requirements are gathered [6] during
early stage of the projects. Without an upfront requirements
gathering, lacks of completeness and comprehensiveness of
requirements with the second and third level effects is a source
of issues in designing architecture of software (AI2.1) and
creating key alternative courses of actions of solutions in the
feasibility study (AI1.3.1). Thus, eventually development of
software may end up exponentially rising costs as time passes
in the development life cycle, making the cost of empirical
process model of Scrum high.
For the clarity and traceability of requirements, Scrum
adopters should define their requirements definition procedure
(AI1.1.1) and address epic, feature, and storys equivalents in
software requirement engineering terminology. According to
AI2.2.10, detailed design specifications must be in accordance
with organizational and industry-accepted specification
standards. Scrum provides insufficient guidance with respect to
the structure of the backlog [24] and someone should study
how a requirement is elaborated from the customers definition
of need, through design documents, to code parts of working
product using the Scrum documents.
In Scrum, the product owner provides the first point of
interaction with the customers as a person that serves as the
mediator between the customers and the team [20]. And,
Scrum assumes POs do not necessarily need business analyst
or system analyst responsibilities when selecting most
appropriate requirements with the customers. The powerful TABLE I. LIST OF RISKS, CHALLENGES AND ISSUES
front end of IT with adequate business analyst or system Process Subject Category
analyst capabilities, therefore, is not at the first touch point to
PO1 IT value management Challenge
the customers at all. It must be the duty of the development
teams, and a special care should be paid in isolating potential PO1 Business-IT alignment Risk
business/system analyst attitudes of POs in doing his/her PO4 Scrum teams' interaction with other parts of Risk
works. organizations
PO4 Workload and resource capacity management Challenge
Iterative and incremental development also means iterative
and most probably incremental development of the software PO4 External contractors and third-parties without Challenge
development documents including requirement specifications Scrum capabilities
PO4 Segregation of duties Challenge
(AI2.9), high level design (AI2.1), detailed design (AI2.2) and
test plans. It requires also formal approvals of these iteratively PO4 Process maturity model Challenge
and incrementally developed documents by related business PO7 Building the culture Challenge
process owners and IT stakeholders as well (AI2.9.3), PO7 People management activities Challenge
(AI2.1.5), (AI2.2.11), (AI7.2.8).
PO7 Performance measurement Challenge
Continuous integration means newly constructed part of the
system is integrated with the current system as often as PO7 Career path development Issue
possible [20]. Each additional build has to incorporate into the PO10 How side of project management Challenge
existing structure without degrading the quality [6]. For multi- PO10 Project time, scope and budget management Challenge
team projects, each team checks in their newly constructed part
PO10 Project resource competency management Challenge
of the system within the entire system and all tests probably
including performance, stress, usability, security, system, PO10 Integrated project plan Challenge
integration, user acceptance, operational readiness, backup and PO10 Project scaling Challenge
recovery tests (AI7.2.5) must pass for the changes to be PO10 Restructuring project management office Issue
accepted. Without a right balance between automated scripted
PO10 Project risk management Challenge
tests and interactive user testing (AI7.6.3), this iterative,
incremental and continuous testing can be hard, time AI's Finding CRACK customers Challenge
consuming and risky. All tests may not be performed properly AI's Dependency on great product owners Challenge
all the times, as it requires a lot of time of a sprint for testing AI's Identifying requirements effects Challenge
and quality assurance [24].
AI's Losing the big picture in design Risk
Organic growth of the system also means the creation and
integration of complete, accurate and usable supporting AI's Requirements elaboration and traceability Challenge
documents (AI4.2) with promptly updates to the existing AI's Managing the first point of interaction with the Risk
environment in production for the use of end users (AI4.3), customers
AI's Iterative and incremental development of software Challenge
operations and support staff (AI4.4), and business management development documents, and their formal
(AI4.2). If required, adequate trainings must be provided to the approvals
related people including business end users, IT operators, AI's Incremental and continuous testing Challenge
support and IT application development teams, and service AI's Proving support documents of products Challenge
providers (AI7.1.2) to learn how to use the new and
AI's Establishing agile IT infrastructures Challenge
continuously changing system.
In the promotion to the production, sprint deployment can
be one of the major concerns for teams [24]. Establishment of The study hopefully provides a risk map to manage and a
secure and sanitized test environments as a representative of list of challenges and issues to tackle. In doing so, it is actually
the future operating landscape (AI7.4) with the deployment possible to tailor Scrum with customizations and extensions.
frequency that Scrum anticipates can be challenging with On the other side, the question of how much COBIT (v.4.1) is
cumbersome and non-agile infrastructures. suitable to support being agile may rise and if possible
organizations may choose the option of tailoring COBIT in a
V. CONCLUSION AND FUTURE WORK more agile way. One way or another, the study reminds that
No one model is necessarily better or worse than another while the opportunities and benefits of Scrum make it
[6]. Every model has its own risks, challenges and issues in its attractive, organizations should be circumspect in integrating it
nature. This study is not an assessment of Scrum as good or with COBIT practices. Although agility is necessary for
bad. Rather, the endeavor is to highlight the risks, challenges organizational adaptation, organizations should remember that
and issues of Scrum implementation within a COBIT stability is necessary for organizational optimization, which
environment as listed in the table below. As mentioned before, results in higher assurances for delivering the value. Thus,
this study is free from any extensions and customizations of systems development organizations need to strike a balance
Scrum. between the two conflicting interests: agility and stability [32].

117
 For researchers, there are several avenues of the future
work to reach a more comprehensive level of this study as
below:
Developing extensions to Scrum framework to find
possible solutions from the theory for the items which
are addressed in this work,
Investigating issues in practice faced by organizations
that adopt Scrum within COBIT environments (it also
serves as a kind of justification of this study with
practical examples)
Investigating issues in practice faced by organizations
that adopt Scrum and matching the issues with COBIT
practices (it also serves as a kind of justification of
COBIT with practical examples)
Finding practical solutions for the issues coming from
Scrum practices in COBIT environments and assessing
their effectiveness,
Developing a COBIT maturity assessment of Scrum
processes,
Doing the similar work of this study with the version 5
of COBIT.
References
[1] K. Beck et al., "Agile manifesto" http://agilemanifesto.org/, 2001.
[2] ISACA, "Cobit 4.1", Rolling Meadows, ISACA, 2007.
[3] ISACA, COBIT Control Practices: Guidance to Achieve Control
Objectives for Successful IT Governance, 2nd edn., Rolling Meadows,
ISACA, 2007.
[4] ISACA ,COBIT Global Regulatory and Legislative Recognition,
Rolling Meadows, ISACA, 2014.
[5] K. Schwaber, Agile Project Management with Scrum. Redmond:
Microsoft Press, 2004.
[6] A. I. Khan, M. R. J. Qureshi, and U. A. Khan, A Comprehensive Study
of Commonly Practiced Heavy & Light Weight Software
Methodologies, International Journal of Computer Science and Issues,
vol. 8, no. 4, pp. 441-450, June 2011
[7] S. P. Ravi, B. Reddaiah, L. S. Movva, and R. Kilaparthi, "A Critical
review and empirical study on success of risk management activity with
respect to scrum," ESTIJ, vol. 2, no. 3, pp. 467-473, June 2012.
[8] R. Hoda, J. Noble and S. Marshall, Documentation strategies on agile
software development projects Int. J. Agile and Extreme Software
Development, vol. 1, no. 1, 2012.
[9] T. Dingsyr, S. Nerur, V. Balijepally, and N.B. Moe, "A decade of agile
methodologies: Towards explaining agile software development",
Journal of Systems and Software, vol. 85, no, 6, pp. 1213-1221, 2012.
[10] O. Ktata and G. Lvesque, 'Agile development: issues and avenues
requiring a substantial enhancement of the business perspective in large
projects', in 2nd Canadian Conference on Computer Science and
Software Engineering, Montreal, Quebec, Canada, 2009.
[11] B.W. Boehm, "Making a Difference in the Software Century",
Computer, IEEE Computer Society, March 2008, pp. 32-38.
[12] R. Bandler, Get the life you want. Deerfield Beach, Fla.: Health
Communications, 2008.
[13] T. Dingsyr and N. B. Moe, '"Towards Principles of Large-Scale Agile
Development: A Summary of the workshop at XP2014 and a revised
118
research agenda', in Agile Methods: Large-Scale Development,
Refactoring, Testing, and Estimation, vol. 199, T. Dingsyr, N. B. Moe,
R. Tonelli, S. Counsell, C. Gencel and K. Petersen, Ed. Springer Verlag,
2014.
[14] ISACA, IS Standards, Guidelines and Procedures for Auditing and
Control Professionals, Information Systems Audit and Control
Association, Rolling Meadows, ISACA, 2008.
[15] R. Charette, Why software fails? IEEE spectrum, vol: 42, 2005
[16] P. J. Denning , C. Gunderson, and R. Hayes-Roth, The profession of IT
Evolutionary system development, Communications of the ACM, v.51
n.12, December 2008
[17] K. Schwaber and J. Sutherland, "The Scrum Guide - The Definitive
Guide to Scrum: The Rules of the Game,"
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf,
July 2013, last access: 2015-06-18.
[18] E. Hossain, M.A. Babar, and H. Paik, Using Scrum in Global Software
Development: A Systematic Literatur Review. In: Proc. of the 4th
International Conference on Global Software Engineering, 2009.
[19] K. Judy, Great Scrums Need Great Product Owners: Unbounded
Collaboration and Collective Product Ownership ', in the 41st Hawaii
International Conference on system sciences, 2008.
[20] M. Blom, 'Is Scrum and XP suitable for CSE Development?', Procedia
Computer Science, vol. 1, no. 1, pp. 1511-1517, 2010.
[21] Z. Zhiying, 'CMM in uncertain environments', Commun. ACM, vol. 46,
no. 8, pp. 115-119, 2003.
[22] K. Schwaber, 'Scrum development process', in OOPSLA95 Workshop
on Business Object Design and Implementation, Austin, Texas, United
States, 1995.
[23] H. Kniberg, Scrum and XP from the Trenches, C4Media, Stockholm,
2007.
[24] R. Akif and H. Majeed "Issues and Challenges in Scrum
Implementation", International Journal of Scientific & Engineering
Research, vol. 3, no. 8, pp. 1-4, 2012.
[25] N. Zabkar and V. Mahnic, "Using COBIT indicators for measuring
Scrum-based software development", WSEAS Transactions on
Computers, vol. 7, no. 10, pp. 1605-1617, 2008.
[26] S. Gupta, 'SOX Compliant Agile Processes', in AGILE08, 2008, pp.
140-143.
[27] A. Cockburn and J. Highsmith "Agile Software Development, The
People Factor", Computer, vol. 34, no. 11, pp. 131 -133, 2001
[28] S. Nerur, R. Mahapatra and G. Mangalaraj, 'Challenges of migrating to
agile methodologies', Commun. ACM, vol. 48, no. 5, pp. 72-78, 2005.
[29] J. Highsmith, 'Cutter Consortium Reports: Agile Project Management:
Principles and Tools', Cutter Consortium, Arlington, MA, 2003.
[30] B. Boehm and R. Turner, Balancing agility and discipline. Boston:
Addison-Wesley, 2004.
[31] B. Boehm "Get Ready for Agile Methods, with Care", Computer, vol.
35, no. 1, pp.64 -69 2002
[32] V. Vinekar, C. Slinkman and S. Nerur, 'Can Agile and Traditional
Systems Development Approaches Coexist? An Ambidextrous View',
Information Systems Management, vol. 23, no. 3, pp. 31-42, 2006.
[33] C. Schwaber and R. Fichera, 'Corporate IT leads the second wave of
agile adoption', Forrester Research Inc, 2005.
[34] N. Zabkar and V. Mahnic, 'Assessing Scrum-based Software
Development Process Measurement from COBIT Perspective', in 12th
WSEAS International Conference on COMPUTERS, Heraklion, Greece,
2008.
[35] R. Martin, Agile software development. Upper Saddle River, N.J.:
Prentice Hall, 2003.
[36] J. Cho, Issues and Challenges of agile software development with
SCRUM, Issues in Information Systems, vol. 9, no. 2, pp. 188-195,
2008.