When Agile Meets Waterfall

Investigating Risks and Problems on the Interface between Agile and Traditional

Software Development in a Hybrid Development Organization

Rob J. Kusters, Youri van de Leur, Werner G. M. M. Rutten and Jos J. M. Trienekens

Faculty MST, Open University, Valkenburgerweg 177, Heerlen, The Netherlands

Keywords: Software Development Methods, Agile, Traditional, Hybrid, Risks, Problems, Challenges.

Abstract: This paper aims to map issues (risks and problems) at the interface of agile and traditional development

approaches in hybrid organizations which have an impact on coordination and cooperation. Successfully

combining agile and traditional development methods appears to be quite a challenge for many hybrid

organizations. Both methods have their own strengths and added value but also bring their own culture and

conditions. Combining these can lead to problems. If we want to handle such problems, we first need to

understand the issues that can cause such problems. This study is aimed at identifying and validating an

overview of these issues. Based on an exploration of literature a preliminary overview of issues was derived.

These were classified into a coherent set. The result was validated in a case study within a large financial

institute in the Netherlands. The resulting list of twenty-four issues can be used as a starting point for handling

the problem area.

1 INTRODUCTION

The agile approach towards software development is

increasingly being implemented in software

development organizations. The advantages, such as

productivity, team satisfaction, and fit to user

requirements (see e.g. Rigby et.al., 2016) are

tempting. This, although drawbacks have also been

recognized, such as lack of upfront planning, lack of

documentation, and lack of predictability (see e.g.

Agrawal et.al., 2016). Within a single organization

we can see agile and more traditional approaches

being used side by side. A reason might be that this is

temporarily, when the organization is in transit from

a more traditional towards a more agile approach.

Another is that this is deliberate. The organizations

might feel that agile is a suitable approach in some

cases, but that other situations should be handled

more traditionally (see e.g. Rigby et.al., 2016).

In either case a more rigid approach, aimed at

retaining control and assuring documentation is being

used in conjunction with an approach that features

agility. The approaches require a different approach

in focus, control, way of working, and culture (see

e.g. Lazwanthi et.al., 2016). When the groups do not

mingle at either project of program level, this does not

need to lead to problems. But when they do, it is not

obvious they can co-exist amicably. Understanding

issues that might play would help. In literature we

were unable to find an overview of relevant issues.

In this paper we will look at issues that may arise

in such a situation. The question to be answered is:

“What are the issues (risks and problems) at the

interface of agile and traditional development which

impact coordination and cooperation?”

In section 2 some related work will be discussed.

Section 3 contains the methodology used while

section 4 looks at execution and results. The paper

ends with conclusions and a discussion of results.

2 RELATED WORK

Traditional development methodologies follow a

sequential design process in which progress is seen as

a gradual flow of process steps, activities and delivery

of documentation to achieve operating software. Key

elements are fixed order of main activities and a focus

on control and documentation (Royce, 1998).

Agile approaches to software development focus

on simplifying and improving software process.

Customers, developers and the final product are

Kusters, R., Leur, Y., Rutten, W. and Trienekens, J.

When Agile Meets Waterfall - Investigating Risks and Problems on the Interface between Agile and Traditional Software Development in a Hybrid Development Organization.

DOI: 10.5220/0006292502710278

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 271-278

ISBN: 978-989-758-248-6

271

central (Agile Manifesto, 2001). This is based on

values identified in the Agile Manifesto:

 People and their interactions over processes

and tools

 Working software over comprehensive

documentation

 Customer collaboration over contract

negotiation

 Responding to change over following a plan

Agile development methodologies such as Agile

Scrum follow an iterative development process. They

define a flexible product development strategy in

which a development team works as a unit to achieve

a common goal. The team organizes itself and works

closely together (preferably) on the same location or

otherwise online (Larman and Basili, 2003).

Hybrid development organizations emerge when

agile and traditional development approaches are

combined. In such an environment, one can determine

which approach or combination of approaches fits

best. Advantages and drawbacks of the approaches

can be balanced (Waardenburg and van Vliet, 2013).

That in such a hybrid environment problems

occur that find their origin in the differences between

these approaches seems obvious and is confirmed by

e.g. Siddique and Hussein (2016). However, as far as

we could see, this question has yet to be addressed

coherently in literature. We can find structured

discussions of similarities and differences between

the approaches (see e.g. McAvoy and Butler, 2007).

Also literature is available on identifying

environments and contexts for which Agile

techniques are best suited (Boehm and Turner, 2003;

Cockburn and Highsmith, 2001). And extensive

research has focused on the change to Agile (see e.g.

Boehm and Turner; McMahon, 2004).

Specifically this last field of literature can be

considered useful for our research since although our

research question is not addressed directly, indirectly

in this change relevant issues can be identified. With

this as a starting point we decided to conduct our

research aimed at identifying a set of issues (risks and

problems) at the interface of agile and traditional

development approaches in hybrid organizations

which impact on coordination and cooperation.

3 METHODOLOGY

The research consisted of three steps:

 A literature search aimed at identification of an

initial set of issues;

 A structured classification of the issues;

 Validation of the issues in a case study setting.

3.1 Literature Search

We performed a structured literature survey. For this

we used Google Scholar which contains most relevant

scientific databases (ACM, Springer, IEEE, etc..). We

looked in the title of papers for the combinations

“agile hybrid traditional”, “agile hybrid”, “hybrid

traditional”, and “agile traditional”. Sources and basic

set of keywords used should give a good overview.

Completeness of results cannot be guaranteed at this

stage given the focus on titles only, and the limited set

of keywords used. However for a first exploration this

was deemed sufficient.

We did follow up this search with a second one

using cross reference search. We looked both

backwards, based on the references in the selected

papers, and forward at papers that referred to these

papers. This second search was more focused since it

was based on papers identified in the first round.

During both searches, we first made a selection

based on the contents of title and abstract. Remaining

papers were downloaded and searched with the

keywords ‘problem’, ‘risk’, and ‘challenge’ to

determine if relevant issues were discussed. If so, the

paper was added. Otherwise it was discarded.

Papers added in the cross-reference step were

again used as a basis for a follow-up cross-reference

analysis until no new papers could be identified.

3.2 Classification

The resulting set of papers was analysed carefully,

extracting potential issues. Each potential issue was

extracted and labelled. Since issues were identified

from individual papers, the resulting set could well

contain overlap, be formulated at differing levels of

abstraction and be too big to be manageable. To deal

with this, a structured classification was carried out.

Since in an unstructured list the only classification

principle available is that of ‘belonging together’, it is

essential that such a classification is carried out in a

structured way by qualified people.

The participants involved in the classification

should have experience in an environment where

agile and traditional development methods are used in

conjunction. Preferably, the participants can judge

this context at the strategic, tactical and operational

levels. It is also important that they have gained this

experience in an organization of sufficient size,

operating with formal structures and a certain degree

of professionalism in project and process

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

272

management. An organization with a minimum

maturity of CMMI level 2 is likely fit this objective.

Literature shows no consensus on the ideal

number of participants. A larger number might give a

higher degree of certainty about the results. But with

a larger group it is also more complex to achieve a

good dialogue and to come to conclusions. A

minimum of four is sometimes mentioned. In this

particular situation we opted for five participants as

an uneven number avoids obvious ties.

The process was based on the Metaplan approach.

This is a nominal group technology based card sorting

technique executed in a group discussion setting

(Howard, 1994). An advantage of such an approach

is that its group discussion aspect tends to cancel out

individual bias. It also directly involves the required

expertise.

We obtained the cooperation of the IT department

of a large Dutch financial organization. In this

organisation agile and traditional development live

side by side. The organisation is also of sufficient

maturity to enable staff to see beyond the daily

emergencies. Five experienced business analysists

participated in the research. At this organisation

business advisors advise between business and IT on

designing and launching projects, and on the potential

impact of changes in technology. As a result, they

have sufficient knowledge and experience regarding

the interplay between different development methods

and the risks and problems that may arise there.

The process followed is simple. Each potential

issue is noted on a card. The resulting stack of cards

is discussed one by one. The first card is put on the

table, forming a first group. For each subsequent card

the question is: is it in essence identical or to an

existing card, sufficiently similar to a group of cards

already on the table, or do we need to start a new

group of cards? If they are considered to be identical

they wil be merged into a single issue. After all the

cards are processed a number of potential issues will

have been merged and a number of groups of cards

wil have been identified which will subsequently be

named. In this way, overlap has been removed

resulting in a single list of issues. The group structure

identified to allow easier handling of this list.

3.3 Case Study

The result of the research up till now is a list of

potential issues. Logical next objectives now are:

 Validation: How valuable and relevant are the

elements of this list;

 Enrichment: Can the list be improved?.

Further research will mainly focus on the first

question, although options for enrichment will not be

ignored when offered. To validate the intermediate

results it was decided to do a case study in an

organization where the issues might be recognized.

Given the preliminary character of the results from

literature it was felt a case study would provide richer

and more in-depth results then can be expected from

a survey. The type of result we are looking for is for

each potential issue a confirmation that it played a

role in a specific situation. This confirmation should

be based on actual and traceable experience, and

preferably be confirmed by triangulation. This to

avoid too strong a reliance on opinions and strengthen

the internal validity of the results. Case studies can

provide such information. It allows triangulation and

provides in depth situational data that allow a better

understanding of the issue and its impact.

Requirements for a case organisation were that:

 Agile and traditional approaches are combined;

 A sufficient level of process maturity is present

so systemic effects can be distinguished from

emergency situations;

 They are in transition to a hybrid situation, so

issues have not yet deteriorated into accepted

background noise.

The same Dutch financial organization that

participated in the first classification phase met these

criteria and was willing to cooperate. We could

identify several environments for the research. We

choose two of these as subcases, enabling cross-

triangulation. Each subcase sat within a programme

where both agile and traditional work is required for

a common goal, so interactions are mandatory.

For information sources we looked for both

documentation and interviews. Documentation

presents of events from which relevant issues could

be found. Interviews can be used to clarify these and

can also validate results from the literature study.

Given the large amount of documentation

available we decided to focus on documents related

to project phase transitions, problem reports and risk

management documentation. It was felt that relevant

issues would be likely to be encountered in these.

People to be interviewed were selected such that

we would cover the most relevant perspectives in

order to provide a sufficiently complete picture. Per

subcase we wanted to speak with a person with a

higher level overview across the two approaches, who

would be able to identify issues from that position.

The role of programme manager was used for this.

From within each of the approach groups we elected

to interview two persons. One interview was with the

When Agile Meets Waterfall - Investigating Risks and Problems on the Interface between Agile and Traditional Software Development in a

Hybrid Development Organization

273

person carrying project responsibility. In agile terms

that is the scrum master and in traditional terms the

project manager. The other interview was with a staff

member who maintains contact with the users. In the

agile approach that is the product owner. In a

traditional setting the business analyst role fit.

To further ensure this, only people were selected

with sufficient (> 2 year) experience in the current

role, as well as having completed a schooling at

bachelor level. We also tried to obtain a mix in gender

and age so as to widen perspectives covered. This

resulted in 10 planned interviews, five per subcase.

The design of the research process is shown in

Figure 1. First an documents were analysed. They

were searched using keywords ‘risk’, ‘problem’, and

‘challenge’ so we could identify relevant issues.

These were mapped to the results from literature or

were labelled as new candidate issues.

After this interviews were planned. Each

consisted of four steps. First the results from the

document study were discussed and validated. Did

the researcher correctly interpret the documents and

did the identified issue indeed play a role. This results

in a number of validated issues. Some of them based

on literature and some of them new.

In step two the interviewee is asked to identify

additional issues. For each such issue, additional

information was asked to ensure it was based on

actual experience. Also the impact of the issue (low -

middle - high) was asked to obtain an indication of its

degree of severity.

In step three the list of potential issues resulting

from literature is discussed. The goal is to see if these

issues have been encountered in practice. Questions

are primarily aimed at actual experience:

 Have you encountered this issue recently?

 If yes: Can you describe what happened?

 If no: Is this a plausible issue?

A solid description after a ‘yes’ should give us

confidence that this answer is indeed based on actual

experience, providing strong validation for the issue.

The opinion queried after ‘no’ of course gives a much

weaker substantiation since it is an opinion only.

Finally in step four people were again asked for

additional issues. This to catch any final thoughts.

The choice was made to conduct the steps one to

four in a single session. The benefit was that people

remembered the first part and could refer back to that.

The discussion of the documents helped in bringing

back the actual circumstances of the past. This

enabled them to better place e.g. the literature results

in this past. It was also done for pragmatic reasons. It

was easier to get participation this way. The sequence

between steps one and two can be seen as a drawback.

If the interview had started with step two, a more open

explorative discussion could have resulted.

Discussion of issues identified from documentation

might close of the minds of the interviewees. The

enrichment objective of the research would have

benefitted from that. On the other hand, such an open

discussion, might be too open and take (precious)

time while leading to inconclusive results. This might

endanger the validation objective of the case study.

An additional drawback was that issues detected in

step two cannot be confirmed in other interviews.

It was decided to do step two before step three,

since new insights are unlikely after having been

confronted with a large and structured list of issues.

Figure 1: Research process in the case study.

The interviews were recorded to facilitate

processing but not transcribed. Since the interviews

were well structured, this was not deemed necessary.

Internal validity is fostered by a careful research

design. Respondents were carefully selected.

Respondents were informed in advance about the

purpose of the research. This allowed them to prepare

the interview. They were also given the option to

check interpretations derived from their interview.

This will increase the quality of the information

obtained, and thus the validity of the research.

External validity is obtained by the ‘factual’

context maintained throughout the interviews.

Results will show that in the particular organization

issues have been encountered. Naturally, this does not

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

274

imply relevancy for all organizations. But it does

show experienced practitioners have met problems

based on the issues, suggesting their relevance.

Reliability is supported by the careful design of

document study and interviews. This resulted in the

development of an interview guide that allowed to a

large degree repeatable interviews. Similarly, the

document study process has been well developed.

4 EXECUTION AND RESULTS

4.1 Literature Search

The literature study, using keywords as described

resulted in identification of 486 papers. After further

consideration of title and abstract 27 of these were

selected for a full study. Reading these aimed at

identifying specific keywords resulted in a final set of

six papers. A cross-reference search led to 12 possibly

useful papers, of which six proved useful. Cross-

reference search on these papers led to no further

findings. The resulting papers are shown in table 1.

A further analyses of the resulting 12 papers

showed that seven gave direct evidence for potential

issues. From these, in total 20 potential issues were

identified. The remaining five papers had no such

direct evidence, but provided relevant material from

which an additional eight potential issues were

derived. This resulted in a list of 28 potential issues.

Table 1: Selected papers.

Bannink, S. (2014); Boehm B. & Turner R. (2005);

Gandomani, T.J., et.al. (2013); Khalil, C. & Fernandez,

V. (2011); Mahadevan, L., et.al (2015); Mahanti, A.

(2006); McMahon, P.E. (2004); Misra, S.C.,et.al

(2010); Pechau, J. (2012); Tanner, M. & Willingh, U.

von (2014); Vinekar, V.,et.al. (2006); Waardenburg, G.

van & Vliet, H. van (2013)

4.2 Classification

This list requires further processing. Different authors

might come up with (almost) identical issues. Also,

an unstructured list of this size is not easy to handle.

So a classification was carried out. For this, five

Business Advisors from different domains or product

chains were invited for a Metaplan session. During

the session a number of issues were merged, resulting

in 22 unique potential issues. These were structured

into six groups. The resulting structured list with

potential issues is presented in table 2.

Table 2: Classification of potential issues.

Organization and structure

C21) Overlap in tasks and responsibilities creates

confusion and duplication of work

C22) Lack of joint responsibility for delivering

customer value

C25) Overlap in tasks and responsibilities in defining,

developing and prioritizing requirements

Business processes and control

C4) Feeling of management they have no control due to

lack of reporting

C14) Lack of a high-level planning and understanding

of dependencies

C18) Lack of collective goals that result in steering

towards individual instead of team contribution

C27) Delay in implementing changes by central quality

control

Culture and management style

C9) Lack of a management style focused on leadership

and collaboration

C10) Lack of a culture focused on authorizing Agile

development teams

C23) Lack of mutual cooperation and trust resulting in

reliance on procedures

Development and testing

C2) Lack of linkage of the iterative development

process to the test process

C6) Lack of continuous integration testing causing

problems be identified too late

C11) Lack of development processes driven by people-

oriented iterative development

C16) Lack of a facilitator / coach to remove obstacles

Involvement of stakeholders

C3) Lack of proper client representation in the

development team

C8) Lack of continuous customer in determining

customer value and priority setting

C28) Lack of executive sponsorship and management

commitment

Documentation and communication

C1) Lack of communication and cooperation between

and across development teams

C5) Absence of design documentation before the start

of the development process

C7) Absence of a fully documented final product which

can collide with expectations

C12) Lack of active exchange of knowledge which

prevents new insights from arising

C15) Lack of communication aimed at autonomous

decision-making and transparency

When Agile Meets Waterfall - Investigating Risks and Problems on the Interface between Agile and Traditional Software Development in a

Hybrid Development Organization

275

4.3 Case Study

Next the case study was executed. We identified two

subcases within the organization. These were found

in clearly distinct environments. Within each subcase,

both agile and traditional development were present

and interaction indeed took place, thus fulfilling our

requirements.

For both subcases the project initiation document

and a risk register were used. For subcase I also

change requests and exception reports were used. In

the analysis for subcase I 20 out of 22 issues were

identified. For subcase II, only 8 out of 22 issues were

identified. In neither case any issue outside of the

already existing list was identified.

These results were used as input for step one of

the interview (cf. Figure 1). The data were given to

the interviewees beforehand to help them prepare.

Table 3: Results from case study.

Issue Documentation Interviews

# of cases Experience Opinion

Organisation and structure

C22 2 9

C21 1 5 1

C25 1 2 3

NC1 0 1

Business processes and control

C27 1 7

C14 2 6

C4 1 6 2

C18 1 4 3

NC2 0 2

Culture and management style

C9 1 6 1

C10 1 6 2

C23 1 5 2

Development and testing

C6 1 8

C2 2 7

C11 1 5 2

C16 0 2 2

Involvement of stakeholders

C28 2 6 1

C8 2 4 1

C3 2 3 1

Documentation and communication

C5 2 9

C1 2 7

C12 1 4 3

C15 1 4 2

C7 0 2 3

In step one the selection obtained from the

documentation was discussed. All identified issues

were confirmed in one or more interviews as being

real and (potentially) leading to problems.

In step two of the interviews the open question

was asked if people could identify any additional

issues. Two new issues were identified.

 In the theme organization and structure:

 NC1) Missing business value by wrong

priorities arising from limited visibility

on customer value (from one interview).

 In the theme business processes and control:

 NC2) Lack of pre-funding for

development to work together over a

longer period (from two interviews).

In step three of the interview, the list of potential

issues (table 2) was discussed with all interviewees.

All issues were validated in at least one interview.

Finally, in step four of the interview respondents

were asked again for any additional issues. This gave

no further results. The results are presented in table 3.

5 CONCLUSIONS

In this paper we looked at development organizations

where both agile and traditional development meet

within programme boundaries. Given the strong

differences in approach, culture and terminology, it is

to be expected that problems and risks arise when

these two worlds meet. The existence of this area of

concern is readily shown, both in theory and in

practice. However, no current overview of the issues

that play a role could be identified in literature.

This gave us the idea to look into this issue. A

literature search led to identification of 28 potential

issues, based on 12 papers. Overlap between the

issues identified was resolved through structured

classification, which also added an additional level of

structure to facilitate handling of the list.

Classification was done in a workshop where one

of the researchers worked with five experienced

business analysts who showed the required

experience at strategic, tactical and operational level.

They provided a sufficient body of experience and

knowledge. The workshop process was followed

without perceived problems. Members participated

voluntarily out of interest resulting in an open and

respectful discussion. This gives confidence in the

quality of the results.

After merging the overlap, the size of the list went

down from 28 to 22 potential issues. In six cases two

issues were seen to be sufficiently similar. This is a

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

276

relative small shrinkage. Also, no issue was identified

in three or more papers. Apparently, there is a fairly

small degree of agreement between the results from

the different authors. The reason for this is unknown.

Maybe the different authors looked from different

perspectives, or with different objectives. Whatever

the case, from such a result we cannot conclude that

the resulting list is complete in the sense that the most

relevant issues have been identified. The identified

issues seem plausible and are supported by literature.

But we take these out of the context in which they

were derived. Further validation in the correct context

is therefore a mandatory next step.

Validation took place in a case study with two

subcases. Each subcase contained a program where

both agile and traditional methods are used. The

organization scores above CMMI level 2. The case

environment is therefore suitable.

Case study design was followed without many

deviations. Documentation was made available and

participants took time for the 90 minutes interview.

This time was found to be sufficient. It is noticeable

that some of the criteria, in particular related to the

impact on the agile development teams, were

recognized to a lesser extent by respondents from a

traditional background. However, the impact was not

such that it invalidated the results.

Unfortunately, of the ten planned interviews only

nine took place. The interview with one business

analyst in subcase II could not be held, and no

replacement was available. But the project manager

of that project was very knowledgeable on customer

related issues and so partly compensated for this.

Another point of attention is the large difference

between the number of issues identified from

documentation in subcase I (20) and those identified

in subcase II (8). This might be due to the fact that

more documentation was available for subcase I. 8

out of 20 issues identified in subcase I were solely

based on the change request or exception report

documents that were not available for subcase II. The

number of issues identified from common documents

(12 versus 8) is not that different.

When we look at the relevance of the potential

issues identified in literature it can be stated that all

were validated with an explicit reference to specific

experience. Table 4 shows an overview of these

results. There it can be seen that two issues are

validated based on experience in nine interviews. All

issues were validated (based on experience) in at least

two interviews. Of these, 20 could be identified

without prompting from the documentation in

subcase I and eight in subcase II, showing a solid

basis of proof. In principle a single experience based

validation is enough to give a plausible proof of

existence. If we were to require more, then based on

a 50% threshold, 14 issues can be accepted. But in

principle this list of 22 can in our opinion be accepted

as a good basis for further research.

Table 4: Validity of issues.

# of interviews Frequency based on

experience experience +

opinion

2 3

3 1

4 4 2

5 3 3

6 5 3

7 3 9

8 1 3

9 2 2

The case study had two objectives, validating the

existing list and if possible adding new issues to it.

The first objective has been achieved. As to the

second, results are less clear. Additional issues could

appear during the investigation of the documentation,

and in steps two and four of the interview.

No additional issues were identified from the

documentation. All issues that were identified, could

be related to the existing list. There is a margin for

error here, since the analysis of the documentation

was done by a researcher involved in the literature

study. Some researcher bias is not unimaginable.

However, these results were discussed in the

interviews with staff members who did not have such

a bias, and who agreed both with existence and

classification. So the results can be considered

reliable. The search based analysis of the documents

ensured that any problem, challenge, or risk

mentioned in the documentation was found and

classified. So the risk of the researcher missing a

potential issue because of personal bias is limited.

Step two of the interview gave respondents the

opportunity to mention addition issues. However,

after having discussed 8 (subcase II) or even 22

(subcase I) issues, there is a good likelihood that this

discussion had closed the mind of the respondents to

new ideas. Coming up with such issues is difficult at

best, and even more so after an extended discussion.

Still, another two issues were identified. One was

even offered twice. Both issues were identified by the

product owner in subcase II, with one confirmation

coming from the product owner from subcase I.

Given the setup of the study, no further validation

data are available. The fact that a single factor is

added independently by two person (both with a

When Agile Meets Waterfall - Investigating Risks and Problems on the Interface between Agile and Traditional Software Development in a

Hybrid Development Organization

277

similar role) suggest it is a good candidate issue. But

both issues need further validation.

Is this list complete? We have no real reason to

claim that. On the other hand, the list by itself could

explain all problems, challenges and risks taken from

the documentation. Also, only two additional issues

were identified, although under unfavorable

circumstances. Completeness of such a list can never

be guaranteed, but it seems plausible that we have

obtained a relevant and significant subset.

Such an overview can be used as the basis for a

number of future research activities. Obvious next

steps are further validation and enrichment of the list.

The current list can also serve as a start to investigate

each issue separately so as to provide guidance on

handling them. The case organization itself already

made a start with this. The interviews have provided

insights into possible mitigating measures to avoid

problems. These were gathered and reported back to

the organization as a basis for improvement. There is

also the interesting aspect of the (relative) degree of

importance of issues. This is probably very much

context dependent although some issues will tend to

crop up everywhere. For practical usage, local

assessment will be be needed to make a “common

criteria list” operational for a specific organization.

REFERENCES

Agile Alliance (2001), Manifesto for agile software

development, http://agilemanifesto.org/, checked on 2

October 2015.

Agrawal, A., Atiq, M. A., & Maurya, L. S. (2016). A

Current Study on the Limitations of Agile Methods in

Industry Using Secure Google Forms. Procedia

Computer Science, 78, 291-297.

Bannink, S. (2014), ‘Challenges in the transition from

Waterfall to Scrum–a Case study at Portbase’, 25

European Doctoral Summer School on Technology

Management. Universiteit Twente, Nederland.

Boehm B. & Turner R. (2005), ‘Management challenges to

implement agile processes in traditional development

organizations’, IEEE Software, Vol. 22 (5), 30–38.

Cockburn, A. & Highsmith, J. (2001). Agile software

development: The people factor. Computer, 34(11),

131-133.

Gandomani, T.J., Zulzalil, H., Ghani, A.A.A., Sultan,

A.B.M. & Nafchi, M.Z. (2013), ‘Obstacles in moving

to Agile software development methods; At a glance’,

Journal of Computer Science, Vol. 9 (5), 620-625.

Howard, M.S., Quality of Group Decision Support Systems:

a comparison between GDSS and traditional group

approaches for decision tasks. 1994, PD-thesis

Eindhoven University of Technology.

Khalil, C. & Fernandez, V. (2011), ‘Agile development

teams in a plan-driven organization: interplay between

agile and traditional software methodologies’,

Symposium on Information Systems and Software

Engineering. Waikiki, Honolulu, USA.

Larman, C. & Basili, V.R. (2003), ‘Iterative and

incremental development, IEEE Computer, 36(6)47-56.

Lazwanthi, M. R. R., Alsadoon, A., Prasad, P. W. C., Sager,

S., & Elchouemi, A. (2016). Cultural impact on agile

projects: Universal agile culture model (UACM). In

2016 7th International Conference on Information and

Communication Systems (ICICS) (pp. 292-297). IEEE.

Mahadevan, L., Kettinger, W.J. & Meservy, T.O. (2015),

‘Running on Hybrid: Control Changes when

Introducing an Agile Methodology in a Traditional

“Waterfall” System Development Environment’,

Communications of the Association for Information

Systems, 36 (5) 77-103.

Mahanti, A. (2006), ‘Challenges in enterprise adoption of

agile methods – a survey’, Journal of Computing and

Information Technology, 14 (3) 197-206.

McAvoy, J.& Butler, T. (2007). The impact of the Abilene

paradox on double-loop learning in an Agile team.

Information and Software Technology, 49(6), 552–563.

McMahon, P.E. (2004), ‘Bridging Agile and Traditional

Development Methods: A Project Management

Perspective’, Systems & Software Technology

Conference 2004. Los Angeles, USA.

Misra, S.C., Kumar, V., & Kumar, U. (2010), ‘Identifying

some critical changes required in adopting agile

practices in traditional software development projects’,

International Journal of Quality & Reliability

Management, 27 (4) 451-474.

Pechau, J. (2012), “Rafting the Agile Waterfall – Value

based conflicts of agile software development”, 17

European Conference of Pattern Languages of

Programs 2012. Irsee, Germany.

Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016).

Embracing agile Harvard Business Review 94(5) 40-50.

Royce, W. (1998), Software project management – A

unified framework. Boston, USA. Addison-Wesley.

Siddique, Lubna, & Bassam A. Hussein. "Grounded Theory

Study of Conflicts in Norwegian Agile Software

Projects" Journal of Engineering, Project, and

Production Management 6.2 (2016): 120-135.

Tanner, M. & Willingh, U. von (2014), ‘Factors leading to

the success and failure of agile projects implemented in

traditionally waterfall environments’, Int. Conf. Human

Captital without Borders. Portoroz, Slovenia.

Vinekar, V., Slinkman, C.W. & Nerur, S. (2006), ‘Can agile

and traditional systems development approaches

coexist? An ambidextrous view’, Information Systems

Management, 23 (3), 31-42.

Waardenburg, G. van & Vliet, H. van (2013), ‘When agile

meets the enterprise’, Information and Software

Technology, 55 (12), 2154-2171.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

278