2018 IEEE 22nd International Enterprise Distributed Object Computing Conference

Using Scrum for Implementing IT Governance with

COBIT 5
Ana Cláudia Amorim Miguel Mira da Silva Rúben Pereira
Dep. of Computer Science and Dep. of Computer Science and Dep. of Information Systems
Engineering
Engineering ISCTE
Instituto Superior Técnico
Lisbon, Portugal Instituto Superior Técnico Lisbon, Portugal
ana.claudia@ist.utl.pt Lisbon, Portugal Ruben.Filipe.Pereira@iscte-iul.pt
mms@tecnico.ulisboa.pt

Margarida Gonçalves
Quasinfalival
Lisbon, Portugal
margarida.goncalves@quasinfalivel.pt

Abstract— COBIT 5 is a widely-used framework for
implementing sound governance of enterprise IT (GEIT).
Despite the existence of official guidance, there are still several
challenges that we can encounter. Currently, the ISACA’s
official implementation solution follows a sequentially ordered
process corresponding to a traditional approach, however,
organizations are increasingly embracing more agile ones for
managing projects where the solution is not clear from the
beginning. Using the Design Science Research Methodology, the
authors analyse the current state of art and provide a Scrum
based methodology for managing at team level a COBIT 5
programme. With a hybrid agile-traditional approach, the
authors aim to eliminate some known challenges of COBIT 5,
such as lack of support from top management and misaligned
scopes and solutions. Additionally, in this paper, the authors
present the results obtained from applying the designed
methodology in a COBIT 5 programme in the Portuguese
Finance Ministry, as well as inspect two series of interviews: 10
performed with experts from both Scrum and COBIT 5 areas to
evaluate the solution, and 6 others with the team involved in the
demonstration programme, to understand if the objectives
where achieved. The article ends with lessons learned,
limitations and future work.
Keywords— COBIT 5, Scrum, governance of enterprise IT,
agile implementation.
I. INTRODUCTION
Information technology (IT) and related information
technologies are pervasive not only in simple day to day
functions everywhere, but also playing critical roles in most
organizations. As it grows, IT has become a business enabler,
taking major responsibility in effective and efficient product
delivery, bringing more value to stakeholders [1], [2].
Adding value, while managing enterprise’s use of IT and
mitigating the IT risks, made governance of enterprise IT
(GEIT) a necessity for accomplishing enterprise’s goals, and
therefore, a fundamental concern of corporate governance
[3].
A succeeded GEIT implementation requires a culture of
well-defined enablers as organizational structures, principles
and structured governance and management processes
according the enterprise’s vision [3]. Frameworks are the best
tool to help this implementation [4] since they provide
adaptable solutions for any type of organization. For that
purpose, ISACA developed COBIT [3] as a framework to
“provide guidance in evaluating, directing and monitoring an
enterprise’s use of IT” [5], giving an objective way for
companies to align business strategies with IT goals.
Although COBIT 5 is wide recognized as one of the most
used GEIT frameworks [13], it is also considered too large
and complex, taking years for its full adoption [6], [10].
Regarding the framework’s complexity and overarching
scope, is almost impossible to manage a COBIT 5 programme
without a defined project management methodology [12].
With the countless methodologies that one can currently find,
one must choose wisely and consider all the project
particularities and challenges [18].
The current approach for a COBIT 5 programme,
detailed in the implementation official guide [5], has its basis
in the traditional paradigm of project management,
presenting a linear strategy for the implementation life-cycle.
Traditional methods are defined by an exhaustive planning
phase that eliminates the need for any changes in the
remaining project life-cycle, so the process follows the
original plan, going through all phases in an orderly fashioned
way [18].
On the other hand, agile approaches such as Scrum and
Kanban appeared as an alternative paradigm to the traditional
ones. These are specially focused on building solutions that
are not clear at the beginning [18], by putting the client’s
interests first, embracing constant feedback and welcoming
changes in the requirements at any time of the process [7].
Although these methodologies are mainly applied in the
software development field, organizations are starting to
adopt this new paradigm in several areas beyond software
development such as consulting, manufacturing, coaching,
etc. [24].
In this article, the authors focus their research on Scrum,
trying to fill the gap in literature on agile programme
methodologies for COBIT 5 analysing its feasibility, with
special interest in overcoming some of its known challenges
such as lack of support from top management, failure to
understand the environment, resistance to change and scope
misalignment [5].
Thus, with this work, the authors aim to achieve three
main objectives: ensure senior management commitment and
support during the whole programme; build a solution that
consider the organisational changes, aligning the scope every
time it is required; ensure that the client understands the

2325-6362/18/$31.00 ©2018 IEEE 198

DOI 10.1109/EDOC.2018.00033
solution and does not show resistance to change time it is
required;
To demonstrate its use, the authors have applied the
designed solution in a real project of GEIT with COBIT 5 in
the Portuguese Finance Ministry. For evaluation purposes,
two series of interviews, ten with both Scrum and COBIT 5
experts to evaluate the methodology and 6 other interviews
with the team members involved in the project for validating
the goals achievement. Lastly, the authors analyse and
discuss the results with a reflexion on lessons learned,
limitations and future work.
This article is structured as follows (section): Research
Methodology (2), Problem and Motivation (3), Objectives (4),
Literature Review (5), Related Work (6), Proposal (7),
Demonstration (8), Evaluation (9), Lessons Learned (10) and
Conclusion (11).
II. RESEARCH METHODOLOGY
Design Science Research Methodology (DSRM) was the
methodology chosen to guide this research work. DSRM
provides a process model for doing research in Information
Systems and other applied resource disciplines, as well as a
mental model for reviewers to evaluate researchers [8].
The main goal of design science in IS research is to
produce and evaluate an IT artifact that supports the solution
for an identified organizational problem [9]. The artifacts
produced can be constructs (vocabulary and symbols),
models (abstractions and representations), methods
(algorithms and practices), and instantiations (implemented
and prototype systems).
The DSRM process establishes 6 phases [8] and our
research conforms as described next:
1. Problem identification and motivation: Lack of
literature on applying agile methodologies to GEIT
implementation with COBIT 5.
2. Define the objectives for a solution: Eliminate
some of the known challenges of COBIT 5 programmes.
3. Design and development: Scrum based
methodology for GEIT implementation with COBIT 5.
4. Demonstration: Demonstrate the proposal by
applying the methodology in a real project of COBIT 5
adoption in Portuguese Finance Ministry.
5. Evaluation: Making interviews with experts
from both Scrum and COBIT 5 areas.
6. Communication: Submission to 2018 IEEE 22nd
International Enterprise Distributed Object Computing
III. PROBLEM AND MOTIVATION
This section is related with the “Problem Identification and
Motivation” step from DSR model (step 1), introduced in
section 2 as the research methodology used in this work.
As aforementioned, COBIT 5 is a widely known
framework for governance of enterprise IT (GEIT)
implementation [13]. When correctly adopted, brings much
value to organizations promising to minimize the risk of IT
[13], [14]. Nevertheless, there are still a few more things that
can be done to provide more support to practitioners when
using this framework.
First of all, there is a known lack of literature on COBIT
5. Despite the existence of official manuals to support its
adoption [4], [5], previous studies on COBIT 5 are scarce [6],
199
specially regarding lessons learned of previews
implementations and practical examples. Case studies and
lessons learned can be fundamental for practitioners,
especially when COBIT 5 is such a complex and overarching
framework, having 7 enablers, 37 processes and more than
6188 interdependencies between them [10], [11], [14] -
“Putting processes in places at any organization that covers
even a fraction of what is encompassed in, for example,
COBIT 5, is highly challenging” [28].
Moreover, ISACA itself aware in its manuals for some
“practical issues that need to be overcome” [5] such as lack
of senior management commitment and support,
communication issues, failure to understand the environment,
resistance to change and scope misaligned with requirements.
This leads to the main motivation of this research work.
The current implementation life-cycle for a COBIT 5
adoption programme can be one of the problems, since it
seams to be a linear strategy. The basic idea of traditional
approaches is that projects are predictable and have clear
boundaries [17], [18]. This makes them easy to plan in detail
so the project flows without rethinking the process, since
changes are not expected.
Although this solution works for many projects, the
strategy used must contemplate the project characteristics and
there is no evidence that a traditional approach is the correct
one to use in a GEIT implementation.
As aforementioned, traditional or linear strategies
consider that projects are predictable so the scope is not
expected to change [17], [18]. This is not the environment
found in most organizations since change is the reality of any
business environment [27], it is likely that the requirements
change, since business needs change, and if this possibility is
not considered, can lead to scope misalignment, which is one
of the challenges found for a COBIT 5 adoption.
Besides, this paradigm also assumes that projects are
isolated from their environment [17], since the requirements
and goals are established at the beginning. This contributes to
a reduction on communication with the client and might
result in lack of support from top management and increase
the resistance to change.
Agile approaches are progressively being more used in
organizations [29] to overcome known problems of
traditional methodologies as they allow to strengthen
engagement with stakeholders due to its nature of feedback
loops which also enables to review the initial requirements
and adapt scope any time in the process [16], [17], [18].
IV. OBJECTIVES
In this chapter, the authors intend to indentify the objectives
of a solution for the problem stated in chapter 3 (step 2 of
DSRM).
The authors main objective is to explore the adoption of
an agile approach for managing a COBIT 5 programme and
to eliminate some of its known challenges.
Aware of the difficulty within IT Governance
implementation programmes, with this study the authors aim
only to address the challenges related with stakeholder
engagement, scope and requirements alignment, environment
awareness and development of the most appropriate
solutions.
Therefore, the objectives for this research are the following: Although it was initially created as a solution for
- Objective 1: Ensure senior management software development, its principles can be applied in other
commitment and support during the whole programme; disciplines and it is starting to be adapted progressively more
- Objective 2: Build a solution that considers the in areas beyond software [24], [27].
organisational changes, aligning the scope every time it is Scrum basic idea is to build the product incrementally
required; using several short iterations (sprints) with feedback of the
- Objective 3: Ensure that the client understands the work done, instead of deliver a complete product near the end
solution and does not show resistance to change; [7], [16], [17], [18]. Its mindset is the empiricism [16], which
makes it simple and straightforward, since it is based on the
idea that knowledge comes from experience “simplicity is
V. LITERATURE REVIEW essential” [7].
In this section, the authors provide, based on literature, When applying Scrum, one must adopt some specific
general understanding of COBIT 5 life-cycle as also provide rules derived from its values of transparency, adaptation and
definitions of key concepts regarding Scrum. inspection [16]:
- There are three main roles: Product Owner,
Scrum Master and Development Team. Together, they form
A. Using COBIT 5 for GEIT implementation the Scrum Team.
ISACA developed COBIT 5 as a framework to “help - The project is divided into sprints – time boxes
enterprises implement sound governance enablers” [5], between 1 to 4 weeks. At the end of each sprint it must be
giving an objective way for organizations to align business delivered some valuable product increment.
strategy with IT goals. For this purpose, the framework - Inspection and adaptation are assured through
comprises 5 principles, 7 enablers, 26 roles and 37 formal events: at the beginning of each sprint (Sprint
management and governance processes and its correspondent Planning), at the end of each day (Daily Meeting) and at the
good-practices, as well as seven sequential phases (described end of each Sprint (Sprint Review and Sprint
in table 1) [4], [15]. Retrospective).
The seven enablers are the core of this framework since
they are the pillars for an effective GEIT implementation [4], VI. RELATED WORK
[5], [19], [20]. They are: Principles, policies and frameworks, Looking for related work in literature, the authors faced some
Processes, Organisational Structures, Culture, Ethics and lack of references for previous studies, not only concerning
Behaviour, Information, Services, Infrastructure and COBIT 5 programmes, but also Scrum based approaches for
Applications, People, Skills and Competencies. areas beyond software development.
Faced with this problem, the authors focused on studies
B. Scrum about Scrum-based approaches for complex projects
(although in software areas) and scaling agile frameworks. In
Agile is an iterative and incremental paradigm for product this section these and other relevant research in this matter
development that aims to create value under constant are analysed.
changing environments, being adaptability its key
characteristic.
TABLE I . DESCRIBED PHASES OF COBIT 5 ADOPTION FOR GEIT IMPLEMENTATION (FROM [5])
1) What are the drivers?
Phase 1 is for identifying the current change drivers, while it is established the desire to change at executive management levels. Regarding programme
management dimension, it is identified the risk associated, the objectives, success factors and high-level responsibilities, which will be described in the
business case.
2) Where are we now?
Phase 2 is for aligning the IT-related goals with business strategies and risk. For this purpose, COBIT 5 provides a generic mapping (goals cascade) of
enterprise goals to IT-related goals to enabler goals and to the key processes involved. Then it is assessed the current level of capability of the identified
processes. Critical processes must be of sufficient capability to ensure successful outcomes. At programme management level, it is reviewed and evaluated
the business case.
3) Where do we want to be?
Phase 3 is for setting the target for improvement, followed by a gap analysis between AS-IS and TO-BE to identify solutions that must be communicated
to stakeholders.
4) What needs to be done?
Phase 4 is for plan feasible and practical solutions by organizing potential projects into the overall programme supported by justifiable business cases. At
the change enablement level, it must be identified the quick wins build on existing strengths.
5) How do we get there?
Phase 5 is for implementing the proposed solution into day-to-day practices, monitoring the projects within the programme. Thus, it is required engagement
and communication with stakeholders for the programme success.
6) Did we get there?
Phase 6 is for assuring a sustainable transition of the improved governance and management practices into normal business operations. Monitor the
achievement of improvements using performance metrics, for example monthly, and documenting lessons learned.
7) How do we keep the momentum going?
Phase 7 is for preparing for a new cycle of continuous improvement, by review the overall success of the initiative and identify further requirements.

200
A. Requirement analysis and project planning
COBIT 5 is a framework for implementing GEIT, which
identifies and describes a set of end-to-end processes, related
base-practices and activities. In order to be in compliance
with COBIT 5 good-practices and principles, the processes in
which IT governance enablers are implemented, should
suffer a readjustment according the target established.
There is a lot of work that must be addressed before and
after the development of a governance solution, as showed in
table 1, where projects begin only in step 5, performing 4
steps before the actual implementation of the solution. These
4 steps are mainly related with requirement analysis for
projecting and planning the encompassed projects.
Indeed, the authors found special interest in the hybrid
approach Water-Scrum-Fall [30], that is approached as the
reality of most of the Scrum processes.
This approach is supported by the idea that business
analysis and release management continue to follow more
traditional approaches leaving Scrum only to the
development team level [26]. For that reason, this approach
suggests a more realistic life-cycle for Scrum projects of three
distinct parts: Water, Scrum and Fall.
The Water phase is to plan and define the high-level
requirements needed to set the project direction, timeline and
budget. Following is the Scrum part, where the work is done.
The initial requirements are not definitive, the main goal of
this approach is to define an initial idea of the project that
only means to set direction, requirements may change during
Scrum phase. Finally, the Fall part of the project is for
software test and rollout, this formal step is to determine the
acceptance of the product as a whole [26], [30].
Regarding this subject, other solutions were considered
particularly relevant to the authors, namely C. Thiemich and
F. Puhlmann study [21] of Business Process Modelling in
which they propose to improve each process incrementally
using Scrum, with process releases each 5 to 10 sprints. For
defining the project direction and evaluate BPM maturity,
before the project starts there is a dedicated scoping phase.
Additionally, at the beginning of each release there is a sprint
0 for defining the initial requirements, where Process
Backlog is an output expected at the end. The next sprints are
dedicated to the process increment (same as product
increment).
The concept of process releases may be an interesting
addition, however, when considering COBIT 5 one must not
forget that is not just about process design and
implementation. There are other enablers that must be
contemplated in a GEIT implementation such as information,
culture or even roles. Although the enablers must be
implemented under specific and identified processes, not all
cases of improving process maturity will be about designing
a new process and implement new procedures; often means,
for example, to design a necessary output or adding a new
role.
Looking at these two solutions for scoping and
requirements analysis, both scope and kick-off phases of [21]
are in some way traditional steps, which makes these two
solutions very similar at the Water level of the Water-Scrum-
Fall approach.
201
B. Scrum for programmes or complex projects
Using Scrum to manage a COBIT 5 programme is not a
straightforward fit, especially since Scrum was originally
designed as a methodology for software development
projects.
One of the challenges of developing a Scrum-based
approach for COBIT 5 is the scalable factor. The original
Scrum framework [16] is conceived for a single project,
however COBIT 5 is approached as a programme [5].
Since Scrum is a framework, it is possible to shape it to
the problem needs. The need to scaling up Scrum is not a
novelty in literature, in fact, the authors found some
interesting solutions and practical case studies that will be
following discussed.
The major challenges to address in a complex project or
a programme are mainly related with scaling the coordination
mechanisms between teams [31], [34].
A scaled Scrum solution was designed and tested at
Nokia and documented in [31]. The proposed framework
suggests having 3 types of product backlog: one for the
general requirements of the programme, one for each release
and, at the release level, a scrum team backlog. In addition, a
Program Manager above all Scrum Team Masters is
proposed, as well as a Program Product Owner above all
Team Product Owners. Meetings are also multiplied at the
programme level between releases.
Another possible solution is the scaled agile framework
SAFe [32]. This agile framework promises to manage
complex projects and programmes, however it includes a
considerable number of additional elements, increasing the
complexity. With 2 levels (programme level and team level)
the idea is to have programme releases composed of four
iterations and an additional one to plan the next releases.
Besides having all the basic concepts of Scrum, it includes
more than ten other elements such as a Scrum of Scrums,
programme backlog, System Eng., product manager,
business owners, product increment objectives, etc. While
this solution may be ideal for many complex projects or entire
organizations that want to become agile, the additional
complexity can be a very high cost to pay for a programme
as challenging as COBIT 5.
Many are the solutions and possible deviations of Scrum.
As a framework, one of the best things about Scrum is the
possibility to apply its principles in a particular context,
adapting and working out its practices considering the
constraints.
VII. PROPOSAL
In this section, the authors detail the solution designed to
achieve the identified objectives (step 3 of DSRM).
The authors chose Scrum due to its nature of welcoming
changes, perform continuous delivery and obtain constant
feedback [7], which the authors intend to verify if contributes
to strengthen the relation with stakeholders, and provide a
collection of solutions that best enables IT governance
considering the constant changing environment most
organizations live.
Therefore, the authors propose an incremental strategy
for developing IT governance solutions and to eliminate some
known issues of COBIT 5 adoption programmes.
 FIGURE 1. SCRUM FOR COBIT 5 LIFE-CYCLE

A. COBIT 5 life-cycle goals cascade. At the end of Sprint 0, the programme

The authors designed two artifacts: a set of constructs to
define the rules and practices in which the implementation
will operate, and a model that uses those rules and describes
the life-cycle.
The model (Figure 1) describes the seven
implementation phases (Table 1) in red circles, aiming to
show how they match with each phase of this hybrid
approach.
Due to the reasons stated before, the authors decided to
embrace the hybrid strategy.
The first two phases of implementation (Table 1) are for
identifying the drivers of change and to select the key
processes to improve. These two phases are essential to
define the initial product backlog, so they were established as
“prior work” constituting the “Water” phase of this solution.
Therefore, in this proposal, the first part comprises two
distinct steps: scoping for identifying the issues triggering the
need to act, and a special Sprint 0 for developing the product
backlog.
The authors identified phase 1 of COBIT 5 as being part
of the scope planning process for defining the product,
deliverables and objectives. Sprint 0 is a special sprint for
developing the product backlog. This encompasses the
identification of the critical processes to improve through the
objectives were discussed, the initial requirements were
established, the key processes were identified and the initial
product backlog was created.
For the Scrum part, the work is divided into teams. Each
Scrum Team becomes responsible for one process, starting
by its capability assessment to the actual implementation of
the governance solutions (phase 2 to phase 5 from COBIT 5
from Table 1). These solutions will be designed iteratively so
that the requirements initially defined can be revaluated and
priorities can be readjusted. With this approach, the authors
expect to design better solutions through constant feedback.
After the solutions are implemented, they must be
controlled. This corresponds to phase 6 (Table 1) and it is for
controlling the processes and “test” the solutions, measuring
the defined metrics. Thus, phase 6 and 7 from COBIT 5 are
not addressed with Scrum, because it is a rollout period of
test, corresponding to the Fall step of this solution.
B. Specification of Scrum concepts for a COBIT 5
programme
In order to use Scrum for a programme of GEIT
implementation, we need to adapt some basic concepts, and
develop a scaled approach. In tables 2, 3 and 4, the authors
explain how the solution differs from the original definition
in terms of events, artifacts and roles.

TABLE II. SCRUM ROLES SPECIFIED FOR A COBIT 5 INITIATIVE

Scrum Scrum original definition
Roles
Product This person is the client’s representative during the whole project.
Owner He/she is accountable for creating and managing the Product
Backlog’s content. His/her job is to manage the Product Backlog
according the clients’ interests, ordering the items so it brings up the
most valuable increment at the end of each sprint.
Implementation Also known as development team. Group from 3 to 9 professionals
Team whose main responsibility is to turn Product Backlog’ items into
tangible Product Increments. This team is self-organized and cross-
functional, deciding autonomously which part of the Product Backlog
is done in each Sprint.
Scrum Master Scrum Master is responsible for promoting and supporting Scrum
among team and non-team members, as he/she must also coach the
development team.
Scrum for COBIT 5
[16] Product Owners’ role starts at scoping phase of our
proposal, where he must identify the issues
triggering need to act and business priorities.
In a COBIT 5 programme, Product Owner has the
same responsibilities of developing and managing the
Product Backlog as a typical Product Owner and is
unique for the programme and team level.
Additionally, he/she must keep the integrity of the
product during the whole project, monitoring the
dependencies between processes and deliverables.
Should be someone from the clients’ side and a
COBIT 5 knowledgeable.
[16] A programme for COBIT 5 adoption is for
implementing sound governance enablers that have
direct implications in each 37 processes identified.
Each implementation team must be responsible for
one process. They are responsible for designing and
implement the established governance solutions in the
process (see product increment). They must also
participate in the AS-IS capability assessment.
[16] Same responsibilities as a typical Scrum Master. Each
team has its own Scrum Master.

202
 TABLE III. SCRUM EVENTS SPECIFIED FOR A COBIT 5 INITIATIVE
Scrum Scrum original definition Scrum for COBIT 5
Events
Product Product Backlog Refinement is the act of adding detail, estimates, and [16] This activity is fundamental for a COBIT 5
Backlog order to items in Product Backlog. It is an activity in which the Product programme given its numerous process
Refinement Owner and the Development Team collaborate on the details of Product dependencies. Same purpose as a typical backlog
Backlog items. During Product Backlog refinement, items are revised and refinement.
reviewed.
Daily Scrum Is a stand-up meeting with maximum duration of 15 minutes, every day [16] May not be applied. It is difficult in a complex
in the same place at the same time. programme where the resources are sometimes
The goal is for every team member to expose every conflicts or issues outsourced to reunite everyone in the same place at
with the remaining team members. the same time every day.
Sprint This meeting is for planning the next sprint. Every development team [16] Only at team level. At the beginning of each sprint,
Planning member selects a few user stories from the Product Backlog to implement with the same purpose as a typical sprint planning
in the next iteration and the result is the Sprint Backlog. meeting.
Sprint Review Meeting at the end of each Sprint, where the Scrum Team and relevant [16] Only at team level. At the end of each sprint, with the
stakeholders inspect the increment and agree on changes in the Product same purpose as a typical sprint review meeting.
Backlog. The main goal is to show the items “done” and get feedback on
the increment, which may be accepted or rejected by the client.
Sprint Meeting at the end of the Sprint, where the team inspects itself and the [16] Only at team level. At the end of each sprint, with the
Retrospective work performed and creates a plan with improvements for them to apply same purpose as a typical sprint retrospective
in the next sprint. Occurs after each Sprint Review and before each Sprint meeting.
Planning.

TABLE IV. SCRUM ARTIFACTS SPECIFIED FOR A COBIT 5 INITIATIVE

Scrum Scrum original definition
Artifacts
Product Product Backlog is an ordered list of all the functionalities, functions,
Backlog requirements, improvements and corrections that represents a change in the
product.
It is Product Owner’s responsibility during the whole project, including
its creation, manage its content, availability, and ordering its items.
Sprint Sprint Backlog is a subset of Product Backlog. It is the list of selected
Backlog items from Product Backlog for a specific sprint. It is a result of the
development team selection of user stories to work on in that iteration.
User Story Representation of a requirement as an item of Product Backlog. Is a
simple and easy way to create context around a task.
User stories are short and should be something like: As a <type of user>,
I want <some feature>, so that <some goal>.
Product A usable part of work done in each sprint. Product Increment is the group
Increment of all the items from the Product Backlog that were “done” during the last
sprint. This increment will sum to the previous product increment if its
complete enough to demonstrate its working functionality.
Scrum for COBIT 5
[16] Product Backlog is unique to the entire programme.
It is an ordered list of user stories related to the
agreed deliverables to implement governance
enablers.
[16] Sub set of items from Product Backlog, with the
same purpose of a typical Sprint Backlog.
Each team has its own Sprint Backlog since they
have separate contexts to work on.
As simple as it can be. Should not follow a specific
[16], format. In this case, a story card should contain more
[22] information like the process related and the
correspondent phase of COBIT 5 life cycle.
[16] Processes are not as easy to deliver as features in
software applications. The main goal will be to
improve process capability with small deliveries of
necessary work products to achieve the established
target.

VIII. DEMONSTRATION initiative comprised: 1 product owner, 1 programme

This section covers the step 4 of the DSR method. To
demonstrate the feasibility of this solution and to prove that
it can be used to improve the outcomes of COBIT 5
programmes, the authors will next discuss the results from
applying it on a real programme of GEIT implementation
with COBIT 5 in the Portuguese Finance Ministry.
The programme was carried out at the Portuguese
Finance Ministry. With this GEIT implementation
programme, they sought to obtain reliable guidance from a
well-known framework, such as COBIT 5, to start their work
system based on internationally accepted good-practices.
This programme had a duration of 5 months with 8 sprints of
2 weeks each, and a pause for Christmas holidays of 2 weeks.
The programme was composed by 5 projects, where each
of them was focused on a specific process. The processes
chosen through the goals cascade tool were the following:
APO02 Manage Strategy, APO03 Manage Enterprise
Architecture, APO10 Manage Suppliers, BAI01 Manage
Programmes and Projects.
Regarding the roles and the people involved, the
manager, 1 scrum master and 5 implementation team
members. These members were fully outsourced, except the
product owner.
For each process was established a scrum team, however,
since the resources were limited in number, some
implementation team members participated in more than one
team. Furthermore, Scrum master was the same for every
scrum team and participated in one of the projects as an
implementation team member as well, being more than just a
team manager, which worked out very well.
The deliverables produced were the following: the
business and application layers of the enterprise architecture,
the TO-BE processes designed and documented, workshops
of COBIT 5 and Scrum and documentation to support the
establishment of some new organizational structures.
To test the approach in a real environment, allowed the
identification of some relevant issues.
First of all, the programme manager role is not part of the
designed approach (explained in section 7). It was agreed, at
the scoping phase of this programme, that a programme
manager would be essential for managing the upper level and

203
keep the integrity. This programme manager worked as a was asked for them to provide their opinion, in open
project manager for the programme, with scrum master responses, about the approach based on their knowledge and
responsibilities at the programme level. experience in the matter.
Regarding scrum meetings, they were conducted at In Table 6, it was adopted the following simbology for
project level as established, however, since there were no assessing the opinion gave to each element of the solution: if
many people involved and scrum master was the same for all the interviewee did not agree with the definition gave to a
the projects, meetings were common for everyone. One specific element (Tables 2,3,4), the cell is empty; if the
common sprint planning, sprint review and sprint interviewee partially agreed, the cell is filled with “ ”; if the
retrospective at the end of each sprint. interviewee totally agreed, it was used “ ”.
Considering the programme life-cycle: phase 1 began For a more quantitative analysis, the authors considered
before the involvement of the rest of the team, as established that each “ ” has value 1, and “ ” has value 0.5. For a
by the Water-Scrum-Fall approach. This programme total greater than 9.5 (with a maximum of 10), the cell was
planning was responsibility of a joint work between product painted grey to distinguish the more accepted elements from
owner, programme manager and a COBIT 5 expert that is the rest.
also member of the implementation team. Sprint 0 turned out Table 7 shows some statements collected from the
to be a little mixed with the rest of the programme planning. interviews that justify the assessment gave to each evaluated
Phases 2 and 3 were also addressed as prior work, since element.
the processes chosen had very low capability levels (between
0 and 1), so the target for improvement was stated at the TABLE V. INTERVIEWEES’ INFORMATION
beginning as high-level targets. However, for the processes Country Experience Function in Level of Level of
of capability level 1, were conducted a series of interviews in IT IT knowled knowled
(years) ge ge
with the client to perform a more accurate assessment. in in
In phases 4 and 5, were planned and produced the COBIT Scrum
agreed deliverables, although the high-level requirements 5 (1 to 5) (1 to 5)
were agreed during at scope definition, the solutions were 1 Portugal 15 Project 3 5
Manager
constantly evolving during the closely contact with the
2 Portugal 18 Senior 5 2
customer, as foreseen by the Water-Scrum-Fall approach. Advisor
Phase 6 was out of this project scope, however is part of 3 Portugal 26 PMO 4 5
a second project that is starting with new requirements, where Director
the monetarization of the processes designed and the 4 Portugal 24 IT 5 5
Governance
corresponding deliverables are going to be addressed. Consultant
5 Portugal 19 IT 4 3
IX. EVALUTATION Governance
Evaluation phase (step 5 of DSRM) aims to measure how Consultant
6 Portugal 23 SI 5 3
well an artifact supports a solution to the problem, comparing Consultant
the objectives to the results observed from use of the artifacts 7 Portugal 9 IT 3 4
in the demonstration [8]. Governance
Professor
8 Portugal 5 IT 4 3
A. Interviews with experts Governance
Investigator
To obtain a result as accurate as possible, the authors intend 9 Portugal 23 Agile 3 5
to perform as much iterations as possible, but at least two, to Coacher
the DSRM process described in section 2. 10 Brazil 23 IT 5 4
At the end of each iteration, it will be performed a set of Governance
Professor
interviews with experts from both areas to evaluate the
artifacts so the methodology can be refined.
For this first iteration, were performed 10 qualitative B. Evaluation of Objectives
semi-structured interviews with both Scrum and COBIT 5 For evaluating the solution regarding the objectives
experts. established in section 4, the authors conducted a set of
The interviews were conducted by one author over a additional interviews with the team involved in the
period of one month and each one lasted about 1 hour. To demonstration programme described in section 8.
support and lead the interview it was developed a Since a methodology is described as a structured
questionnaire with both open and closed response questions knowledge that deals with methods, techniques, rules,
about COBIT 5, Scrum and the methodology as a whole. templates, best practices, principles and axioms to perform a
It was also asked for interviewees to rank their expertise complex task or group of tasks [23], [33], it requires
with COBIT 5 and Scrum frameworks on a scale from 1 to 5 interaction with people who will use it to achieve the goals
(1 = marginal knowledge; to 5 = expert knowledge). This and proposed. Thus, no one better than the ones who used it to
other information about the interviewee’s can be seen in evaluate how well it achieved the objectives.
Table 5. For this evaluation, were performed 6 semi-structured
With the questionnaire, it was provided the definition of interviews to the implementation team and programme
each element for this specific solution as showed in Tables manager, conducted by one author over a period of one week
2,3 and 4, as well as the model of the life-cycle (Figure 1). It and each one lasted about half an hour. Following, the authors

204
analyse the addressed questions regarding each objective, and
transcribe some of the answers.
- Objective 1: Ensure senior management
commitment and support during the whole project.
In a scale from 1 to 5 (1 = strongly disagree; 5 = strongly
agree) 3 out of 6 strongly agreed (5) when asked if senior
managers were interested in the programme and 3 agreed (4).
When the question was “Were senior managers involved in
developing the solution?” 4 out of 6 agreed, 1 strongly
agreed and 1 was neutral (3).
Furthermore, in open responses, all the six members
considered that a Scrum-based approach was fundamental to
a greater support from top management when developing the
solution: “Besides the iterative approach, a balanced team
was essential with a spirit of great mutual help.”
(Implementation Team Member 2), “An iterative strategy
where senior managers could assess the several iterations
and provide feedback was fundamental. It guaranteed the top
management constant involvement and enabled them to have
a greater control over the solution.” (Implementation Team
Member 1).
- Objective 2: Build a solution that consider the
organisational changes, aligning the scope every time it is
required.
When asked if the solution provided at the end was the one
planned at the beginning, the answers were unanimous – the
solution provided at the end was far from the one planned–
“During the several iterations with the client was possible to
identify some initial aspects that after all were not what the
client wanted.” (Implementation Team Member 1), “The
sprint review was essential in adapting the initial solution to
TABLE VI. RESULTS FROM THE INTERVIEWS
1 2
Product Owner
Roles
the client’s vision and needs. The gathered feedback allowed
to iteratively refine the solution so it would become closer to
what the client needed as a solution that properly addressed
the client’s vision.” (Implementation Team Member 3),
“Sprint Review definitely helped.” (Programme Manager).
They all agreed the solution was build according the
client’s needs and confirmed it was adapted several times.
- Objective 3: Ensure that the client understands
the solution and does not show resistance to change.
In a scale from 1 to 5 (1 = strongly disagree; 5 = strongly
agree) 4 out of 6 strongly agreed (5) with the question “Did
the client show an understanding of what were the benefits of
the solution at the end of the programme better than at the
beginning?” and 2 agreed (4).
Although most of the team agreed or strongly agreed
about their (client) understanding of the solution at the end,
the client was not always convinced about the benefits: “At
first, the client showed signs of resistance as showed some
difficulty in understanding the benefits of the solution.
Probably that happened because some had a more technical
background and had problems in understanding the value of
the approach used.” (Implementation Team Member 3). “At
the beginning there was a slight resistance to change that I
consider normal when it changes the way people have worked
all their professional life. However, as they realized the
reasons and benefits that the recommended changes could
bring to the organization, they were no longer so resistant to
change and were much more available and interested in
implementing and promoting such changes.”
(Implementation Team Member 1).
Interviewees
3 4 5 6 7 8 9 10 Total
7.5

Development Team 10
Scrum Master 9.5
Product Backlog Refinement 9.5
Daily Scrum 6.5
Events

Sprint Planning 10
Sprint Review 10
Sprint Retrospective 10
Product Backlog 8.5
Artifacts

Sprint Backlog 9.5

User Story 7
Process Increment 8
Scoping 8.5
Sprint 0 6.5
Cycle
Life-

Phases 2-5 7.5

Phase 6 -7 10

TABLE VII. ANALYSIS FROM OPEN RESPONSE

Comments on each element
Product Owner Some believe it should be responsible for ensuring COBIT 5 programme integrity, some disagreed.
Should also be responsible for change enablement.
Roles

Implementation Team
Scrum Master
Product Backlog Refinement
Daily Scrum Most of the interviewees believe that daily scrum is fundamental and must be done, if not every day, weekly.
Events

Sprint Planning
Sprint Review
Sprint Retrospective

205
 Product Backlog The definition of product should not be limited to processes and this should reflect also product’s backlog
definition.
Consider the possibility of initiating a new project for improve process capability.
Artifacts

Sprint Backlog
User Story User story is relevant and should be used to break resistance among project team members.
Representing tasks with user stories should not be mandatory.
Process Increment It should be provided concrete examples for possible product increments.
Representing tasks with user stories should not be mandatory.
Scoping Scoping should be extended to phases 1,2,3 and 4, eliminating Sprint 0.
Sprint 0
Cycle
Life-

Phases 2-5
Phase 6 -7

X. LESSONS LEARNED
For the authors is clear that this solution is still not the most
accurate, despite it was proved it is feasible considering the
objectives established.
Most of the studies found in literature described complex
systems where Scrum was applied to giant programmes or
very complex projects of software development.
Nevertheless, COBIT 5 is a very broad and complex
framework, which motivated the authors for designing a
simpler solution than the ones found in literature for scaling
scrum.
However, when applied in a real environment, it was
noticed a lack of coordination mechanisms at the programme
level (see Table 8). Still, since there were not many people
involved, this gap had not much impact in the outcome.
Despite all those limitations, and the fact that the solution
was proved to be a simpler version of what it could be,
developing these organizational changes in an iterative and
incremental way, was very effective overcoming some issues
related with senior management commitment, resistance to
change and misaligned solutions from the scope defined.
The use of an iterative approach for developing the
deliverables, especially in phase 5 (Table 1), was crucial to
find the best solutions, especially since the client was very
uncertain about what he was looking for. The opportunity to
participate actively in the development and to give feedback
has contributed to much more accurate deliverables.
The programme was considered a success, although
there is still much work to be done, this first iteration allowed
the authors to verify that developing organizational solutions
with Scrum is very effective in many aspects.

TABLE VIII. OVERVIEW OF LESSONS LEARNED

Interviews Demonstration
Product Owner The Product Owner role is essential to monitor the Is necessary at least one person from the client side to keep the integrity of
product as a whole, with process owners to control the product and he must be at the programme level. Still, process owners
each process/project. are required since they represent the client in each process.
Roles

Implementation
Team
Scrum Master Some believe Scrum Master should be the COBIT A programme manager was included in the programme at UniLEO, and
5 expert and the one performing the scoping part ended up being essential to keep the integrity between the teams. Thus, this
of identifying the issues triggering need to act. role is fundamental for keeping the integrity as a chief scrum master.
Product Backlog
Refinement
Daily Scrum Nowadays, it is possible to make this a mandatory Although it was not mandatory in the solution, team members discussed
meeting despite the distance problems. the project almost every day, and it was essential for solving most
Events

problems.
Sprint Planning At the end of this initiative, when questioned, team members complained
Sprint Review that these common meetings did not help solving their particular problems,
Sprint stating that they were too broad.
Retrospective
Product Backlog Product’ definition should not only be focused on
processes, but in the rest of the enablers.
Artifacts

Sprint Backlog
User Story User Stories should be an optional representation During the demonstration, the tasks had very short and simple
of product backlog items. representations.
Process
Increment
Scoping Should include phases 1,2 and 3. Phases 1,2 and 3.
Sprint 0 Should be eliminated. Was part of scope definition. Not relevant.
Life-Cycle

Phases 2-5 Phases 2 and 3 should are considered part of
scoping. Eliminating sprint 0. Only phases 4 and 5
(of solution’s development) should be addressed
with Scrum.
Phase 6 - 7
Phase 2 was done before the involvement of the rest of the team.
Phase 3 was partially executed with Scrum, although went very well for
the AS-IS assessment, ended up quick since the target was already
established.

206
 XI. CONCLUSION
To conduct this research, it was followed the DSRM process,
which comprises 6 phases of development. Our main
objective was to provide an agile methodology for managing
the programme and eliminate some of the known challenges
of a COBIT 5 such as lack of senior management support,
resistance to change and scope misaligned with requirements.
For demonstrating that the solution can be used to
achieve the proposed goals, the approach was applied in a real
project of GEIT implementation with COBIT 5. As the
project ended, it was validated that Scrum indeed helps
improve implementation problems related with stakeholder
commitment and scope alignment, despite some limitations.
For evaluating the methodology, ten interviews were
performed with both Scrum and COBIT 5 experts and it was
concluded that although it was demonstrated that the solution
is feasible, there are some improvements that can be done in
order to provide a more valuable solution.
A. Limitations
This research has also a few limitations.
The biggest flaws in this research occurred in the
demonstration phase. First of all, the team involved in the
programme was rather small, because of that the scrum
master was the same for every scrum team. A role that was
not addressed by the solution was added, and the third phase
was not completely demonstrated because of the low
capability level of the processes.
Also, although the demonstration was original planned
as a programme initiative, it ended up being just a big project
since the teams began to mix with each other within the
projects due to the reduced number of people involved in the
implementation. This is also an important aspect to consider
for a complete demonstration.
Furthermore, the authors did not perform any previous
COBIT 5 programme using the traditional method to compare
the results, and the literature is very scarce regarding COBIT
5 initiative’ results.
B. Future Work
As future work, the authors intend to make a second iteration
to the proposal based on lessons learned, followed by another
series of interviews to validate the new proposal. This second
iteration will have special focus on the life-cycle, one of the
aspects of the proposal more discussed during the interviews.
REFERENCES
[1] Melville, Kraemer, and Gurbaxani, “Review: Information Technology
and Organizational Performance: An Integrative Model of IT Business
Value,” MIS Q., vol. 28, no. 2, p. 283, 2004.
[2] S. de Haes and W. van Grembergen, “An Exploratory Study into IT
Governance Implementations and its Impact on Business/IT
Alignment,” Inf. Syst. Manag., vol. 26, no. 2, pp. 123–137, 2009.
[3] ISACA, COBIT 5: A Business Framework for the Governance and
Management of Enterprise IT. 2012.
[4] ISACA, Getting Started With GEIT : A Primer for Implementing
Governance of Enterprise IT. 2016.
[5] ISACA, COBIT 5: Implementation. 2012.
[6] S. De Haes, W. Van Grembergen, and R. S. Debreceny, “COBIT 5 and
Enterprise Governance of Information Technology: Building Blocks
and Research Opportunities,” J. Inf. Syst., vol. 27, no. 1, pp. 307–324,
2013.
[7] Manifesto for agile software development, 2001,
http://agilemanifesto.org/. Last accessed April 12, 2018
207
[8] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A
Design Science Research Methodology for Information Systems
Research,” J. Manag. Inf. Syst., vol. 24, no. 3, pp. 45–77, 2007.
[9] A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design Science in
Information Systems Research,” MIS Q., vol. 28, no. 1, pp. 75–105,
2004.
[10] Y. Bartens et al., “A visualization approach for reducing the perceived
complexity of COBIT 5,” in Lecture Notes in Computer Science
(including subseries Lecture Notes in Artificial Intelligence and
Lecture Notes in Bioinformatics), 2014, vol. 8463 LNCS, pp. 403–407.
[11] Y. Bartens, S. De Haes, Y. Lamoen, F. Schulte, and S. Voss, “On the
way to a minimum baseline in IT governance: Using expert views for
selective implementation of COBIT 5,” Proc. Annu. Hawaii Int. Conf.
Syst. Sci., vol. 2015–March, pp. 4554–4563, 2015.
[12] Y. H. Kwak, “Brief History of Project Management,” Story Manag.
Proj. An Interdiscip. Approach, no. 1916, pp. 1–9, 2000.
[13] J. Etzler, “IT governance according to COBIT,” Stock. Sweden R. Inst.
Technol., 2007.
[14] M. Nicho, “Towards a Taxonomy of Challenges in an Integrated IT
Governance Framework Implementation Governance Framework
Implementation,” J. Int. Technol. Inf. Manag., vol. 25, no. 2, pp. 1–32,
2016.
[15] S. De Haes, R. Debreceny, and W. Van Grembergen, “Understanding
the Core Concepts in COBIT 5,” ISACA J., vol. 5, no. 1, pp. 1–8, 2013.
[16] K. Schwaber and J. Sutherland, “The Definitive Guide to Scrum: The
Rules of the Game,” 2017.
[17] M. Špundak, “Mixed Agile/Traditional Project Management
Methodology – Reality or Illusion?,” Procedia - Soc. Behav. Sci., vol.
119, pp. 939–948, 2014.
[18] D. J. Fernandez and J. D. Fernandez, “Agile project management -
agilism versus traditional approaches,” J. Comput. Inf. Syst., vol. 49,
no. 2, pp. 10–17, 2008.
[19] ISACA: COBIT 5 Enabling Processes, 2012.
[20] ISACA: COBIT 5 Enabling Information, 2013.
[21] C. Thiemich and F. Puhlmann, “An agile BPM project methodology,”
in Lecture Notes in Computer Science (including subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics),
2013, vol. 8094 LNCS, pp. 291–306.
[22] M. Cohn, User Stories Applied: For Agile Software Development.
2014.
[23] PMI, A Guide to the Project Management Body of Knowledge
(PMBOK Guide) - 6th ed. 2017.
[24] S. Denning, “How to make the whole organization Agile,” Strateg.
Leadersh., vol. 43, no. 6, pp. 10–17, 2015.
[25] A. M. M. Hamed and H. Abushama, “Popular agile approaches in
software development: Review and analysis,” Proc. - 2013 Int. Conf.
Comput. Electr. Electron. Eng. ’Research Makes a Differ. ICCEEE
2013, no. August 2013, pp. 160–166, 2013.
[26] D. West, “Water-Scrum-Fall Is The Reality Of Agile For Most
Organizations Today,” Appl. Dev. Deliv. Prof., pp. 1–15, 2011.
[27] D. K. Rigby, J. Sutherland, and H. Takeuchi, “Embracing agile,”
Harvard Business Review, vol. 2016, no. May. 2016.
[28] R. S. Debreceny, “Research on IT Governance, Risk, and Value:
Challenges and Opportunities,” J. Inf. Syst., vol. 27, no. 1, pp. 129–
135, 2013.
[29] Project Management Institute, “Success Rates Rise 2017 9th Global
Project Management Survey,” PMI’s Pulse Prof., p. 32, 2017.
[30] S. Schlauderer, S. Overhage, and B. Fehrenbach, “Widely used but also
highly valued? Acceptance factors and their perceptions in water-
scrum-fall projects,” 2015 Int. Conf. Inf. Syst. Explor. Inf. Front. ICIS
2015, pp. 1–19, 2015.
[31] M. Laanti, “Implementing program model with agile principles in a
large software development organization,” Proc. - Int. Comput. Softw.
Appl. Conf., no. January 2008, pp. 1383–1391, 2008.
[32] Scaled Agile, SAFe, https://www.scaledagileframework.com/#. Last
accessed May 22, 2018
[33] S. L. T. McGregor and J. A. Murnane, “Paradigm, methodolog34y and
method: Intellectual integrity in consumer scholarship,” Int. J. Consum.
Stud., vol. 34, no. 4, pp. 419–427, 2010.
[34] E. Hossain, M. A. Babar, and H. Paik, “Using Scrum in Global
Software Development: A Systematic Literature Review,” 2009
Fourth IEEE Int. Conf. Glob. Softw. Eng., pp. 175–184, 2009.