agileBIResearch

Agile BI: recommended by the experts,
but is it used in the real world?
© Petr Podrouzek
February 2014

Abstract
Agile frameworks are becoming favourite project management methodologies in OLTP systems
development. The question is whether the same stands for OLAP (business intelligence/data
warehousing) systems. In this paper, the author reviews existing agile BI literature and interviewees
10 BI practitioners to determine how much is agile used to manage BI projects. After answering this
question, the paper focuses on the risks of applying agile on BI projects. The issue of possible risks
and pitfalls of going agile with a BI project is rarely discussed in the literature. The results show the
biggest risk is associated with using agile methodology which does not respect specifics of BI
projects. This could be mitigated by using specific agile BI methodology or customizing “out of the
box” agile methodology to deal with the complexity of BI projects. Incompatibility of the data
modelling techniques with agile methodology or insufficient training to use agile on BI projects are
among other risks. For each risk, there is a mitigation provided based on analysis of interviews with
BI practitioners.
2

Table of Contents
1 Introduction.......................................................................................................................................5
2 Literature review...............................................................................................................................7
3 Objectives and research methods....................................................................................................12
4 Conceptual framework....................................................................................................................16
5 Findings...........................................................................................................................................19
6 Analysis...........................................................................................................................................25
7 Conclusion.......................................................................................................................................29
8 References.......................................................................................................................................31
9 Appendix A: Transcript of interviews..............................................................................................32
10 Appendix B: Categorization of I4 answers....................................................................................49
3

Illustration Index
Illustration 1: Basic BI infrastructure configuration............................................................................7
Illustration 2: Waterfall model on the left (Avison and Torkzadeh 2010, p.16) and agile approach on
the right (DeSarra 2012, p.10)..............................................................................................................8
Illustration 3: Want to use agile, but it did not work properly............................................................16
Illustration 4: Ishikawa diagram (Bullington 2012, p.18)..................................................................17
Illustration 5: Response rate...............................................................................................................19
Illustration 6: Agile methodologies used............................................................................................21
Illustration 7: Distribution of answers by dimensions........................................................................21
Illustration 8: Who initiates agile?......................................................................................................24
Illustration 9: Agile project management tools usage........................................................................24
Index of Tables
Table 1: Risks of using agile on a BI project......................................................................................29
Table 2: Links between answers and dimensions...............................................................................49
4

1 Introduction
1.1 Research question
The title of this research project is “Agile BI: recommended by the experts, but is it used in the real
world?” and the task is to investigate how are agile development frameworks applied in business
intelligence projects. The author of this report has been working on business intelligence projects
for more than 6 years now and although there have been lot of rumours about agile approach to
development he has never seen it use in a business intelligence project. Last year the author worked
on a project which started with an agile approach, but the agile methodology was quickly
abandoned for the traditional waterfall model. The waterfall model starts with collecting
requirements from the customers, then the data model is developed, followed by data sourcing and
development of ETLs1
. Finally the reports are delivered to the customers. However, it is a painful
process with constant rework, redesign and delays. To mitigate these problems, business
intelligence experts recommend using agile approach instead of waterfall.
The author of this research lately dedicated significant time to studying relevant BI project
management literature and it became obvious that most authors explain clearly why waterfall is not
working for data-warehousing projects and recommend using agile methodology instead. Yet, the
author has not worked on a single business intelligence project that would utilize agile approach and
all the projects have been managed using traditional waterfall model. The contrast between what is
used and does not work and what could work better is the main motivation for this project. The
research question is formulated as “How often are agile development methods used in BI projects
and what are the risks when the BI development team decide to go agile?”. The central research
question was divided into the following set of research questions:
Q1. How often is agile development used in business intelligence projects?
Q2. What are the risks which can lead to unsuccessful implementation of agile methodology in
a BI project?
Q3. How to deal with these risk?
Q4. What are the most often used agile frameworks in business intelligence projects?
Q5. Does the initiative of using agile come from the business or from the IT?
1 ETL stands for Extract, Transform and Load – process of loading the data from the source system and storing them
in the data-warehouse.
5

1.2 Motivation
As indicated in the paragraph 1.1, the author of this report works as a business intelligence
developer. It is his own professional interest to deepen knowledge in this field. In addition to this,
there are two other reasons why to carry out research in the area of agile BI:
1. Business intelligence is undergoing an intense development as it stays in the focus of many
CFOs and is one of the top areas of IT investments (Van Decker & Sinnett 2013).
2. Agile methodology is well established in the area of OLTP2
systems development but
organizations only recently started to apply agile approach to BI projects (DeSarra 2012,
p.8).
This means that the topic of agile BI is interesting from both theoretical as well as practical
perspective and is also evolving rapidly. Motivation to carry out research in the area of agile BI
stems from all the reasons given above.
1.3 Structure of the report
While Chapter 1 introduces the project topic, research question, motivation for the research as well
as the structure of the report, Chapter 2 provides critical review of the literature from the area of
agile BI. It is important to note, that the literature about agile applications in business intelligence
projects is scarce. There are just few books dedicated to agile BI and the same stands for journal
articles. This also justifies the research project – there is a lot to explore in the agile BI world. Apart
from that Chapter 2 includes definitions of the basic terms. Chapter 3 discusses the research
objectives in detail. Chapter 3 also introduces the research methods used in this project. Description
of the conceptual framework based on the theory of root problem analysis is the backbone of the
Chapter 4. Data from the real world will be collected through semi-structured interviews with
business intelligence developers and agile BI experts. Chapter 5 contains results of the data
collected. Only the most interesting findings are presented; findings that contribute to answering the
research question. Chapter 6 contains detailed analysis of the data collected. The analysis compares
theory with the empirical evidence. Finally, the outcome of the research is discussed in Chapter 7.
2 OLTP stands for Online Transaction Processing; contrary to OLAP, which stands for on-line analytical processing,
OLTP usually involves many more atomic updates, inserts and deletes; OLAP usually performs bulk inserts and is
optimized for massive data retrieval required for reporting
6

2 Literature review
2.1 Definitions of the basic terms
Business intelligence (BI) is “an umbrella term that includes the applications, infrastructure and
tools, and best practices that enable access to and analysis of information to improve and optimize
decisions and performance” (Gartner.com 2013). As stated in the definition, BI is facilitated through
numerous applications and tools. In the simplest terms, BI would consist of data loading layer or
ETL, persistence layer (data-warehouse or data-mart) and finally presentation layer (reporting tools
for business users).
Source systems will not be discussed here. These are usually out of the control of the business
intelligence team. BI team only needs to agree on the format of the data extracts from the source
systems with the source system owners. Data loading layer is the place where data is loaded from
the extracts, cleansed, transformed into the required format and finally loaded in the data-
warehouse. Data persistence layer is a database structure, where the data is stored in a denormalised
schema, which allows quick data retrieval. This is a big difference to OLTP systems, which usually
require quick data entry or update. Finally data is presented through data presentation layer which is
typically only part of the BI infrastructure the user interacts with. The interaction is facilitated
through reporting tools allowing the user design her own reports using WYSIWYG3
editor.
Agile is a set of “software development methods based on iterative and incremental development,
where requirements and solutions evolve through collaboration between self-organizing, cross-
functional teams.” (Wikipedia 2013) The words iterative and incremental are crucial and distinguish
3 WYSIWYG stands for What You See Is What You Get; user friendly interface allows users to design their reports
without knowledge of any data query language
7
Illustration 1: Basic BI infrastructure configuration
ETL
Data-warehouse
Reports
Source systems Data loading layer
Data persistence
layer
Data presentation
layer
Reports

agile methods from waterfall model. Waterfall model consists of several phases and the developers
move from one phase to another in linear fashion; they do not go back to the previous phases (or at
least they should not go back but they often do and this causes problems). On the other hand, agile
approach is all about delivering small pieces of functionality over and over. This means that the
developers are moving in a circle and they go through development and testing phases (these two
phases are just examples) multiple times. The difference between waterfall and agile approach can
be clearly seen on the illustration 2 below. Agile approach was build around following 4 basic
values (Agilemanifesto.org 2013):
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
Agile BI is a term that appeared recently and first journal article mentioning agile BI comes from
the year 2005 and first book published on this topic comes from the year 2008. Currently there is
not a single definition of agile BI. Hughes (2013) considers agile BI to be application of various
styles of iterative and incremental development tailored to challenges of data integration and
presentation. Hill et al. (2009) even more emphasizes the fact that the authors of the agile methods
were not BI or data-warehousing (DWH)4
experts so these methods were not developed to support
this kind of projects. Changes to the agile methodology are required so it can be applied to BI
projects. Completely differently understands agile BI Evelson et al. (2010). He sees agile BI as a
4 While some authors differentiate between BI and DWH projects, this is not the case of this report; in this report BI
and DWH projects will be synonyms
8
Illustration 2: Waterfall model on the left (Avison and Torkzadeh 2010, p.16) and agile approach on
the right (DeSarra 2012, p.10)
Initiating
Planning
Developing
Implementing
Closing

technical concept, where development tools support automatic meta data generated BI applications.
This means that when a change occurs, meta data is changed and this change is cascaded through all
the BI layers. In this case agility is not achieved through project management methods but rather
through technical solution.
In this research project, the first understanding of agile BI is adhered to. Agile BI is understood as a
project management concept based on agile software development methodology but with some
significant changes to accommodate the specifics of business intelligence and data-warehousing
projects.
2.2 Why waterfall fails for BI projects?
According to DM Review magazine study the average deployment time of a BI project was 17
months and the failure rate was nearly 65% (Ericson 2006, cited in Hughes 2013, p.9). These
numbers come from the year 2004. Agile manifesto was introduced in the year 2001
(Agilemanifesto.org 2013) and it is unlikely that the new methodology would make its way so
quickly to BI project management. Especially as it was developed by programmers not BI
developers. Although it cannot be concluded that waterfall methodology is the reason why many of
these BI projects failed, it gives good starting point for theoretical discussion about the suitability of
the waterfall model for BI projects.
Moss (2013) devotes whole chapter to explain why the traditional development methodology,
namely waterfall, does not work when used on BI projects. She puts forward the argument that
waterfall methodology was developed in 1970's and in that time, concept of data governance and
data integration did not exist. And this is a significant problem. Data integration is the very essence
of BI and DWH projects. These projects are all about integrating data from various data sources.
Another point Moss makes is, that contrary to OLTP systems, where significant amount of the work
is to write code, this is not the case of BI projects. Most of the work is the data analysis and data
integration which is supported by partly WYSIWYG tools rather than pure coding (although some
code, usually data definition/manipulation language like SQL, is used).
However, data orientation of BI projects is not the only problem which waterfall cannot easily deal
with. The other is the fact that waterfall is linear and all the requirements needs to be collected first
at the very beginning of the project. Getting all the requirements right the very first time is
becoming more and more difficult as the project's complexity increases. Contrary to OLTP software
where applications can be decoupled and delivered one by one, data-warehousing project usually
aims to deliver multiple applications at once as it is going to support multiple reporting solutions for
9

different teams and departments in the company (Hughes 2013). This argument is supported by the
fact that OLTP systems can be developed on one highly consolidated platform5
but BI application
will utilize various platforms from different vendors for different BI layers6
. The complexity of the
BI projects and amount of technologies used simply makes it impossible to have complete
requirements covering all the customer's needs before hand and never update those again as is
required by the waterfall model.
There is another problem with the requirements. This time it is not their completeness but their
correctness. Let's look on the problem from the perspective of the customer who is being asked
what she requires from the BI application. Reporting application is all about data manipulation, yet
the data is not ready in the data-warehouse. The customer needs to imagine what she would do with
the data. So the typical customer (knowledge worker) would need to think of all the possible ways
how she would like to manipulate the data without actually having access to the data. This means
that getting meaningful artefacts (in the form of traditional documentation of requirements) is not
achievable (Brobst et al. 2008, p.14). The customer would simply supply wildly inaccurate
requirements.
2.3 Agile BI methodologies
In the previous paragraph, it was shown that waterfall model is a poor choice for BI projects. It
proves troublesome to get all the requirements correct and complete the first time (Hughes 2013;
Brobst et al. 2008). The next important issue is that waterfall has never been designed for data
integration projects but for projects where main focus is on coding functionality (Moss 2013). Many
experts in the field of BI projects management recommend using agile approach. These experts
agree on the fact, that agile will have to be altered for the purposes of business intelligence projects.
Hughes (2013) assumes that in practice “out of the box” agile is unlikely to manage breadth and
depth of data-warehousing projects. Very similar premise is advocated by Moss (2013, pp.59-61).
She states that agile methods were developed by coders and do not take into account the complexity
of data integration. Moss also lists activities which will need to be incorporated into agile to fit the
needs of BI project. Here is a list of selected ones:
• Analysing data sources, collecting meta-data and business rules.
• Modelling the data from an enterprise business perspective.
5 Examples can be .NET from Microsoft or Java from Sun.
6 Any database engine can be used for the data persistence layer, there are multiple vendors offering ETL tools (for
example Microsoft or Informatica). Finally, there is a whole range or reporting suites (Business Objects, Qlikview,
Microstrategy etc.)
10

• Standardizing and integrating the data based on enterprise model.
Based on these activities Moss (2013) has developed BI specific agile methodology called Extreme
Scoping. Similarly Corr and Stagnitto (2012) designed agile data modelling method named BEAM7
.
Hughes (2013) on the other hand prefers using Scrum8
as a starting point and updates it to fit the
complexity of data-warehousing projects. It is not task of this paper to discuss any of these
methodologies in detail. The methodologies were mentioned here to illustrate the fact that most
agile BI experts tend to alter existing agile approach and tailor it for BI projects purposes.
2.4 Conclusion
On one hand, waterfall is not working for BI projects and there are well developed agile
methodologies that could replace it. On the other hand, the author of this project has not worked on
any BI project that would utilize any of these methodologies. Hughes (2013, p.3) also expresses
concerns in the beginning of his book that while agile methods are increasingly popular style of
OLTP systems programming, they have not been employed nearly as much for data-warehousing
projects. This mismatch leads to an obvious question:
• Is agile used in BI projects at all in the real world? If yes, how much is it used?
The literature review proved that there are agile BI methodologies that could be used for BI
projects. However, the literature rarely discuss the problems the development team can face when
they decide to use agile methodology. Insufficient focus on the problems of agile implementation
will be addressed in this research project through the following questions:
• What are the risks which can lead to unsuccessful implementation of agile methodology in a
BI project?
• How to deal with these risk?
7 BEAM stands for Business Event Analysis & Modelling
8 Scrum is one of the first agile methodologies
11

3 Objectives and research methods
3.1 Research project objectives
The objective of this project is to carry out research in the area of agile BI. Specifically, the primary
objective of this paper is to determine what is the level of penetration of the agile methodologies in
BI projects and what are the risks when team decides to use agile in a BI project. How to mitigate
these risks is also part of this objective. The primary objective will be achieved by answering
following research questions:
Q1. How often is agile development used in business intelligence projects?
Q2. What are the risks which can lead to unsuccessful agile implementation in a BI project?
Q3. How to deal with these risks?
The task is to answer these questions from a very practical perspective. The outcome should be list
of problems which one can encounter while going agile with a BI project and advice how to
overcome these issues. The secondary objective is to find out some specific details about how BI
teams use agile and this will be achieved by answering following questions:
Q4. What are the most often used agile frameworks in business intelligence projects?
Q5. Does the initiative of using agile come from the business or from the IT?
Most of the effort will be dedicated to accomplishing the primary objective. The secondary
objective will be answered through very specific questions and as such will provide supporting
arguments for the primary objective.
3.2 Research methods
Firstly, the literature will be reviewed which will provide solid theoretical foundation for further
empirical investigation. Research objectives and questions has been carefully crafted to avoid
addressing the same issues which has already been discussed in the existing literature. Semi
structured interviews is the method used to collect real world data. The interviews will be carried
out with BI practitioners using email, telephone (or VoIP) and one-to-one sessions. Semi structured
interviews has been selected because of the following reasons:
• As indicated in the Chapter 1 (paragraph 1.2) and the Chapter 2 (various definitions
discussed in paragraph 2.1) the topic of agile BI is evolving quickly and could be considered
emerging rather than consolidated; this means that the research method needs to provide
12

high level of flexibility and experts will be asked variety of questions based on their
experience with agile BI.
• It is expected that different interviewees will understand questions differently and answer
those from different angles. Follow up questions will be necessary if the answer is not
sufficient or on the other hand introduces another questions; this is exactly what semi
structure interviews allow.
• The author of this research believes that the rate of responses can be higher with semi-
structured interviews than with a standardized questionnaire as the latter one is too
standardized and does not allow customization of the questions. Interviews might get the
participants more involved and interested which will increase the response rate.
Semi-structured interview questions and how they link to answering the research questions:
I1. Do you know what agile BI is? If yes, how would you define it?
◦ Links to answering research question Q1.
I2. On how many BI projects, which have utilized agile methodology, have you participated on?
◦ Should be expressed in percent; if interviewee has not worked on a single agile BI
project, the interview finishes.
I3. Which agile methodology have you used the most while working on BI projects?
◦ Only one methodology should be provided.
I4. Please name three problems (based on your experience) which can cause failure of an agile
methodology implementation on a BI project.
◦ These should be obstacles the team can face while adopting agile approach and which
can severely hinder implementation of agile methodology or even cause failure of the
agile implementation in a BI project.
I5. For the problems from question (4), please describe shortly, how have you (or would you)
address those issues.
13

◦ Answer should be provided for each problem from question (4).
Follow up questions:
I6. Does the initiative of using agile come from the business or from the IT (BI team)?
◦ Links to answering research questions Q3, Q4, Q5.
I7. Do you have any preferred tools for agile BI management?
◦ Links to answering research questions Q3, Q4.
I8. Other follow up questions will arise during the interview.
In total, 28 BI practitioners has been nominated for the interviews. These can be divided into two
groups:
• Group A: BI developers, analysts or managers with whom the author of this research worked
and knows their professional background (14 nominated interviewees).
• Group B: agile BI experts and consultants who has written journal articles or books about
agile BI (14 nominated interviewees).
It is not expected that all of them will want to participate in this research however the goal is to
interview equal number of BI practitioners from both groups. The selection of the BI practitioners
for the interviews is justified as follows:
• None of the nominated interviewees were selected by random and each has a proven history
of working on BI projects to provide relevant answers.
• Group A consists mainly from long term employees on comparable level of seniority of one
or very few companies; Group B on the other hand contains agile BI consultants and
freelancers who provide services to many companies (again on a comparable level of
seniority). Significant differences between answers (group A versus group B) to question I2
can indicate that while agile BI is popular among highly experienced professionals who has
published about the topic it might have not gotten to the “ordinary BI folk”. Although it is
not the aim to analyse the answers by groups, for I2 this will be done.
• For the rest of the questions (I1, I3 – I8) the groups will not be divided; the reason is that
once interviewee from group A answers I2 positively (= worked on an agile BI project) then
it is expected she can contribute to the other questions the same way as anyone from the
14

group B. It is actually desired not to divide answers for the questions I3 – I8 by groups as
the aim of Q2 – Q5 is to provide overview of agile BI from various angels. This variety will
then be dealt with using conceptual framework (Chapter 4). This means that group A and B
are actually more sources of the nominated interviewees rather than something that should
determine the way how the data will be analysed.
15

4 Conceptual framework
The major concepts of this paper has been defined and discussed in the Chapter 2. These are:
1. Business intelligence – applications as well as infrastructure supporting decision making in
an organization through collecting data from various data sources.
2. Agile methodology – iterative and incremental software development methodology which
tries to address some of the issues which arise when waterfall development model is used.
3. Agile BI – agile methodology tailored for BI projects as suggested by Moss (2013) and
Hughes (2013).
The objectives of this research are to examine whether agile methodology is used in BI projects and
what are the risks that the developers might face when they decide to use agile in a BI project.
These risks can lead to agile not working very well or even being refused by the development team
(author of this research has experience like this). Ultimate outcome can be a failure of the project
due to incorrect implementation of an agile methodology. In the beginning, the development team
decides to use agile methodology and regardless of the specific outcome (project failure, delays
etc.), the result was that the agile methodology was not working properly on a BI project.
Now the task is to find out what ? means. At the end of the process there is a problem (agile did not
work properly on a BI project) and it needs to be found out what caused it. On complex BI projects
there might be multiple causes of a negative outcome. Basically, this is a root cause analysis
problem. One of the frameworks that could be used is Ishikawa diagram which originates from
quality management.
Ishikawa diagram (also called fish bone diagram) is a problem solving tool which can help identify
and discuss all potential causes of an effect (Perry 2006). The causes can belong to different
dimensions (measurements, materials, people, environment, machines and processes) as it can be
seen on the figure 4 from Bullington (2012). These are the default dimensions which come from the
16
Illustration 3: Want to use agile, but it did not work properly.
Decision to use agile
on a BI project
Agile not working
well on a BI project?

manufacturing world9
and are not fully suitable for analysis of qualitative data in this research.
For the purpose of analysis of the data collected using semi structure interviews, some changes to
the default dimensions of the fish bone diagram will be made. This approach is feasible as defined
and proven methodology is used and very slightly changed to fit the needs of this research project.
List of proposed changes:
1. Machines and materials will be merged into one dimension called tools – machines and
materials come from the manufacturing world; the parallel in software engineering would be
tools (development tools, project management tools or methodologies).
2. Management dimension will be added – as we are dealing with agile as a project
management methodology, adding management dimension seems to be appropriate.
Finally, the data from the semi-structured interviews will be analysed using Ishikawa diagram with
the following dimensions:
D1. Environment – the conditions under which the agile BI project runs (e.g. culture of the
company or the team).
D2. Management – representing various levels of management which has an influence on the
project (e.g. operational day to day task assigning to the team members).
9 As it can be seen from some of the dimensions like materials and machines.
17
Illustration 4: Ishikawa diagram (Bullington 2012, p.18)

D3. Measurements – concerns measurement of the performance of the agile methodology
implementation (e.g. deadlines being met as a way to measure performance of the project
management).
D4. People – people who are involved in the process (e. g. developers).
D5. Processes – processes supporting the agile software development (e. g. HR process
supporting further education of the developers).
D6. Tools – software tools (e.g. project management tools like JIRA) but also methodologies
(e. g. Pomodoro method for time management).
18

5 Findings
Full transcripts of the interviews can be found in the Appendix A. Only the most insightful answers
(in italic) will be presented in this chapter.
5.1 Response rate
In total 28 nominated interviewees were contacted. The response rate is as follows:
• 36% (10 interviewees) did not respond at all.
• 14% (4) responded, but concluded they cannot contribute to the topic (responded but did not
want to carry on); most often these interviewees mentioned they do not work on BI projects
any more.
• 14% (4) replied and wanted to participate in the research but did not come back with
answers (responded but interview did not take place); these interviewees were sent 2
reminders to answer.
• 36% (10) responded in full which means answering all the compulsory questions and some
follow up questions as well.
Although the intention was to carry out the interviews as person-to-person interaction (either real or
using VoIP) this proofed to be nearly impossible as all the interviewees asked for the questions to be
sent in an email and would not allocate any time for person-to-person discussion.
5.2 Question I1
Question I1 wording:
• Do you know what agile BI is? If yes, how would you define it?
The majority of the answers say that agile BI is application of agile approach on BI projects which
19
Illustration 5: Response rate
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
36% 14% 14% 36%
Did not respond at all Responded but did not want to carry on
Responded but interview did not take place Responded in full

means running BI project in an iterative and incremental way.
• “An approach to the development of a BI solution that is evolutionary (iterative and
incremental) and collaborative in nature.” (Ambler 2014, email interview, 15/1/2014)
• “It has to be BI solutions delivered using the core values and principles of the agile
manifesto.” (Corr 2014, email interview, 8/1/2014)
One interviewee provided answer where he emphasized the fact that agile methods needs to
embrace specifics of BI projects which is what the literature (see Moss (2013) with Extreme
Scoping, Hughes (2013) or Corr and Stagnitto (2012) with BEAM) suggests.
• “Agile BI is an iterative and spiral development approach that embraces Agile principles but
has been modified for the unique characteristics and subtleties associated with BI projects.”
(Gallo 2014, email interview, 6/1/2014)
5.3 Question I2
• On how many BI projects, which have utilized agile methodology, have you participated on?
As stated in the Chapter 3, answers to I2 will be divided by group A and B. Author of this research
is fully aware that averaging the answers which are in percentages is gross simplifications
(averaging percentages would work only if all interviewees participated on the same number of
projects which were equally complex). However, the groups A and B consists of interviewees on the
same level of seniority so it can be assumed that the would work on a similar level and amount of
BI projects and averaging the answers will then provide asymptotically correct answer.
• average for Group A: 43 %
• average for Group B: 80 %
• overall average: 62 %
5.4 Question I3
• Which agile methodology have you used the most while working on BI projects?
Starting with question I3, answers from 9 interviewees will be contained as Mr. Peake stated that he
has not been using agile on BI projects and finished with answering I2.
20

• BEAM, Disciplined Agile Delivery, Extreme Scoping and Spiral methodology is each
preferred by 1 interviewee (11%).
• The most common agile methodology of choice was Scrum/Scrumban with 56% (5
interviewees).
5.5 Question I4 and I5
Questions I4 and I5 wording:
• (I4) Please name three problems (based on your experience) which can cause failure of an
agile methodology implementation on a BI project.
• (I5) For the problems from question (4), please describe shortly, how have you (or would
you) address those issues.
Answers to questions I4 and I5 will be presented together. The reason is that to fully understand the
risk (I4) the mitigation (I5) of the risk must be known. Risks will be divided into dimensions as
defined in the Chapter 4. This approach will be a good starting point for analysis and discussion
which will be presented in the next chapter. In the following text, only examples of the risks are
listed (Appendix A contains all answers including risk mitigation). All the links between answers
and dimensions can be found in the Appendix B.
Environment (D1)
• “Traditional mindset. Too many data professionals are stuck in 1970s thinking.” (Ambler
21
Illustration 6: Agile methodologies used
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
11% 11% 11% 56% 11%
BEAM Disciplined Agile Delivery Extreme Scoping
Scrum/Scrumban Spiral
Illustration 7: Distribution of answers by dimensions
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
19% 26% 4% 26% 7% 19%
D1 D2 D3 D4 D5 D6

2014, email interview, 15/1/2014)
• “Lack of participation by the business people. IT can only be agile if their users actively
participate on the projects.” (Moss 2014, email interview, 13/1/2014)
Management (D2)
• “Management won't commit to a firm feature set per sprint, therefore good deadlines won't
be set.” (Ellis 2014, email interview, 3/1/2014)
• “Having developers run the projects instead of data management professionals. 80% of the
work on enterprise-class data integration projects like EDW/BI is data management; only
20% of the work is data delivery (reports and apps). Enterprise-class BI projects are data
projects, not development projects.“ (Moss 2014, email interview, 13/1/2014)
Measurements (D3)
• “Measurements of project progress and success is measured still using traditional waterfall
approach especially on completeness, where Agile is more flexible in terms of
“completeness” due to it’s nature of using an iterative approach.” (Chu 2014, email
interview, 14/1/2014)
People (D4)
• “Poor skills. There is a very serious lack of testing skills, let alone database refactoring, test
driven development, or other skills that are very useful for agile development. ” (Ambler
• “Inexperienced project members concerning Scrum-know-how.” (Schwarz 2014, email
interview, 6/1/2014)
Processes (D5)
• “Not starting agile. Leaving agile to the development/testing and not applying it to analysis
and design. It very difficult to go agile mid project.” (Corr 2014, email interview, 8/1/2014)
Tools (D6)
• “Inmon or Kimball data modelling techniques, because they lead to data warehouses that
cannot be easily redesigned for new requirements once they’re loaded with data.” (Hughes
22

• “Heavy project administration.” (Gallo 2014, email interview, 6/1/2014)
5.6 Question I6
• Does the initiative of using agile come from the business or from the IT (BI team)?
Most of the interviewees provided direct answer stating either IT or business:
• “Always from IT! This is understandable since agile was initially used in development
projects. I have yet to work on a project that has business owners/project managers that use
agile throughout and not only when dealing with IT/development environments.” (Chu
• “Generally, it’s the business who sees the value in agile. IT, the PMOs in particular, seem to
be adverse to the idea. Not sure why this is the case.” (Gallo 2014, email interview,
7/1/2014)
Others on the other hand provided less conclusive answer (in the chart these are under
inconclusive):
• “In my experience, the business won't care what particular methodology is used. Their main
concern is (1) Who from the business side needs to be involved, and for how long; (2) is
there a cost difference between the methods being considered. I.T. will want to know how
long one will take versus the other, and if one requires a different skill set over the other.”
(Tate 2014, email interview, 20/1/2014)
From quantitative point of view:
• 22% of interviewees (2) claimed that business initiates the agile approach.
• 56% (5) on the other hand say that the agile is introduced by IT.
• 11% (1) provided inconclusive answer.
• 11% (1) interviewee did not answer.
23

5.7 Question I7
• Do you have any preferred tools for agile BI management?
Unfortunately this question generated so varying answers it is desirable to group these together by
some common denominator. This denominator is whether interviewee uses a preferred tool or does
not use any specific tool for supporting agile development.
• 33% (3) of the interviewees do not use any specific agile project management tool or use
traditional project management tools.
• 44% (4) on the other hand use specific agile project management tool (like JIRA or
Agilizen).
• 22% (2) has not answered.
5.8 Follow up questions
The follow up questions were specific for each interviewee and the answers will be used to support
the analysis in the next chapter. Again, full answers to follow up questions can be found in the
Appendix A.
24
Illustration 8: Who initiates agile?
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
22% 56% 11% 11%
Business IT Inconclusive Did not answer
Illustration 9: Agile project management tools usage
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
33% 44% 22%
No specific tool Uses specific tool to support agile development
Did not answer

6 Analysis
In the previous chapter findings of the research have been presented. In this chapter conceptual
framework from the Chapter 4 will be applied on the collected data. The findings were presented
for each of the interview questions (I1 – I7) separately. The analysis, on the other hand, will be
performed for each of the research questions (Q1 - Q3). Links between interview and research
questions were described in the Chapter 3. Secondary objectives (Q4 and Q5) will be not be
analysed separately but as a part of analysis of primary objective questions Q1, Q2 and Q3.
6.1 Research question Q1
Research question (objective) Q1 wording:
• How often is agile development used in business intelligence projects?
From the findings it is obvious there is a significant difference between the answers of group A
(43% projects used agile methodology) and B (80%) to the question I2. This indicates that while
agile is used heavily by the agile BI experts (group B) it is not so much used by the BI project
managers or developer (group A). Although it is obvious that agile BI experts use the methodology
often, much lower usage by BI developers means that agile BI is not used as much among ordinary
(someone who considers themselves BI expert but not an agile BI expert) BI practitioners.
6.2 Research questions Q2 and Q3
Research questions (objectives) wording:
• (Q2) What are the risks which can lead to unsuccessful agile implementation in a BI
project?
• (Q3) How to deal with these risks?
To answer research questions Q2 and Q3 conceptual framework will be utilized. In the Chapter 5
the answers were categorized by different dimensions defined by the conceptual framework. It
shows that D3 (Measurements) and D5 (Processes) were the least common sources of risk. This
means that the analysis needs to focus on the other 4 dimensions to identify the major risks of
applying agile on a BI project.
In the case of D1 (Environment) the common theme of the answers is prevailing traditional mindset.
This is true not just for IT experts as “too many data professionals are stuck in 1970s thinking”
(Ambler 2014, email interview, 15/1/2014) but also it is a case of business representatives because
25

“many clients have been adverse to this as they feel their traditional methods “work”.” (Chu 2014,
email interview, 14/1/2014). As a mitigation of these problems, most of the interviewees suggest
continuously changing the way how IT as well as business representatives think about IT project
management. Mr. Chu suggests to “promote and continuously communicate to users and
specifically management the benefits of Agile through rapid deliverable and show value through
these.” (Chu 2014, email interview, 14/1/2014) and Mr. Ambler emphasizes the importance of
education as his team when working on a project “mentor and coach the existing staff to give them
more modern skills” (Ambler 2014, email interview, 15/1/2014). Mrs. Moss explains that she
always “insist on a business representative from the business community (not IT) to be a member of
the core team, which is also the project management team” (Moss 2014, email interview,
13/1/2014) to prevent lack of interest from the side of the business considering that without
participation of the business people agile cannot work. This is an important point because from
question I6 which links directly to Q4 it is obvious that IT project team members are the ones who
initiates usage of agile (after all it is a software development methodology) and thus it will be most
likely responsibility of the IT representatives to change the environment in the organization. This
means that IT department will need to have members with good communication skills who can
persuade business about advantages of agile. If there is a lack of such people then using agile might
be endangered by lack of commitment or understanding form the side of the business.
D2 (Management) was the dimension that together with D4 (People) contains most of the risks
identified by the interviewees. There is one major theme to which most of the answers in D4
dimension can be assigned. This is a risk of improper task and time management. Mr. Ellis says he
often encounters problem of “the feature sets are too large, and then deadlines are missed.” (Mr.
Ellis 2014, email interview, 3/1/2014) which is basically a task management problem. Mr. Tate on
the other hand is concerned about time management as he often sees “insufficient time to
understand requirements” or “insufficient time allocated for user acceptance testing” (Tate 2014,
email interview, 20/1/2014). To deal with these risks Mr. Ellis suggests to “push for more frequent
deadlines with smaller feature releases” (Mr. Ellis 2014, email interview, 3/1/2014). On the contrary
Mr. Tate thinks that orientation of shorter sprints (frequent deadlines) and smaller feature releases
will not work. He explicitly states that he actually “added more time” (Tate 2014, email interview,
20/1/2014) to mitigate the problem and is in general sceptical about using plain agile (like Scrum)
on DWH projects (prefers to use spiral methodology). Literature (Moss 2013; Hughes 2013; Corr
and Stagnitto 2012) also suggests that agile needs to respect specifics of BI projects (especially
those which have strong data integration element). Mrs. Moss stated in the interview, that “80% of
26

the work on enterprise-class data integration projects like EDW/BI is data management; only 20%
of the work is data delivery” (Moss 2014, email interview, 13/1/2014) which differs these projects
from traditional OLTP development and the agile methodology will need to take this into account.
Question is whether BI professionals realize this. From answers to I1, most of the interviewees say
that agile BI is simply agile + BI. Only Mr. Gallo explicitly said that agile should tailored for the
specifics of BI projects. Also, answers to question I3 shows similar trend - Scrum, which is not
custom tailored for BI, is preferred agile methodology. This all leads to the conclusion there is still
lack of understanding that agile methodology needs to take into account specifics of BI projects. If
this requirement is not met, then managing BI project using agile methodology might prove
troublesome.
Another dimension that contains most answers is D4 (People). The single most important theme in
this dimension is inadequate agile skills and lack of training. Mr. Ambler says “there is a very
serious lack of testing skills, let alone database refactoring, test driven development, or other skills
that are very useful for agile development” as well as “lack of coaching” (Ambler 2014, email
interview, 15/1/2014). Mr. Gallo sees the major weakness in “team members with single skills”
(Gallo 2014, email interview, 6/1/2014) which means that people in the team are highly specialised
IT professionals but might have lack of knowledge of agile project management. Important point is
made by Mr. Schwarz as he states that “project members are continuing working according to
classical methodologies like waterfall” (Schwarz 2014, email interview, 6/1/2014). This suggests
that even though the team members has been instructed and trained to use agile methodology they
don't use it as they have lack of hands on experience and are simple more comfortable with
waterfall approach. Interviewees suggest that continuous coaching and mentoring is required
(Ambler 2014, email interview, 15/1/2014) and to “pay attention to the project team“ (Schwarz
2014, email interview 6/1/2014) whether they manage to make the shift from waterfall towards
agile.
Last dimension that will be discussed in this chapter is D6 (Tools). This dimension contains answers
which also have one common denominator – to minimize risks, challenge tools and methodologies
the team is used to using and ask whether these are suitable for agile approach. Mr. Hughes thinks
that using traditional DWH modelling techniques like Inmon or Kimball approaches can be risky as
“they lead to data warehouses that cannot be easily redesigned for new requirements once they’re
loaded with data” and suggests using alternative approaches like hyper normalization techniques or
hyper generalization instead (Hughes 2014, email interview, 13/1/2014). Mr. Gallo raised a concern
about heavy project administration. He insists that the team should “minimize the amount of formal
27

project management documentation needed” and “use daily stand-up meetings and direct
communication to address issues, concerns, etc.” (Gallo 2014, email interview, 6/1/2014). This is a
big difference to waterfall approach which is normally documentation heavy and the team trying to
use agile needs to understand the that agile methodology puts working software over
comprehensive documentation (Agilemanifesto.org 2013). Interestingly enough, not a single
interviewee mentioned software tools (project management or development tools) being a risk. Also
answer to I7 indicate that there is not tool that would be preferred by the majority of the BI
developers. In conclusion, it seems that while the software tools are not a concern at all, the
methodologies applied (data modelling, documentation creation approach) can actually generate
substantial risks or might not be compatible with agile approach.
28

7 Conclusion
There is a significant difference between agile usage among agile BI experts and ordinary BI
practitioners (80% versus 43% respectively). The review of literature and analysis of the findings
proved that while there is agile BI literature available and there is also high level of disappointment
with waterfall methodology. This leads to conclusion that agile is not used in the BI world as much
as it could probably be and the future will show if it will reach higher adoption levels.
If a project team decides to use agile in a BI project several risks which can endanger this initiative
has been identified:
Dimension Root cause (risk) Risk mitigation
D1
Environment
Prevailing traditional mindset.
Continuously promote advantages of agile BI to the
management and mentor existing staff how to use
agile BI. Also make sure that the business has
business representative in the core (project
management) team. The initiative needs to come
from the IT side; it cannot be expected that business
will promote agile BI.
D2
Management
Managing BI projects using
agile without considering
specifics of such projects.
Always keep in mind that agile was designed by
OLTP developers; OLAP (BI/DWH) projects are
different and can become very complex due to data
integration element. Either choose agile
methodology that has been designed specifically for
BI (Extreme Scoping, BEAM, DAD) or use generic
agile (like Scrum) but make sure it is applied in a
way that respects BI project specifics.
D4
People
Inadequate agile skills.
It cannot be assumed that when someone is a good
BI developer he will easily pick up agile approach
and become valuable member of agile driven team.
Training and coaching is required. The team that
recently started using agile on a project should be
supported by an experienced agile practitioner and
observed for a while. The risk of reverting back to
waterfall or developing agile-waterfall mix will be
present.
D6
Tools
Using tools and
methodologies which are not
compatible with agile.
Always challenge tools and methodologies the team
is used to use and ask whether these are compatible
with agile. Especially in the area of data modelling
such an analysis needs to be performed (in regards
to traditional Inmon or Kimball approaches to
designing DWH).
Table 1: Risks of using agile on a BI project
29

The single most important risk that resonated not just through the interviewees but in the literature
as well is the fact that agile methodology needs to respect BI specifics. It would be beneficial to
verify results of this research by running online questionnaire among higher numbers of BI
developers and project managers.
Undertaking the research was a huge learning experience but it was not without problems. The
biggest issues was to find the right interviewees and convince them to participate on the research.
Although 28 interviewees were nominated and contacted only 10 responded. While the author of
the research believe that 10 interviews provided enough information to perform valid analysis, it
needs to be pointed out that convincing some of the BI practitioners to contribute was a daunting
task. The other issues was trying to solve too many research questions – this was dealt with by
dividing the questions into primary (Q1, Q2 and Q3) and secondary objective (Q4 and Q5).
Secondary objective questions were not analysed separately but as a part of analysis of the primary
questions. On the other hand, choosing Ishikawa diagram as the conceptual framework proved to be
a good choice. It is a simple, easy to understand tool that fits the needs and aims of this research.
In conclusion, the author considers this research a success which allowed him to boost his
knowledge of agile techniques and hopes that the results will be valuable for wider BI audience as
well.
30

8 References
Agilemanifesto.org, 2013. Manifesto for Agile Software Development. [online] Available at:
http://agilemanifesto.org/ [Accessed: 19 Dec 2013].
Avison, D. E. and Torkzadeh, G. 2010. Information systems project management. New Delhi: Sage
Publications/Sage South Asia
Brobst, S., McIntire M., Rado E., 2008. Agile Data Warehousing With Integrated Sandboxing.
Business Intelligence Journal, 13(1), pp. 13-22.
Bullington, K., 2012. Learning to Fish. Quality Progress, 45(7), pp. 16-21.
Corr, L. and Stagnitto, J., 2012. Agile data warehouse design. Leeds: Decisionone Press.
DeSarra, P., 2012. BI Dashboards the Agile Way. Business Intelligence Journal, 17(4), pp. 8-16.
Evelson, B., Karel, R. and Others, 2010. Agile BI Out Of The Box. Forrester Research, p. 1.
Gartner.com, 2013. Gartner IT Glossary - Business Intelligence (BI). [online] Available at:
http://www.gartner.com/it-glossary/business-intelligence-bi/ [Accessed: 18 Dec 2013].
Hill, J., Moss, L.T., Sorenson, C. and Weeks, W., 2009. Agile Development. Business Intelligence
Journal, 14(2), pp. 53-60.
Hughes, R, 2013. Agile data warehousing project management. Waltham, MA: Morgan Kaufmann.
Moss, L, 2013. Extreme scoping. [S.l.]: Technics Pubns Llc.
Perry, M.S., 2006. A Fish(bone) Tale. Quality Progress, 39(11), pp. 88.
Van Decker, J.,E. and Sinnett, W.M., 2013. The CFO's Top Technology Imperatives. Financial
Executive, 29(5), pp. 25-28.
Wikipedia, 2013. Agile software development. [online] Available at:
http://en.wikipedia.org/wiki/Agile_software_development [Accessed: 18 Dec 2013].
31

9 Appendix A: Transcript of interviews
This Appendix Bontains transcripts of all interviews. Answers of the interviewees are in italic and in
verbatim. The questions are tagged with I1 – I7 if they are standard questions of the questionnaire,
follow up questions (often specific for each interviewee) are tagged with S. In total there are
transcripts of 10 interviews (5 from Group A and 5 from Group B).
9.1 Interview with Mr. Ambler
Name: Scott W. Ambler
Shot description: senior consulting partner in an organization that focuses on agile BI project
management consultations; founding member of Disciplined Agile Consortium (DAC); Canada
Form of interview: email, linked in discussion
Group: A
15/1/2014
1. (I1) Do you know what agile BI is? If yes, how would you define it?
Yes. An approach to the development of a BI solution that is evolutionary (iterative and
incremental) and collaborative in nature.
2. (I2) On how many BI projects, which have utilized agile methodology, have you
participated on?
Directly on 4 or 5, but indirectly (advisory role) on a dozen or so.
3. (I3) Which agile methodology have you used the most while working on BI projects?
Disciplined Agile Delivery, a hybrid
4. (I4) Please name three problems (based on your experience) which can cause failure of an
P1. Traditional mindset. Too many data professionals are stuck in 1970s thinking.
P2. Lack of coaching. There’s enough new ideas in the agile BI space that teams with
“experienced” staff will run into trouble (often due to traditional thinking).
P3. Poor skills. There is a very serious lack of testing skills, let alone database refactoring,
test driven development, or other skills that are very useful for agile development.
32

5. (I5) For the problems from question (4), please describe shortly, how have you (or would
• I usually have to bring in skilled people to do the implementation work, and use the
existing staff as SMEs for the legacy data sources. We also mentor and coach the
existing staff to give them more modern skills.
19/01/2014
6. (S; follow up question to I2) Could you please provide perceptual of agile BI projects
compared to all BI projects you worked on?
• In the last 10 years, it would be 100% agile for me.
7. (S) Disciplined Agile Delivery, is that an agile BI methodology developed by yourself? How
much does it relate to traditional agile development frameworks like Scrum or XP?
See http://DisciplinedAgileDelivery.com. DAD is a hybrid method that encompasses Scrum,
XP, Agile Modelling, Agile Data, and other methods. It basically shows how all this fits
together. Anyone telling you that they're just doing Scrum isn't being honest (or doesn't know
what they're talking about).
8. (I6) Does the initiative of using agile come from the business or from the IT (BI team)?
Often the business, particularly when they're in a competitive environment.
9. (I7) Do you have any preferred tools for agile BI management?
No.
9.2 Interview with Mr. Chu
Name: Dennis Chu
Shot description: BI business analyst in an investment bank; South Africa
Form of interview: email, telephone
Group: A
14/01/2014
Yes, introduced as part of tertiary education. The agile development methodology (applied
33

traditionally to software development projects) is applied to Business Intelligence projects.
As such this encourages shorter and a more iterative approach than the traditional waterfall
approach that a large number of BI projects tend to follow. This approach is especially
useful in the BI area as often requirements are not known upfront and can only be defined
once on-going analysis in the data has been enabled. Due to the nature of BI, this approach
also lends itself to cater for seasonal/adhoc analytic which cannot be defined clearly using
traditional approaches. The enablement of this method in the organization allows
information to be gathered from the data in a much more flexible approach where
requirements can change depending on the result of the on-going analysis.
participated on?
4 out of 15 (26.67%); (2 were very “loose” agile)
3. (I3) Which agile methodology have you used the most while working on BI projects? (
SCRUM
P1. Business does not follow agile approach
◦ Planning and budgeting are based on set criteria at the beginning of the project, this
assumes that the scope of the project is known and also exact requirements are
defined at a point in the project. Agile does not follow this.
◦ Measurements of project progress and success is measured still using traditional
waterfall approach especially on completeness, where Agile is more flexible in terms
of “completeness” due to it’s nature of using an iterative approach.
◦ Often BI projects (from my experience) is seen as a side-line project, and thus
business do not feel the need to adopt formal approaches and methodologies as it’s
not “big” enough to define it’s own method of working. The greater project
approach is often adopted and forced upon BI projects.
P2. Not following Agile principles when under pressure
◦ Related to above, but many people understand the Agile methodology but due to
changing requirements and priorities in the project this gets eroded to a point where
34

“hybrid” agile is used, but not in a constructive way, and this tends to lead teams to
revert to traditional approaches.
P3. Risk
◦ Due to the nature of it’s origins (of being from a IT background), businesses tend to
be sceptical about buying into IT teams adopting Agile approaches. As a consultant
previously we have tried to encourage this on many projects, but many clients have
been adverse to this as they feel their traditional methods “work”. A large majority
of business orientated PMs have also not been introduced formally to agile, thus are
reluctant to drive projects using an approach that is new to them.
• Business does not follow agile approach
◦ Initiating projects from the beginning with the Agile methodology, working with
business to define principles and methodology. Promote and continuously
communicate to users and specifically management the benefits of Agile through
rapid deliverable and show value through these.
◦ Work closer with PMO to implement an Agile methodology that fits with the
project and establish clear definition
• Not following Agile principles when under pressure
◦ Related to above as well, this requires business to be in alignment with
development teams. Project Management and users need to be aware of the
process and not circumvent these to “fast track” certain tasks outside the agreed
upon principles.
◦ We’ve had success in taking certain tasks out of Agile where necessary and 1-2
individuals operate temporarily outside the larger project agile process to focus
on certain tasks that require immediate attention, this allows these tasks to be
done without compromising the rest of the project methodology.
• Risk
◦ Practitioners of Agile should be skilled enough to implement and assist
migration to agile way of working. This should be done upfront preferably before
35

the initiation of a project to get buy in from PMO and business to fully realize the
benefits of the methodology. Many people do not understand the implications of
this process and thus often revert back to traditional principles when there is
uncertainty.
◦ The PMO should be an integral entity in this migration and committed to this
buy-in. Constant feedback and improvements should be communicated and
shown to business to continuously emphasize the benefits of this for business and
not purely an IT approach that is applicable for development.
24/1/2014
Always from IT! This is understandable since agile was initially used in development
projects. I have yet to work on a project that has business owners/project managers that use
agile throughout and not only when dealing with IT/development environments.
Currently we use JIRA, in most SCRUM approach projects we have used manual methods.
We had a dedicated SCRUM room where the process was tracked physically used sticky
notes and walls with dedicated areas indicating the status, and we move the notes from area
to area.
9.3 Interview with Mr. Corr
Name: Lawrence Corr
Shot description: agile BI expert; author of the book Agile Data Warehouse Design which
introduces BEAM method (agile BI methodology); UK
Form of interview: email
Group: B
8/1/2014
Yes, I think so. It has to be BI solutions delivered using the core values and principles of the
agile manifesto.
36

participated on?
20% of the project I have worked on in the last 10 years utilize agile. That figure rises to
50% of my projects in the last 2 years.
I use BEAM (Business Event Analysis and Modelstorming) - the agile BI requirements
gathering and dimensional modelling approach described in my book. This is most
commonly used in conjunction with scrum by my clients who are running their entire BI
development on an agile basis.
P1. I will give you only one. Not starting agile. Leaving agile to the development/testing
and not applying it to analysis and design. It very difficult to go agile mid project.
BEAM if it’s a BI project.
6. (S; follow up to I4) In your answer to Q4 you say not to start agile, yet your book mention
agile data modelling and warehouse design? I though that agile is an iterative approach and
requirement collection/design of dwh would happen in each iteration or am I mistaken?
I should have made it clear that "not starting in an agile way" is a problem that can cause
failure of an agile methodology on a BI project. It is not enough to use agile methods for the
development phase we must use them for analysis and design - again exactly as you said. To
succeed with agile, development teams can go agile unilaterally.
P2. The business must be on board with agile too. It’s very difficult to successfully "throw
the agile switch" mid-project. It’s much easier if you start as you mean to go on and
start with the users with some disruptively different (agile) approach to requirements
gathering (such as BEAM) then they realize they need to act differently too and might
receive a different outcome.
7. (S) Is BEAM an extension to Scrum?
I would not say BEAM is an extension of Scrum. I’d say it’s an agile data
37

analysis/modelling/design technique which is compatible with Scrum just as many Extreme
Programming software engineering/development techniques are compatible with Scrum.
Scrum itself is just a lightweight feature-driven project management framework which pre-
dates the Agile Manifesto by some years and has been embraced by the agile software
development (ASD) community. Most of the techniques used for "traditional" ADS are
feature-driven.
9.4 Interview with Mr. Ellis
Name: Ike Ellis
Shot description: SQL and BI expert; provides training on technologies like MS SQL and MS SSIS;
USA
Form of interview: email, person to person discussion
Group: A
3/1/2014
Yes, I'm using agile BI right now on a project.
participated on?
75%
Agile SCRUM
P1. The team needs to commit to doing it, or else the deadlines are more negotiable.
P2. Management won't commit to a firm feature set per sprint, therefore good deadlines
won't be set.
P3. The feature sets are too large, and then deadlines are missed.
38

We push for more frequent deadlines with smaller feature releases.
4/1/2014
Always IT (answer to who initiates agile approach)
9.5 Interview with Mr. Gallo
Name: Jim Gallo
Shot description: agile BI expert who publishes in Business Intelligence Journal (TDWI); USA
Group: B
6/1/2014
Yes. Agile BI is an iterative and spiral development approach that embraces Agile
principles but has been modified for the unique characteristics and subtleties associated
with BI projects. The dimensions of Agile BI include:
• Sound architectural principles
• Collaborative and iterative
• Scrum teams organized around Sprints
• Business-driven development (BDD)
• Test-driven development (TDD)
• Lean (to the degree possible)
• An eye on velocity
• Dynamic and pragmatic
participated on?
100% over the past 3 years.
39

Iterative and supported by Scrum project management methods. We also integrate Lean
concepts into deliverable and work products.
P1. Trying to force waterfall methods and deliverable on the Agile/Scrum team
P2. Team members with single skills
P3. Heavy project administration
• Accept that agile/scrum is different and work with the PMO to at least try delivering a
project using Agile/Scrum unfettered by traditional deliver methods and document-heavy
processes. Educate the naysayers on Agile/Scrum Methods and its benefits. If there is an
insistence on waterfall-type deliverable and approaches, provide a separate estimate
and project plan that includes them. Invariably, the costs for pure Agile/Scrum will be
less, will have a quicker delivery time line and will produce better results.
• Create teams that have multiple skills and do not force them into a single role or set of
tasks.
• Minimize the amount of formal project management documentation needed and leverage
the Scrum Master to deal with issues/problems, thus allowing the team to focus on
design, development and testing. Use daily stand-up meetings and direct
communication to address issues, concerns, etc. The less time the team is writing things
down, the more time they have to deliver the project.
7/1/2014
Generally, it’s the business who sees the value in agile. IT, the PMOs in particular, seem to
be adverse to the idea. Not sure why this is the case.
I recommend Jira for managing agile/scrum projects.
40

9.6 Interview with Mr. Hughes
Name: Ralph Hughes
Shot description: agile BI expert; author of the book Agile Data Warehousing Project Management
(Business Intelligence Systems Using Scrum); USA
Group: B
13/1/2014
Agile + BI; Agile = The incremental and iterative delivery approach that emerges from self-
organized teams that are charged with constantly delivering quality-assured value to the
customer in a manner that steadily mitigates risks and eliminates wasted efforts; BI = A set
of concepts, methods, and processes to improve business decision-making using any
information from multiple sources that could affect the business, and applying experiences
and assumptions to deliver accurate perspectives of business dynamics. (DAMA Dictionary
of Data Management, 2ed)
participated on?
Since 2006, 100%.
Scrumban
P1. Poor requirements definition (RM)
P2. Poor quality management
P3. Inmon or Kimball data modelling techniques, because they lead to data warehouses
that cannot be easily redesigned for new requirements once they’re loaded with data.
• The more advanced user story generation techniques that generic agile practitioners
41

teach + enterprise-level RM techniques that we adapted from RUP
• Agile quality assurance a la Lisa Crispin’s book + test lead development at theme and
epic levels + Zuzena, the automated regression test engineer for data warehouses
(zuzena.com)
• Hyper modelling: either a) hyper normalization techniques such as anchor modelling or
data vaulting, or b) hyper generalization using Kalido DIW
21/1/2014
In my experience, impetus comes from IT after business has threatened to fire them because
they are too slow and too expensive.
Jira / Greenhopper, Version 1, IBM Rational Team Concert, Pivotal Tracker
9.7 Interview with Mrs. Moss
Name: Larissa Moss
Shot description: agile BI expert; author of the book Extreme Scoping; USA
Group: B
13/1/2014
Yes. Agile BI is a business capability. BI requires new analytical tools and technologies as
well as a pool of standardized, integrated, and trust-worthy data, which is often referred to
as the "single version of truth" (SVoT). Because that SVoT often does not exist in operational
systems, it must be provided through an enterprise data warehouse (EDW). In order to
deliver analytic functionality through the EDW as quickly as possible, different agile
methodologies must be utilized.
participated on?
During the 26 years I have been in data warehousing, I have applied agile principles to
42

approximately 50% of my clients' projects.
Since I only engage in mature enterprise-class BI projects, I use Extreme Scoping, which is
a data-agile methodology as opposed to Scrum, which is a development-agile methodology.
P1. Rigid adherence to an agile methodology. In other words, following rules like cadence
when your data scopes vary in volume and effort from release to release.
P2. Having developers run the projects instead of data management professionals. 80% of
the work on enterprise-class data integration projects like EDW/BI is data
management; only 20% of the work is data delivery (reports and apps). Enterprise-
class BI projects are data projects, not development projects.
P3. Lack of participation by the business people. IT can only be agile if their users actively
participate on the projects.
• I do not use the agile development methodologies like Scrum or XP on BI projects. I use
the agile data methodology Extreme Scoping. That methodology was designed
specifically for enterprise-class data integration projects like EDW/BI. It applies most
agile principles, but does not include those principles that do not work for data
projects. I also adapt this methodology further depending on individual project needs.
• I insist that the project core team includes a data management professional (preferably
CDMP, which stands for Certified Data Management Professional). The project core
team acts as the project management team. I follow the BDTP Balance as suggested in
Extreme Scoping, namely that the core team is made up of a business representative, a
data management professional, one or more technical experts, and a project lead with
project management experience. They make all project decisions together based on
guidelines specified in the Extreme Scoping methodology.
• I insist on a business representative from the business community (not IT) to be a
member of the core team, which is also the project management team. In other words, I
follow the BDTP Balance in Extreme Scoping. I prefer full-time participation on project
43

activities by the business representative. If that is not possible, I insist that the business
representative participates in all project meetings (daily stand-ups, weekly reviews,
special meetings) and is part of every discussion that requires a decision regardless
whether it is a business decision or technical decision. I do this to ensure co-ownership
and co-management of the projects and to give projects full visibility.
15/1/2014
It's a mix. In some companies, data analysts and data scientists on the business side push
agile. But in my experience 80% of the time it is IT that is pushing it. In particular, it is the
DEVELOPERS in IT that push agile DEVELOPMENT methodologies like Scrum and they
do not understand why data management professionals have a hard time using Scrum on
DATA (not development) projects.
I am not at all into tools and products. I manage my projects the old-fashioned way with
milestone charts and task boards. So, I have no opinion on products.
8. (S) You say that use extreme scoping which is technique developed by yourself. Is it in any
way related to off the shelf development agile (Scrum, XP etc.)?
Extreme Scoping follows the agile manifesto (modified and adapted to data-centric projects)
and also the 12 agile principles (also modified and adapted to data-centric projects) In that
sense it is one of many (I think there are 13) agile methodologies on the market. What makes
Extreme Scoping DIFFERENT from the others is that it is centered around data architecture
work and not around software development. Scrum and XP were invented by developers for
other developers to write better and faster code. Extreme Scoping was invented by a data
management professional (me) for other data management professionals to deliver better
and faster and integrated data that supports business analytic. How do you persuade
people to adopt Extreme Scoping when this is not wide-spread software development
methodology? I do not have any problem persuading data management professionals to use
a data agile methodology because they are not able to use the other software development
methodologies. Scrum and XP revolve around turning requirements into working software
code. Extreme Scoping revolves around standardizing and integrating data across the
enterprise to be used by BI analytic services. It's "apples and oranges" as we say... two
44

different types of agile methodologies for two different purposes. We also write some code
on our projects (maybe 10%-20% of total effort) but most of our work is data preparation.
People are usually resistant to learn something new unless they know that can capitalize on
it later on.
9.8 Interview with Mr. Peake
Name: Jan Peake
Shot description: business intelligence project manager working in automotive industry; UK
Group: A
3/1/2014
I know what agile development is, but I haven’t heard of the term in direct relation to BI.
participated on?
None using a formal agile method. However, we are starting to work more along the agile
way, trying to break the products down into smaller deliverable that can be shared with the
customer. But the Bentley methodology, formerly SEP, now becoming IT-PEP is still the
waterfall method.
6/1/2014
3. (S) Will agile be demanded in the future?
Yes I think agile will continue to become more utilized. We would have moved to agile in
Bentley but we are not mature enough as an organization. It relies upon trust and a high
degree of collaboration with the customer to agree deliverable and support frequent testing
and feedback. Getting commitment to support testing and feedback can be a challenge in
Bentley, even if a schedule is agreed up front and events put in calendars they quickly lost
focus in place of other business as usual priorities. Agile requires frequent review with the
customer to agree on the content to be delivered during a sprint and to test and sign-off at
the end.
45

9.9 Interview with Mr. Schwarz
Name: Peter Schwarz (please note that this is pseudonym as the interviewee did not authorize to use
his real name or the company he works for)
Shot description: business intelligence analyst working in automotive industry; Germany
Group: A
6/1/2014
• IT is able to return benefits to business (needs) in a very early project phase
• Fast response and flexible implementation of new or modified business requirements
• Gathering fast project results which can be discussed directly with project owner
• Continuous dialogue with business and continuous implementation process. Thus IT is
able to deliver work products permanently in very short development cycles..
participated on?
In every project I try to convince my project partners of the advantages of Agile Methods.
(S; follow up to I2) If you can estimate, how many BI projects then use agile?
Agile projects: 100% … for those I am responsible, all of them, actually two projects.
SCRUM
P1. lack of acceptance of project participants
P2. inexperienced project members concerning Scrum-know-how
P3. project members are continuing working according to classical methodologies like
waterfall
46

• further and deeper information should be provided to project participants and more
communication is required
• continuous know-how-transfer and practice new methodology
• pay attention to project team and use Scrum-tools continuously
So far as I know, IT is initiating the use or discussion of using agile methods.
9.10 Interview with Mr. Tate
Name: Jeffrey Tate
Shot description: experienced BI and DWH developer; contact gained through LinkedIn discussion
about Agile BI; USA
Group: A
20/1/2014
A variation on iterative development methodologies, similar to other incremental, time-
boxed approaches. Uses a short development cycle (usually measured in days) to complete a
set of agreed upon requirements. In BI, usually seen in report development, sometimes in
non-complex data mart development.
participated on?
15% as "pure" Agile; 100% as spiral/iterative methodologies.
Spiral
P1. insufficient time to understand requirements
47

P2. scope creep
P3. insufficient time allocated for user acceptance testing
Added more time. I think you need to make sure you recognize that a BI project may not be a
Data Warehouse project - BI is normally undertaken from a DW. The use of Agile is common
in BI, as it follows a predefined approach (much as Spiral), and delivers a solution quickly.
A DW is more complicated, from the Requirements through to the Infrastructure models
being deployed and generally take longer to spin out the first capability. Agile methods can
be (and are) used within certain aspects of DW development projects to control delivery of
artefacts, but rarely is Agile used as the primary methodology.
In my experience, the business won't care what particular methodology is used. Their main
concern is (1) Who from the business side needs to be involved, and for how long; (2) is
there a cost difference between the methods being considered. I.T. will want to know how
long one will take versus the other, and if one requires a different skill set over the other.
Any project management tool - Microsoft Project, Rational, Rally, etc. can be used to
manage Agile development. There are some tools specifically designed for Agile (Rally,
TeamPulse, etc.). Tools and technologies generally come after selecting the methodology
you want to use, and after getting the project team members aligned with whatever concept
you have in mind.
48

10 Appendix B: Categorization of I4 answers
In the Chapter 5 only examples of answers for each dimension were given. In the following table,
all links between dimensions and answers can be found. Problems (or risks) are identified by PX,
where X can be 1, 2 or 3. Full transcript of the risk is in Appendix A. Dimensions are also identified
by their codes (D1 – D5). Full name and definition of each dimension can be found in the Chapter
4.
Interviewee Problem identification Dimension
Mr. Ambler
P1 D1
P2 D4
P3 D4
Mr. Chu
P1 D1 and D3 (answer split)
P2 D2
P3 D1
Mr. Corr
P1 D5
P2 D5
Mr. Ellis
P1 D4
P2 D2
P3 D2
Mr. Gallo
P1 D1
P2 D4
P3 D6
Mr. Hughes
P1 D6
P2 D6
P3 D6
Mrs. Moss P1 D6
P2 D2
P3 D1
Mr. Schwarz P1 D4
P2 D4
P3 D4
Mr. Tate P1 D2
P2 D2
P3 D2
Table 2: Links between answers and dimensions
49

agileBIResearch

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to agileBIResearch

Similar to agileBIResearch (20)

agileBIResearch