Content uploaded by Vesna Nikolic
Author content
All content in this area was uploaded by Vesna Nikolic on Sep 17, 2019
Content may be subject to copyright.
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Contents
lists
available
at
SciVerse
ScienceDirect
The
Journal
of
Systems
and
Software
jo
u
rn
al
hom
epage:
www.elsevier.com/locate/jss
A
survey
study
of
critical
success
factors
in
agile
software
projects
in
former
Yugoslavia
IT
companies
Dragan
Stankovica,∗,
Vesna
Nikolicb,
Miodrag
Djordjevicc,
Dac-Buu
Caod
aFaculty
of
Technical
Sciences,
University
of
Pristina,
Kosovska
Mitrovica,
Serbia
bFaculty
of
Occupational
Safety,
University
of
Nis,
Nis,
Serbia
cFaculty
of
Sciences
and
Mathematics,
University
of
Nis,
Nis,
Serbia
dSiemens
PLM
Software,
CA,
USA
a
r
t
i
c
l
e
i
n
f
o
Article
history:
Received
2
July
2012
Received
in
revised
form
13
February
2013
Accepted
13
February
2013
Available online 21 February 2013
Keywords:
Software
development
Agile
methods
Critical
success
factors
a
b
s
t
r
a
c
t
Determining
the
factors
that
have
an
influence
on
the
success
of
the
software
development
projects
has
been
the
focus
of
extensive
research
for
more
than
30
years.
In
recent
years
agile
methodol-
ogy
of
software
development
has
become
the
dominant
one
for
all
kinds
of
software
development
projects.
In
this
paper
we
present
the
results
of
empirical
study
for
determining
critical
factors
that
influence
the
success
of
agile
software
projects
which
we
conducted
among
senior
developers
and
project
managers
from
IT
companies
located
in
the
former
Yugoslavia
countries
within
South
East-
ern
Europe
(SEE)
region.
This
study
is
inspired
by
the
similar
study
conducted
5
years
ago
(Chow
and
Cao,
2008).
With
this
study
we
were
not
able
to
confirm
the
model
developed
in
the
previous
study.
Moreover
it
disconfirmed
not
only
part
of
the
factors,
but
very
much
questioned
the
whole
scheme.
However,
we
were
able
to
shed
additional
light
regarding
agile
software
development
in
former
Yugoslavia
countries
from
SEE
region
as
a
reference
region
for
investigating
outsourced
projects
done
in
agile
way.
© 2013 Elsevier Inc. All rights reserved.
1.
Introduction
A
process
of
software
development
has
been
the
focus
of
interest
of
many
managers,
engineers
and
researchers
due
to
a
large
percentage
of
failures
in
the
software
industry.
Failures
range
from
inability
to
provide
software
solution
that
fits
the
require-
ments
on
time,
to
providing
solutions
that
are
a
maintenance
nightmare
or
in
the
worst
case
inability
to
provide
any
solution
at
all
(abandoned
software
projects).
One
of
the
main
problems
that
make
software
development
so
special
and
which
is
causing
the
above
mentioned
difficulties
is
that
during
the
project
both
technology
and
the
business
environment
change
(Williams
and
Cockburn,
2003).
That
change
is,
due
to
technology
advancement
nowadays,
even
more
dynamic
than
at
the
time
Agile
movement
started
its
development;
it
is
causing
customers
to
have
difficulties
not
only
to
state
their
needs
in
the
beginning
of
the
project
but
even
to
have
a
basic
idea
of
what
they
need
at
that
time
and
to
form
requirements
only
after
a
few
iterations
of
the
demo
product.
The
process
of
forming
requirements
includes
changes
as
well.
The
result
of
this
situation
is
the
development
of
a
variety
of
∗Corresponding
author.
Tel.:
+381
63
1089310.
E-mail
address:
dragan.stankovic@pr.ac.rs (D.
Stankovic).
methodologies
and
practices
that
embrace
changes
like
SCRUM,
Extreme
Programming,
Lean
Software
Development,
Kanban,
Crystal,
Feature
Driven
Development,
etc.
Over
the
years
agile
methods
have
proven
to
overcome
many
of
the
problems
stated
above
and
have
become
dominant
in
the
software
industry.
The
agile
approach
is
basically
driven
by
self-
organizing
teams
that
have
the
power
to
coordinate
their
work
on
their
own.
This
increases
productivity,
enables
employees
to
learn,
innovate,
and
finally
makes
them
happy
with
what
they
do
(Smite
et
al.,
2010a).
In
the
traditional
plan-driven
(waterfall)
software
development
processes,
work
is
coordinated
by
man-
agers
and
there
is
a
clear
separation
of
roles
(Moe
et
al.,
2010).
Similarly,
in
larger
organizations
there
is
a
tendency
of
organiz-
ing
people
around
component
teams
–
grouping
people
in
the
way
that
they
have
the
influence
over
the
small
part
of
the
prod-
uct
thus
giving
the
teams
less
control
and
losing
the
ability
of
close
collaboration.
Introducing
new
features
in
the
organization
of
that
kind
requires
synchronization
of
many
different
compo-
nent
teams
(Larman,
2011).
In
the
agile
approach,
a
self-organizing
team
decides
how
work
is
coordinated
and
has
the
complete
con-
trol
over
development
process
and
introduction
of
new
features.
However,
many
organizations,
and
especially
large
organizations,
still
base
their
software
development
around
plan
driven
or
com-
ponent
teams.
The
transition
of
such
teams
to
agile
teams
and
how
to
overcome
difficulties
that
occur
during
that
process
has
0164-1212/$
–
see
front
matter ©
2013 Elsevier Inc. All rights reserved.
http://dx.doi.org/10.1016/j.jss.2013.02.027
1664 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
been
the
subject
of
many
case
studies
(Moe
et
al.,
2010;
Ogle
et
al.,
2011).
All
of
them
agree
that
this
kind
of
transition
is
a
hard
process.
That
process
often
has
dead
ends
in
means
of
try-
ing
and
abandoning
various
software
development
practices
that
do
not
work
for
the
current
team.
Sometimes
it
is
filled
with
team
members’
frustration,
skepticism,
denying,
but
regardless
of
everything
mentioned,
achieved
benefits
ramify
the
cost
of
transi-
tion.
As
Smite
et
al.
(2010a)
comprehend
there
is
a
growing
need
for
companies
to
explore
global
sourcing
leading
to
distributed
soft-
ware
projects
with
geographically,
temporally
and
socio-culturally
dispersed
teams
facing
additional
challenges
when
trying
to
suc-
cessfully
implement
agile
values
and
principles.
The
research
in
Smite
et
al.
(2010b)
has
shown
that
it
is
possible
to
successfully
apply
agile
principles
in
distributed
environment
although
these
two
can
be
considered
as
opposite
extremes.
As
stated
by
many
authors
(Smite
et
al.,
2010b;
Hansson
et
al.,
2006)
agile
development
practice
has
always
been
ahead
of
research.
Academic
research
has
mostly
been
involved
with
try-
ing
to
understand
what
is
going
on
and
exploring
in
a
scientific
way
techniques
and
procedures
which
were
already
established
and
used
by
the
community
of
software
developers
and
agile
prac-
titioners.
One
such
example
is
work
by
Hansson
et
al.
(2006)
where
they
investigated
the
differences
between
industrial
practices
and
agile
development
practices
in
several
companies.
They
have
con-
cluded
that
the
actual
industrial
practices
used
by
companies
were
dependent
on
companies’
characteristics
and
projects
on
which
they
worked
on.
Another
study
(Chow
and
Cao,
2008)
among
agile
professionals
has
shown
that
only
10
out
of
48
hypothe-
ses
were
critical
to
success
of
agile
projects.
Based
on
the
survey
from
that
study
in
the
work
presented
here
we
have
tried
to
identify
critical
success
factors
in
agile
software
projects
on
the
sample
of
companies
operating
in
SEE
region
(region
sometimes
referred
as
Western
Balkans).
Similarly
to
the
authors
of
previ-
ous
study
we
have
used
statistical
methods
to
evaluate
responses
we
received
from
our
interviewees
and
verify
obtained
model.
It
can
be
debated
whether
model
driven
estimation
based
on
statis-
tics
such
as
the
one
used
in
our
study
is
the
proper
method
to
use
when
it
comes
to
software
engineering.
For
example,
a
study
by
Johansson
(2000)
suggests
that
the
use
of
statistics
is
perhaps
inappropriate
in
the
field
of
software
engineering
due
to
all
the
difficulties
associated
with
interpreting
the
results
and
many
existing
uncertainty
factors.
Similarly,
Jørgensen
and
Boehm
(2009)
suggest
that
the
use
of
both
formal
methods
and
expert
judgment
might
be
best.
They
also
conclude
that
future
efforts
should
be
headed
toward
judgment
based
methods.
Neverthe-
less,
we
have
decided
to
use
the
same
method
as
in
previous
study
mainly
to
make
more
accurate
comparison
with
the
results
of
previous
study.
Since
our
study
was
not
able
to
confirm
the
model
developed
in
the
previous
study,
in
conclusions
of
this
paper
as
part
of
our
future
research
efforts
we
announce
the
use
of
AHP
(Analytic
Hierarchy
Process)
in
order
to
create
a
better
model.
Our
survey
was
conducted
among
developers
from
over
20
companies.
The
general
characteristic
of
our
interviewees
is
that
they
mostly
work
in
distributed
environments
meaning
that
they
face
additional
challenges
mentioned
in
the
section
above.
We
were
interested
in
whether
these
specific
environmental
factors
will
influence
the
conclusions
made
by
Chow
and
Cao
(2008).
In
an
article
by
Freudenberg
and
Sharp
(2010)
which
was
created
as
a
result
of
panel
discussion
where
practitioners
identified
the
list
of
issues
related
to
agile
software
development
they
would
like
to
be
researched,
three
of
the
top
10
items
focus
on
distributed
teams.
This
survey
will
hopefully
show
the
difference
to
the
previous
study
which
can
be
attributed
to
both
demographic
and
distributed
teams
effect.
2.
Background
(intro
to
agile
methods)
Our
survey
showed
that
the
most
popular
agile
methods
used
among
former
Yugoslavia
agile
teams
are:
XP,
Scrum,
and
Feature
Driven
Development.
We
have
also
received
responses
in
which
some
hybrid
methods
were
used.
Interestingly,
there
were
no
reports
on
use
of
Lean
or
Kanban
which
are
becoming
increasingly
popular
in
IT
industry
in
recent
years
(Anderson,
2010;
Kniberg
and
Skarin,
2010).
The
reason
for
this
could
be
the
delay
in
imple-
menting
the
latest
practices
that
exist
in
developers’
communities
from
the
more
developed
regions
(for
example
in
Silicon
Valley).
The
possible
cause
of
that
delay
could
be
attributed
to
the
absence
of
modern
trainings
lead
by
qualified
and
experienced
profession-
als
that
are
available
in
more
developed
regions,
or
the
fact
that
cutting
edge
projects
are
less
likely
to
be
outsourced
to
overseas
teams.
Nevertheless
the
most
popular
agile
practices
are
there
and
were
considered
in
our
study.
Many
agile
methodologies
share
a
lot
of
practices
and
have
com-
mon
characteristics
and
approach
to
projects,
but
each
is
unique
in
its
own
strategy
of
their
implementation.
In
the
following
sections
we
will
briefly
describe
each
of
the
popular
methods
which
we
identified
as
being
used
by
surveyed
companies.
2.1.
Extreme
programming
Extreme
Programming
(XP)
is
one
of
several
popular
agile
pro-
cesses.
It
was
originally
described
by
Kent
Beck
(one
of
the
authors
of
Agile
manifesto)
and
has
been
proven
to
be
very
successful
at
many
companies
of
all
different
sizes
and
within
various
indus-
tries.
The
focus
of
this
approach
is
on
customer
satisfaction
so
it
empowers
developers
to
be
able
to
respond
to
changing
cus-
tomer
requirements
and
to
deliver
high-quality
software
quickly
and
continuously.
Working
software
is
delivered
to
customer
typ-
ically
in
intervals
of
1–3
weeks.
XP
improves
software
projects
by
embracing
communication,
simplicity,
feedback,
respect,
and
courage.
The
original
XP
recipe
contained
12
rules:
Planning
Game,
Small
Releases,
Customer
Acceptance
Tests,
Simple
Design,
Pair
Programming,
Test-Driven
Development,
Refactoring,
Contin-
uous
Integration,
Collective
Code
Ownership,
Coding
Standards,
Metaphor,
and
Sustainable
Pace.
Like
in
every
agile
process
these
rules
are
not
written
in
stone
and
over
time
certain
rules
were
modified,
new
rules
appeared
and
for
example
in
Shore
and
Warden
(2008)
authors
make
distinction
between
two
versions
of
XP
described
by
Beck
(1999)
and
Beck
and
Andres
(2004)
and
even
introduce
their
own
approach
to
XP
which
emerged
from
their
practical
experience.
2.2.
Feature
driven
development
(FDD)
FDD
was
introduced
by
Jeff
De
Luca
in
1997
and
later
as
a
result
of
collaboration
with
Peter
Coad
first
incarnations
of
FDD
appeared
(Coad
et
al.,
1999;
Palmer
and
Felsing,
2002).
FDD
is
a
model-driven,
short-iteration
process.
It
begins
with
establishing
an
overall
model
shape
and
identification
of
features.
Features
are
then
grouped
in
work
packages.
One
work
package
can
be
finished
within
a
single
iteration
and
it
actually
represents
working
software
with
which
customer
can
play
with.
FDD
designs
the
rest
of
the
development
process
around
feature
delivery
using
the
following
eight
practices:
1.
Domain
object
modeling
2.
Developing
by
feature
3.
Component/class
ownership
4. Feature
teams
5.
Inspections
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1665
6.
Configuration
management
7.
Regular
builds
8.
Visibility
of
progress
and
results
When
comparing
FDD
to
XP
it
seems
that
XP
is
better
suited
for
volatile
projects
where
user
requirements
are
obscure
or
change
often
(Khramtchenko,
2004).
This
is
mainly
because
XP
avoids
any
activities
that
are
not
immediately
required
for
the
current
imple-
mentation
stage.
In
the
same
analysis
FDD
is
determined
to
be
more
scalable
than
XP
because
XP
heavily
relies
on
communica-
tion
within
a
team
which
becomes
harder
as
team
grows.
FDD
is
better
suited
for
large
teams
and
within
corporate
environment.
2.3.
SCRUM
Scrum
can
be
observed
as
a
lightweight
management
frame-
work
rather
than
a
full
process
or
methodology.
It
has
broad
applicability
for
managing
and
controlling
iterative
and
incremen-
tal
projects
of
all
types.
Ken
Schwaber,
Mike
Beedle,
Jeff
Sutherland
and
others
have
con-
tributed
significantly
to
the
evolution
of
Scrum
over
the
last
decade.
Over
the
last
couple
of
years
in
particular,
Scrum
has
garnered
increasing
popularity
in
the
software
community
due
to
its
simplic-
ity,
proven
productivity,
and
ability
to
act
as
a
wrapper
for
various
engineering
practices
promoted
by
other
agile
methodologies.
In
a
nutshell,
Scrum
in
general
involves
the
following
(Kniberg
and
Skarin,
2010):
-
Splitting
the
organization
into
small,
cross-functional,
self-
organizing
teams
(Scrum
does
not
provide
complete,
detailed
descriptions
of
how
everything
is
to
be
done
and
much
is
left
up
to
the
team
itself
to
decide).
-
Splitting
the
project
(work
to
be
done)
into
a
list
called
product
backlog
containing
small,
concrete
deliverables
such
as
features,
bugs,
non-functional
requirements,
etc.
The
list
is
sorted
by
pri-
ority
and
the
estimate
of
relative
effort
for
each
item
is
done.
-
Splitting
the
time
and
forming
iterations
which
are
not
longer
than
1
month.
Iterations
are
called
sprints
and
they
end
up
with
working
code
that
can
be
presented
and
delivered
to
the
cus-
tomer.
-
Optimizing
the
release
plan
and
updating
priorities
in
collabora-
tion
with
the
customer,
based
on
insights
gained
by
inspecting
the
release
from
previous
iteration
-
Optimizing
the
process
itself
by
having
retrospections
after
each
iteration
Our
survey
has
shown
that
Scrum
is
among
the
most
used
prac-
tices
in
surveyed
companies
and
also
it
has
been
proven
to
scale
to
multiple
teams
across
very
large
organizations.
3.
Critical
success
factor
In
order
to
analyze
the
results
of
our
survey
and
compare
them
with
results
obtained
by
Chow
and
Cao
(2008)
we
have
decided
to
use
same
method,
namely
Critical
Success
Factor
which
will
be
shortly
described
in
the
following
section.
Critical
success
factor
(CSF)
was
introduced
by
Rockart
(1979)
as
a
method
to
help
managers
determine
what
information
is
the
most
relevant
to
them
in
order
to
allow
them
to
successfully
attain
their
goals
in
increasingly
complex
world.
The
method
received
additional
background
in
Bullen
and
Rockart
(1981).
In
that
paper
authors
explain
that
the
method
reflects
the
fact
that
all
good
man-
agers,
most
often
subconsciously,
have
their
own
CSF’s
they
use
in
order
to
help
them
manage
throughout
their
careers.
The
method
they
introduced
helps
to
identify
these
factors
and
make
them
Table
1
Failure
factors
as
identified
by
Chow
and
Cao
(2008).
Dimension
Factor
Organizational
1.
Lack
of
executive
sponsorship
2.
Lack
of
management
commitment
3.
Organizational
culture
too
traditional
4.
Organizational
culture
too
political
5.
Organizational
size
too
large
6.
Lack
of
agile
logistical
arrangements
People
7.
Lack
of
necessary
skill-set
8.
Lack
of
project
management
competence
9.
Lack
of
team
work
10.
Resistance
from
groups
or
individuals
11.
Bad
customer
relationship
Process
12.
Ill-defined
project
scope
13.
Ill-defined
project
requirements
14.
Ill-defined
project
planning
15.
Lack
of
agile
progress
tracking
mechanism
16.
Lack
of
customer
presence
17.
Ill-defined
customer
role
Technical 18.
Lack
of
complete
set
of
correct
agile
practices
19.
Inappropriateness
of
technology
and
tools
public
so
managers
can
prioritize
tasks
better
and
improve
resource
allocation.
Chow
and
Cao
(2008)
give
the
more
recent
examples
of
CSF
method
usage
in
the
context
of
project
management
and
soft-
ware
development
project
area.
In
this
study
we
use
the
same
CSF
identification
method
they
used
in
order
to
confirm
or
refine
their
findings
in
specific
environment
of
former
Yugoslavia
companies.
4.
Success
factors
in
agile
software
development
projects
In
our
analysis
we
have
used
success
and
failure
factors
identi-
fied
by
Chow
and
Cao
(2008)
and
displayed
in
Tables
1
and
2.
They
have
grouped
failure
factors
in
four
categories:
orga-
nizational,
people,
process,
and
technical.
In
addition
to
failure
factors,
success
factors
contain
a
group
related
to
projects.
Authors
have
identified
19
failure
factors
and
36
success
factors
and
have
used
four
different
attributes
to
identify
perceived
level
of
over-
all
project
success.
These
four
attributes
are
the
following:
Quality
(i.e.
delivering
good
product
or
project
outcome),
Scope
(meeting
all
requirements
and
objectives),
Time
(delivering
on
time),
and
Cost
(delivering
within
estimated
cost
and
effort).
Using
these
fac-
tors
Chow
and
Cao
(2008)
have
generated
a
survey
which
we
used
for
our
study
as
well.
The
complete
survey
used
in
both
studies
is
available
in
Appendix
A.
In
the
above
mentioned
paper
authors
have
used
Cronbach’s
alpha
method
and
component
factor
analysis
with
Varimax
rotation
which
allowed
them
to
consolidate
failure
and
success
factors
to
the
number
of
12
(see
Table
3).
In
this
paper
we
will
be
using
these
consolidated
factors
which
now
act
as
hypotheses,
each
linking
Agile
project
success
factor
to
four
dimensions
used
to
measure
the
level
of
success
of
that
project.
5.
Data
collection
Data
was
collected
with
the
help
of
web
survey
that
was
dis-
tributed
to
target
population
consisting
of
managers
and
senior
developers
in
former
Yugoslavia
IT
companies.
Survey
consisted
of
four
sections.
The
Section
1
was
on
demographic
data
and
informa-
tion
about
the
project.
The
Section
2
was
on
success
factors,
and
the
Section
3
was
on
perception
of
success.
The
Section
4
was
reserved
for
additional
comments.
To
measure
importance
of
success
factors
and
perception
of
success,
a
7-point
Likert
scale
was
used.
Survey
period
lasted
one
month
and
we
have
collected
23
com-
plete
responses
to
our
survey.
Respondents
belong
to
23
different
companies
located
in
4
former
Yugoslavia
countries
out
of
5
former
Yugoslavia
countries
belonging
to
SEE
region
in
9
different
towns.
1666 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Table
2
Success
factors
as
identified
by
Chow
and
Cao
(2008).
Dimension
Factor
Organizational
1.
Strong
executive
support
2.
Committed
sponsor
or
manager
3.
Cooperative
organizational
culture
instead
of
hierarchical
4.
Oral
culture
placing
high
value
on
face-to-face
communication
5.
Organizations
where
agile
methodology
is
universally
accepted
6.
Collocation
of
the
whole
team
7.
Facility
with
proper
agile-style
work
environment
8.
Rewards
system
apropriate
for
agile
People
9.
Team
members
with
high
competence
and
expertise
10.
Team
members
with
great
motivation
11.
Managers
knowledgeable
in
agile
process
12.
Managers
who
have
light-touch
or
adaptive
management
style
13.
Coherent,
self-organizing
teamwork
14.
Good
customer
relationship
Process
15.
Following
agile-oriented
requirement
management
16.
Following
agile-oriented
project
management
process
17.
Following
agile-oriented
configuration
management
process
18.
Strong
communication
focus
with
daily
face-to-face
meetings
19.
Honoring
regular
working
schedule–no
overtime
20.
Strong
customer
commitment
and
presence
21.
Customer
having
full
authority
Technical
22.
Well-defined
coding
standards
up
front
23.
Pursuing
simple
design
24.
Rigorous
refactoring
activities
25.
Right
amount
of
documentation
26.
Regular
delivery
of
software
27.
Delivering
most
important
features
first
28.
Correct
integration
testing
29.
Appropriate
technical
training
to
team
Project
30.
Project
nature
being
non-life-critical
31.
Project
type
being
of
variable
scope
with
emergent
requirement
32.
Projects
with
dynamic,
accelerated
schedule
33.
Projects
with
small
team
34.
Projects
with
no
multiple
independent
teams
35.
Projects
with
up-front
cost
evaluation
done
36.
Projects
with
up-front
risk
analysis
done
Table
3
Consolidated
factors
or
hypotheses
as
identified
by
Chow
and
Cao
(2008).
Dimension
Factor
Organizational
v1.
Management
commitment
v2.
Organizational
environment
v3.
Team
environment
People
v4.
Team
capability
v5.
Customer
involvement
Process
v6.
Project
management
process
v7.
Project
definition
process
Technical
v8.
Agile
software
techniques
v9.
Delivery
strategy
Project
v10.
Project
nature
v11.
Project
type
v12.
Project
schedule
Table
4
Survey
respondents’
distribution
per
country.
Country
#Respondents
Serbia
18
Bosnia
and
Hercegovina 2
Croatia 2
Macedonia
1
Table
5
Survey
respondents’
distribution
per
town.
City,
Country
#Respondents
Nis,
Serbia
14
Belgrade,
Serbia 3
Paracin,
Serbia 1
Banja
Luka,
BH
1
Sarajevo,
BH 1
Zagreb,
Croatia
1
Rijeka,
Croatia
1
Skopje,
FYRM
1
Table
4
displays
breakdown
of
number
of
respondents
for
each
country.
Table
5
displays
the
number
of
respondents
for
each
town.
It
may
seem
that
large
concentration
of
number
of
respon-
dents
located
in
Nis
and
overall
number
of
respondents
from
Serbia
can
influence
the
results,
but
authors
believe
that
this
should
not
be
true.
The
reason
is
the
fact
that
all
respondents
work
in
dif-
ferent
companies
and
on
completely
dissimilar
projects
and
this
is
valid
even
if
we
observe
IT
companies
from
a
single
town
as
it
is
shown
in
the
table
by
Stankovic
(2011)
covering
technolo-
gies
used
by
more
than
40
IT
companies
operating
in
Nis.
More,
in
cases
where
respondents’
companies
actually
have
outsourcing
partners
they
are
located
in
various
countries.
The
fluctuation
of
developers
also
could
negatively
impact
the
survey
since
they
could
share
their
experiences
and
influence
each
other
toward
a
non-
representative
direction,
but
this
effect
is
diminished
since
authors
paid
strong
attention
to
survey
people
that
are
not
mutually
con-
nected.
Furthermore,
in
order
to
statistically
test
the
differences
between
respondents
from
various
towns
we
have
used
ANOVA.
The
obtained
results
have
shown
that
there
are
no
statistically
significant
differences
between
respondents
from
various
towns
except
for
the
v11
variable
so
we
can
safely
assume
that
the
distri-
bution
of
the
respondents
has
not
influenced
the
results.
We
should
also
mention
that
since
we
had
only
single
respondent
per
town
for
Croatia
and
Bosnia
and
Herzegovina
we
have
put
all
Croatian
respondents
to
one
group
and
also
all
Bosnian
respondents
to
the
other
group.
6.
Data
analysis
and
results
This
research
is
an
extension
to
exploratory
study
of
Chow
and
Cao
(2008)
and
therefore
we
use
the
same
method
they
used
for
data
analysis,
namely
multiple
regression
analysis.
By
leveraging
this
method
we
will
try
to
determine
the
relationship
between
multiple
independent
variables
(success
factors)
and
the
depend-
ent
variable
(agile
project
success)
as
well
as
to
establish
relative
predictive
importance
of
the
independent
variables
in
the
similar
manner
as
authors
of
the
previous
study
did.
For
multiple
regression
analysis
we
use
the
following
equation:
Y(Q,
S,
T,
C)
=
ˇ1SF1+
ˇ2SF2+
ˇ3SF3+
ˇ4SF4+
·
·
·
+
ˇ12SF12
where
Y
is
Agile
Project
Success
dependent
variable,
Q
is
the
Quality
dimension,
S
is
the
Scope
dimension,
T
is
the
Time
dimension,
C
is
the
Cost
dimension,
ˇiis
the
Partial
regression
coefficient
for
the
ith
Success
Factor
(SF).
In
order
to
verify
obtained
results
we
have
statistically
analyzed
answers
to
our
survey.
The
first
analysis
we
have
done
is
related
to
reliability
statistics.
We
have
analyzed
reliability
for
each
questions
group
except
for
v10,
v11,
and
v12
since
they
contained
only
1
ques-
tion
per
group.
We
have
also
analyzed
reliability
for
each
dimension
–
Organizational,
People,
Process,
Technical,
and
Project.
The
results
are
shown
in
Table
6.
Table
6
also
contains
the
number
of
items
(questions)
each
of
the
analyzed
groups/dimensions
is
explained
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1667
Table
6
Reliability
statistics.
Dimension
Factor
Cronbach’s
alpha
No.
of
items
Question
group
Dimension
Question
group
Dimension
Organizational
v1.
Management
commitment
0.380
0.652
2
12
v2.
Organizational
environment
0.442
6
v3.
Team
environment
0.548
4
People v4.
Team
capability 0.766
0.794
5
8
v5.
Customer
involvement 0.740
3
Process
v6.
Project
management
process
0.665
0.778
6
9
v7.
Project
definition
process
0.710
3
Technical
v8.
Agile
software
techniques
0.663
0.680
5
7
v9.
Delivery
strategy
0.415
2
Project v10.
Project
nature – 0.318
13
v11.
Project
type – 1
v12.
Project
schedule
–
1
with.
We
have
high
reliability
when
Cronbach’s
Alpha
is
between
0.7
and
1.
The
multiple
regression
analysis
was
done
on
full
regression
model
where
all
12
independent
variables
were
present
and
the
objective
was
to
find
the
variables
with
top
scores
which
can
be
considered
as
critical
success
factors.
The
analysis
(Appendix
C)
has
shown
that
if
we
pick
12
factors
from
the
model
they
can
explain
88.126%
of
measurement
variance.
The
structure
of
factors
(which
survey
items
are
related
to
which
factor)
is
determined
based
on
the
component
matrix
(Appendix
D).
Factors
which
we
have
obtained
by
using
factor
analysis
are
different
than
factors
considered
in
study
by
Chow
and
Cao
(2008).
Therefore,
we
have
made
decision
on
how
many
factors
to
retain
by
using
the
Scree
plot
criteria
(Fig.
1).
Scree
plot
does
not
give
us
clear
answer
on
which
factors
to
retain.
Instead
we
have
a
couple
of
rules
of
thumb.
For
example
one
rule
is
to
consider
only
those
with
eigenvalues
over
1.
We
have
instead
plotted
all
the
eigenvalues
in
their
decreasing
order
(Fig.
1).
The
plot
looks
like
the
side
of
mountain,
and
“scree”
refers
to
the
debris
fallen
from
a
mountain
and
lying
at
its
base.
So
the
scree
test
proposes
to
stop
analysis
at
the
point
where
the
mountain
ends
and
the
debris
(error)
begins.
In
our
case
this
is
somewhere
between
seventh
and
eight
factor.
The
obtained
component
matrix
shows
which
survey
questions
each
factor
contains.
The
first
factor
which
we
obtained
by
multiple
regression
analysis
is
related
to
17
questions
from
the
survey.
7
out
of
17
questions
that
this
factor
is
related
to
belong
to
the
people
dimension.
3
belong
to
organizational
dimension,
3
to
process
and
4
are
within
technical
dimension.
For
other
factors
we
get
ques-
tions
distributions
across
many
dimensions
as
well.
The
existence
of
factors
which
contain
a
variety
of
questions
not
closely
related
to
each
other
in
means
of
explaining
a
certain
hypothesis
does
not
allow
us
to
generate
meaningful
explanations.
Fig.
1.
Scree
plot
criteria.
In
the
end
we
have
decided
to
evaluate
the
model
generated
in
the
previous
study.
Factors
we
have
used
in
analysis
are
the
twelve
consolidated
factors
from
Table
3.
The
results
we
have
obtained
by
analyzing
the
influence
of
these
factors
to
the
quality,
scope,
time
and
cost
are
given
in
Tables
7a–c,
8a–c,
9a–c,
and
10a–c
respec-
tively.
The
displayed
results
help
us
to
determine
which
of
the
12
hypotheses
is
true
for
the
given
attribute
that
measures
the
agile
project
success.
Column
B
in
Table
7a
is
filled
with
coefficients
of
the
regression
model
used
for
predicting
Q
(quality)
dimension
based
on
twelve
factors
(reflected
as
hypotheses
H1a–H12a
from
Table
11).
By
look-
ing
at
the
significance
column
(Sig)
we
can
observe
that
none
of
the
Table
7a
Quality
prediction
based
on
12
factors.
Model
Unstandardized
coefficients
Standardized
coefficients
t
Sig.
B
Std.
error
Beta
1Constant
2.705
1.638
1.651
0.130
v1 −0.165
0.210
−0.279
−0.786
0.450
v2
0.184
0.380
0.201
0.484
0.639
v3
0.241
0.204
0.390
1.182
0.265
v4
−0.298
0.391
−0.418
−0.763
0.463
v5
−0.038
0.165
−0.070
−0.228
0.824
v6 0.695
0.478
0.864
1.454
0.177
v7
0.072
0.180
0.127
0.400
0.698
v8
−0.076
0.250
−0.115
−0.304
0.768
v9 −0.048
0.242
−0.059
−0.196
0.848
v10
−0.027
0.128
−0.063
−0.209
0.839
v11 0.091
0.180
0.181
0.504
0.625
v12
−0.051
0.204
−0.095
−0.251
0.807
1668 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Table
7b
Quality
variance.
Model
R
R
square
Adjusted
R
square
Std.
error
of
the
estimate
0.707
0.500
−0.100
0.788
Table
7c
Quality
prediction
ability.
Model Sum
of
squares df Mean
square
F
Sig.
1Regression 6.219
12
0.518
0.834
0.623
Residual 6.216
10
0.622
Total
12.435
22
12
given
predictors
is
having
statistically
significant
impact
on
the
final
prediction
(all
values
are
higher
than
0.05).
This
model
explains
50%
of
quality
dimension
variance
(R
square
column
in
Table
7b).
Based
on
the
obtained
significance
(column
Sig
in
Table
7c)
of
sig
=
0.623
which
is
greater
than
0.05
we
can
conclude
that
this
model
does
not
have
an
important
prediction
ability.
Table
8a
shows
the
coefficients
of
the
regression
model
used
for
predicting
S
(scope)
dimension
based
on
H1b–H12b.
Again,
based
on
the
Sig.
column
we
can
conclude
that
none
of
the
12
given
predic-
tors
is
having
statistically
significant
impact
on
the
final
prediction.
Tables
8b
and
8c
show
that
the
model
explains
58.9%
of
scope
dimension
variance,
having
significance
of
0.395
and
consequently
does
not
have
important
prediction
ability.
Tables
9a–9c
similarly
show
the
results
of
the
regression
model
for
predicting
T
(time)
dimension
based
on
the
same
factors
as
previous
two
models.
Based
on
the
Sig
column
in
Table
9a
we
conclude
that
only
H10c
(Project
nature)
has
significant
influence
(sig
=
0.029)
to
whether
the
project
will
be
finished
on
time.
The
model
explains
65.2%
of
T’s
variance
(Table
9b)
having
significance
of
0.244
which
is
still
higher
than
0.05.
The
model
does
not
have
important
prediction
ability.Tables
10a–10c
show
the
results
of
the
regression
model
for
predicting
C
(cost)
dimension
based
on
the
same
12
factors
from
previous
models.
As
we
can
observe
from
the
Sig
column
in
Table
10a,
predictors
H6d
(Project
management
pro-
cess),
H7d
(Project
definition
process),
H10d
(Project
nature),
and
H12d
(Project
schedule)
have
statistically
important
influence
on
project
cost.
The
model
explains
81.6%
of
C’s
variance
(Table
10b).
This
is
the
only
model
that
has
significant
prediction
ability
with
significance
of
sig
=
0.023
(less
than
0.05).
6.1.
Summary
of
hypothesis
testing
results
Table
11
outlines
the
results
we
obtained
in
our
study.
The
results
from
the
former
study
are
given
as
well
so
we
can
observe
whether
CSF’s
obtained
with
our
study
match
with
CSF’s
obtained
with
previous
study.
Unfortunately,
the
only
match
between
these
two
studies
we
can
identify
is
related
to
the
absence
of
evidence
that
some
assumed
prerequisites
for
success
of
Agile
projects
such
as
strong
executive
support
(v1),
organizational
environment
(v2),
or
Agile-appropriate
project
types
(v11)
are
actually
critical
factors
for
success.
Table
8a
Scope
prediction
based
on
12
factors.
Model
Unstandardized
coefficients
Standardized
coefficients
t
Sig.
B
Std.
error
Beta
1Constant
4.230
1.455
2.909
0.016
v1
0.021
0.187
0.037
0.114
0.911
v2
0.574
0.337
0.643
1.704
0.119
v3
−0.016
0.181
−0.026
−0.087
0.933
v4
−0.626
0.347
−0.897
−1.804
0.101
v5
−0.037
0.147
−0.070
−0.252
0.806
v6 0.656
0.425
0.833
1.544
0.154
v7
−0.069
0.160
−0.123
−0.430
0.677
v8
0.182
0.222
0.281
0.819
0.432
v9
−0.129
0.215
−0.165
−0.601
0.561
v10
0.052
0.114
0.125
0.456
0.658
v11 −0.169
0.159
−0.346
−1.061
0.313
v12
−0.123
0.181
−0.234
−0.679
0.513
Table
8b
Scope
variance.
Model
R
R
square
Adjusted
R
square
Std.
error
of
the
estimate
1
0.767
0.589
0.095
0.700
Table
8c
Scope
prediction
ability.
Model Sum
of
squares
Df
Mean
square
F
Sig.
1Regression
7.014
12
0.584
1.193
0.395
Residual 4.900
10
0.490
Total
11.913
22
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1669
Table
9a
Time
prediction
based
on
12
factors.
Model
Unstandardized
Coefficients
Standardized
coefficients
T
Sig.
B
Std.
error
Beta
1Constant
−0.161
2.820
−0.057
0.955
v1
−0.420
0.362
−0.343
−1.159
0.273
v2 0.518
0.653
0.275
0.793
0.446
v3 −0.127
0.351
−0.099
−0.360
0.726
v4 −0.062
0.673
−0.042
−0.093
0.928
v5
−0.018
0.285
−0.016
−0.063
0.951
v6
1.071
0.823
0.645
1.300
0.223
v7
0.126
0.311
0.107
0.406
0.693
v8 −0.305
0.431
−0.223
−0.708
0.495
v9 −0.088
0.417
−0.053
−0.211
0.837
v10 0.563
0.221
0.645
2.554
0.029
v11
0.090
0.309
0.088
0.292
0.776
v12 −0.409
0.351
−0.370
−1.167
0.270
Table
9b
Time
variance.
Model
R
R
square
Adjusted
R
square
Std.
error
of
the
estimate
1 0.808 0.652 0.235
1.357
Table
9c
Time
prediction
ability.
Model
Sum
of
squares
Df
Mean
square
F
Sig.
1Regression
34.541
12
2.878
1.563
0.244
Residual 18.416
10 1.842
Total
52.957
22
Table
10a
Cost
prediction
based
on
12
factors.
Model
Unstandardized
coefficients
Standardized
coefficients
t
Sig.
BStd.
error Beta
1Constant
4.326
1.820
2.377
0.039
v1 −0.423
0.234
−0.390
−1.811
0.100
v2
0.119
0.422
0.071
0.281
0.784
v3
−0.280
0.227
−0.247
−1.236
0.245
v4
−0.607
0.434
−0.464
−1.397
0.193
v5
0.060
0.184
0.061
0.326
0.751
v6 1.199
0.531
0.813
2.257
0.048
v7
0.488
0.200
0.468
2.435
0.035
v8
−0.027
0.278
−0.022
−0.097
0.925
v9
−0.314
0.269
−0.214
−1.165
0.271
v10
0.402
0.142
0.518
2.821
0.018
v11
0.022
0.199
0.024
0.108
0.916
v12
−0.514
0.226
−0.523
−2.270
0.047
Table
10b
Cost
variance.
Model
R
R
square
Adjusted
R
square
Std.
error
of
the
estimate
1
0.903
0.816
0.596
0.876
Table
10c
Cost
prediction
ability.
Model Sum
of
squares
Df
Mean
square
F
Sig.
1Regression 34.069
12
2.839
3.701
0.023
Residual
7.670
10
0.767
Total 41.739
22
1670 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Table
11
Summary
of
hypothesis
testing
results
(“√x”
–
hypothesis
proven
by
Chow
and
Cao
(2008)
and
not
confirmed
in
our
study;
“x√”
–
hypothesis
not
proven
in
previous
study
but
proven
here).
Quality Scope Timeliness
Cost
1.
Management
commitment
H1a
H1b
H1c
H1d
2.
Organizational
environment H2a
H2b
H2c
H2d
3.
Team
environment
H3a √x
H3b
H3c
H3d
4.
Team
capability
H4a
H4b
H4c √x
H4d √x
5.
Customer
involvement
H5a
H5b√x
H5c
H5d
6.
Project
management
process
H6a √x
H6b
H6c
H6d
x√
7.
Project
definition
process H7a H7b H7c H7d
x√
8.
Agile
software
engineering H8a √x
H8b √x
H8c
H8d
9.
Delivery
strategy
H9a
H9b √x
H9c √x
H9d √x
10.
Project
nature
H10a
H10b
H10c
x√H10d
x√
12.
Project
type
H11a
H11b
H11c
H11d
13.
Project
schedule
H12a
H12b
H12c
H12d
x√
Please
note:
Double
checkmark
symbol
“√√
”
is
not
present
in
any
case
(it
would
have
appeared
in
the
case
of
the
hypothesis
proven
in
both
studies).
In
order
to
further
investigate
why
the
results
from
the
two
stud-
ies
are
different
we
have
statistically
analyzed
the
differences
in
responses
in
relation
to
the
agile
method
used
(Scrum,
XP,
FDD),
internal
company
organization
(outsourcing,
has
own
product,
mixed
(distributed)
–
internal
product
is
a
part
of
an
outsourcing
project),
and
the
respondent
position
(Intermediate,
Senior,
Team
Leader).
Since
the
majority
of
respondents
were
using
Scrum,
the
possibility
that
this
will
mediate
the
obtained
CSF’s
was
investi-
gated
as
well.
By
using
ANOVA
we
have
confirmed
that
there
are
no
significant
differences
between
respondents
using
Scrum
and
any
other
method.
Also
significant
difference
was
not
found
among
respondents
working
at
various
positions
within
companies.
However,
significant
difference
was
found
between
respon-
dents
working
in
outsourcing
companies
or
companies
having
own
product
and
respondents
working
in
‘mixed’
companies.
This
dif-
ference
can
be
explained
with
the
factor
of
distributed
environment
since
a
team
in
‘mixed’
case
typically
consists
of
two
subparts
with
people
that
are
not
collocated.
This
is
somewhat
different
than
the
typical
outsourcing
project
where
a
team
can
be
entirely
collocated
in
the
outsourcing
country
and
where
the
only
distributed
relation
is
the
relation
between
customer
or
a
project
lead
and
the
team
itself.
Mixed
type
companies
deserve
further
explanation
since
a
number
of
respondents
we
have
surveyed
works
in
IT
companies
of
that
kind.
A
typical
example
of
the
team
organization
in
this
case
can
be
described
as
following:
a
team
consisting
of
a
part
located
in
e.g.
Serbia
and
a
part
located
in
e.g.
USA
work
on
the
same
project.
The
team
in
Serbia
uses
internal
software
product
(for
example
search
engine)
developed
to
boost
performance
or
for
further
reuse
in
similar
projects.
Serbian
team
integrates
that
internal
product
in
the
project
on
which
they
work
together
with
USA
developers
who
do
not
have
prior
experience
with
the
inter-
nal
product
of
Serbian
team.
This
puts
additional
new
challenges
which
are
not
discussed
in
this
paper.
Rather,
by
using
statistics
we
have
identified
their
existence
and
influence
to
our
results.
Further-
more
we
have
identified
the
actual
factors
which
are
influenced
by
this
setup.
The
identified
factors
are:
customer
involvement
(v5),
project
management
process
(v6),
agile
software
engineering
(v8)
and
project
nature
(v10).
Interestingly,
3
out
of
5
hypotheses
we
have
proved
in
our
study
and
4
out
of
10
proved
in
the
previous
study
are
related
to
these
factors.
By
using
Fischer’s
LSD
post
hoc
method
we
have
confirmed
that
for
the
identified
factors
the
dif-
ference
in
results
exists
between
‘mixed’
and
own
product
groups
and
‘mixed’
and
outsourcing
groups
and
not
between
outsourc-
ing
and
own
product
groups.
This
leads
us
to
conclusion
that
the
most
probable
reason
for
the
difference
in
obtained
results
between
our
and
previous
study
is
the
distributed
environment
of
‘mixed’
companies.
What
is
also
interesting
is
the
fact
that
4
out
of
5
hypotheses
which
proved
right
belong
to
the
cost
domain.
One
obvious
reason
for
this
is
that
the
cost
is
an
important
driving
factor
when
deciding
to
outsource
projects
to
SEE
countries.
The
developers
and
man-
agers
from
former
Yugoslavia
are
aware
of
that
fact
which
further
causes
to
pay
more
attention
on
it.
Our
study
has
successfully
identified
that
situation.
6.2.
Research
limitations
As
we
have
already
mentioned
the
conducted
research
has
certain
limitations.
The
first
is
that
only
three
out
of
a
seven
agile
methods
mentioned
in
previous
study
were
used
on
projects
described
by
our
respondents.
The
second
is
strong
bias
toward
Scrum
which
can
be
considered
as
an
evolution
to
the
bias
reported
in
previous
study
toward
XP.
Scrum
is
nowadays
reported
to
be
the
most
widely
accepted
agile
practice
(State
of
Agile
Survey,
2011).
Our
study
has
shown
that
IT
companies
from
former
Yugoslavia
countries
are
not
the
exception.
By
using
the
invitation
based
sur-
vey
instead
of
publicly
available
we
have
avoided
the
bias
that
certain
respondents
could
have
toward
representing
better
project
success
than
what
it
actually
was.
We
did
not
pick
the
survey
participants
among
people
who
have
direct
benefit
of
subjective
representation
of
project
success.
However,
the
research
setting
in
our
and
in
the
previous
study
did
not
address
how
well
agile
meth-
ods
have
been
followed
by
the
respondents.
Perhaps
better
and
more
accurate
model
can
be
obtained
if
we
extract
only
respon-
dents
who
were
properly
following
agile
methods
they
employ
for
software
development.
We
see
this
as
a
potential
direction
to
follow
in
our
future
research
related
to
the
subject.
The
final
and
pos-
sibly
the
most
important
limitation
is
the
sample
size.
Although
sample
size
of
23
is
lot
smaller
than
in
the
previous
study,
the
rel-
ative
ratio
of
respondents
to
the
overall
number
of
practitioners
in
the
geographical
area
covered
by
our
survey
is
better
than
the
same
ratio
from
the
previous
study
(109
respondents
from
all
over
the
world
versus
23
for
the
former
Yugoslavia
part
of
SEE
region
only).
7.
Conclusions
In
this
study
we
have
tried
to
verify
the
classification
of
crit-
ical
success
factors
previously
described
in
study
by
Chow
and
Cao
(2008).
The
regression
analysis
done
on
our
collected
data
has
introduced
three
more
factors
that
could
potentially
be
considered
as
critical
success
factors
in
terms
of
Timeliness
and
Cost
(H10
in
terms
of
Timeliness
and
Cost,
and
H7
together
with
H12
in
terms
of
Cost).
On
the
opposite
side,
the
obtained
results
did
not
confirm
that
either
of
the
factors
from
the
previous
study
can
be
consid-
ered
as
critical
success
factor
in
the
space
of
former
Yugoslavia
IT
companies.
However,
our
results
match
with
the
results
from
the
previous
study
in
suggesting
that
strong
executive
support
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1671
and
project
type
has
no
influence
on
the
success
of
agile
project.
Our
study
similarly
suggests
that
organization
environment
(agile-
style
work
facility)
is
not
a
factor
with
strong
influence
on
the
success
of
agile
projects
carried
out
in
former
Yugoslavia
IT
com-
panies.
In
our
study
only
5
out
of
48
hypotheses
proved
right
and
together
with
10
out
of
48
proven
in
the
previous
study
leads
us
to
conclusion
that
we
should
try
to
formulate
different
success
fac-
tors
or
try
to
model
the
success
of
agile
projects
with
different
method.
A
recently
published
survey
of
research
literature
(McLeod
and
MacDonell,
2011)
covering
period
1996–2006
with
focus
on
empirical
analyses
has
proposed
a
new
classification
frame-
work
of
the
types
of
factors
that
are
believed
to
have
important
influence
on
project
success.
Their
classification
largely
overlaps
with
the
classification
observed
in
this
study.
However
as
we
did
not
succeed
to
prove
the
critical
connection
of
the
large
majority
of
described
factors
to
project
outcome
and
as
we
are
aware
of
the
flaws
that
empirical
studies
can
have,
such
as
shown
with
infamous
“IROP
study”
by
Zeller
et
al.
(2011),
we
think
that
different
method,
perhaps
AHP
method
(Analytic
Hierarchy
Process)
combined
with
the
latest
classification
from
McLeod
and
MacDonell
(2011)
will
perhaps
reveal
more
relevant
results.
Many
research
results
are
available
to
us
that
show
the
benefits
agile
practices
have
to
the
project
cost
and
timeliness.
As
a
possible
other
direction
to
consider
in
the
near
future
we
plan
on
investi-
gating
how
we
can
expand
the
domain
on
which
agile
practices
should
be
applied
and
consider
their
use
to
stop
building
worthless
software
at
the
first
place
(Patton,
2011).
Acknowledgement
The
work
presented
here
was
supported
by
the
Serbian
Ministry
of
Education
and
Science
(projects
III44006
and
III42006).
Appendix
A.
Survey
instrument
Agile
software
development
project
survey
Section
1
– Demographics
Thank
you
very
much
for
agreeing
to
spend
a
few
minutes
of
your
time
to
complete
this
survey.
If
you
have
been
involved
with
more
than
one
agile
project,
please
pick
one
(either
successful
or
failed)
that
was
most
relevant
or
most
telling
with
regard
to
critical
success
factors
of
such
a
project.
Section
1.1
For
questions
1–5
please
provide
some
basic
information
regarding
the
agile
project.
1. Project
description
(i.e.
what
the
software
was
about):
2.
Agile
method
used:
3.
Size
of
the
project
(number
of
project
team
members):
4.
Length
of
the
project
(in
months):
5.
Location
of
the
project
(country):
Section
1.2
For
questions
6–13
please
provide
some
basic
information
regarding
your
organization
and
yourself
(all
information
provided
will
be
kept
completely
confidential):
6.
Company
name
(optional):
7. Company
size
(ranges
of
number
of
employees):
8. Company
revenues
(ranges
of
annual
sales
dollar
amounts):
9.
Company
industry
(selection
of
pre-determined
industries):
10.
Your
job
responsibility
in
the
project
(project
manager,
team
lead,
team
member,
customer,
organization
management,
other)
11.
Your
level
of
experience
with
agile
projects
(in
years):
12.
Number
of
agile
project
you
have
been
involved
with:
13.
Please
provide
your
name,
address,
phone
and
email
informa-
tion,
should
we
need
to
get
some
clarification
regarding
your
response
to
this
survey
(optional):
Section
2
–
Success
factors
of
the
agile
project
This
section
includes
all
the
possible
success
factors
of
soft-
ware
development
projects
using
agile
methods,
which
had
been
compiled
and
consolidated
from
the
academic
and
professional
lit-
erature.
Responses
to
each
of
the
following
statements
range
from
1
to
7
as
follows:
1
Strongly
disagree
2 Disagree
3
Somewhat
disagree
4 Neither
disagree
or
agree
5
Somewhat
agree
6 Agree
7
Strongly
agreeN/A–Not
applicable/Don’t
know
Section
2.1
–
Organizational
dimension
14.
The
project
received
strong
executive
support.
“Executive”
may
mean
the
whole
Board
of
Directors
or
the
CEO,
CFO,
CIO,
etc.
who
influenced
the
decision-making:
15. The
project
had
a
committed
sponsor
or
a
committed
organi-
zation
manager.
An
example
of
a
committed
sponsor/manager
would
be
one
who
would
stand
up
to
critics
and
vouch
for
the
agile
method
in
a
non-agile
organizational
environment:
16.
The
organization
had
a
cooperative
culture
instead
of
hierar-
chal.
A
cooperative
culture
is
one
that
fosters
ad-hoc
teams
driven
by
the
needs
of
the
job
at
hand
(e.g.
start-up
organiza-
tions)
while
a
hierarchal
culture
is
one
that
has
clear
divisions
of
responsibility
and
authority
(e.g.
established,
large
organi-
zations):
17.
The
organization
had
an
oral
culture
placing
high
value
on
fluid,
face-to-face
communication
style:
18.
Agile
methodology
was
universally
accepted
in
the
organiza-
tion:
19.
The
organization
had
a
reward
system
that
was
appropriate
for
agile
behavior.
An
example
of
such
a
reward
system
would
be
one
that
recognizes
both
individual
and
team
contributions,
and
that
rewards
results
of
the
agile
pilot
projects:
20.
The
project
team
was
collocated,
i.e.
all
team
members
worked
in
the
same
location
for
ease
of
communication
and
casual,
constant
contact:
21.
The
project
team
worked
in
a
facility
with
proper
agile-style
work
environment,
e.g.
a
dedicated
office
with
pair
program-
ming
workstations,
communal
area,
ample
wall
spaces
for
postings,
no
separate
cubicles
or
offices,
etc.:
Section
2.2
–
People
dimension
22.
The
selected
project
team
members
had
high
technical
com-
petence
and
expertise
(problem
solving,
programming,
subject
matter):
23.
Project
team
members
had
great
motivation
and
were
commit-
ted
to
the
project
success:
24.
Project
management
was
knowledgeable
in
agile
principles
and
processes:
25. Project
management
had
light-touch
and/or
adaptive
man-
agement
style,
e.g.
encouraging
creative,
flexible
working
1672 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
environment
while
taking
advantage
of
mutual
interactions
among
the
project’s
various
parts
and
steering
them
toward
continuous
learning
and
adaptation:
26.
The
project
team
worked
in
a
coherent,
self-organizing
team-
work
manner,
i.e.
relying
on
the
collective
ability
of
an
autonomous
team
to
solve
problems
and
adapt
to
changing
conditions:
27.
Project
management
had
a
good
relationship
with
the
cus-
tomer:
Section
2.3
–
Process
dimension
28.
The
project
scope
and
objectives
were
well-defined:
29.
The
project
followed
agile-oriented
requirement
process,
e.g.
specifying
initial
requirements
at
a
very
high
level,
leaving
much
room
for
interpretation
and
adaptation
as
the
project
progressed:
30. The
project
followed
agile
project
management
style,
e.g.
plans
generally
not
being
documented
in
great
detail,
and
deviations
and
changes
being
readily
accepted
and
incorporated
into
the
project
plan:
31. The
project
followed
agile-oriented
configuration
management
process,
e.g.
employing
good
version
control
or
source
code
management
to
accommodate
the
refactoring
efforts
and
fre-
quent
builds:
32.
The
project
manager
followed
an
agile-friendly
progress
track-
ing
mechanism,
e.g.
using
flexible
time-boxing
or
rapid-pace
progress
measurement
techniques
instead
of
document
mile-
stones
or
work
breakdown
structure:
33.
The
project
had
strong
communication
focus
and
rigorous
communication
schedule,
i.e.
face-to-face
and
instant
commu-
nication
channels
(between
team
members,
between
team
and
management,
and
between
team
and
customers),
daily
stand-
up
meetings,
build
cycle
meetings,
etc.:
34.
The
project
honored
regular
working
schedule,
i.e.
40-hour
work
week,
no
overtime:
35.
The
project
had
strong
customer
commitment
and
pres-
ence,
i.e.
having
at
least
one
customer
representative
on
site
working
hard
and
full-time
as
a
member
of
the
project
team:
36.
The
customer
representative
on
the
project
had
full
authority
and
knowledge
to
make
decisions
on-site,
such
as
approv-
ing,
disapproving,
and
prioritizing
project
requirements
and
changes:
Section
2.4
–
Technical
dimension
37.
The
project
imposed
a
well-defined
coding
standards
up
front:
38.
The
project
pursued
simple
design,
e.g.
programmers
used
the
simplest
possible
design
for
each
module
to
avoid
waste
and
to
facilitate
cooperative
work:
39.
The
project
pursued
vigorous
refactoring
activities
to
ensure
the
results
are
optimal
and
to
accommodate
well
all
changes
in
requirements:
40.
The
project
maintained
right
amount
of
documentation
for
agile
purpose,
i.e.
not
too
focused
on
producing
elaborate
doc-
umentation
as
milestones
but
not
ignoring
documentation
altogether
either:
41.
The
project
followed
continuous
and
rigorous
unit
and
integra-
tion
testing
strategy
for
each
and
every
iteration:
42.
The
project
delivered
working
software
regularly
within
short
periods
of
time:
43.
The
project
delivered
most
important
features
first:
44.
The
project
employed
proper
platforms,
technologies,
and
tools
suitable
for
agile
practice,
e.g.
object-oriented
development
techniques,
tools
supporting
rapid
iterative
development,
pro-
cesses
supporting
refactoring,
etc.:
45.
The
project
provided
appropriate
technical
training
to
team,
including
training
on
subject
matter
and
agile
processes:
Section
2.5
–
Project
dimension
46.
The
project
nature
was
a
non-life-critical
software
project,
although
it
could
be
a
business
mission-critical
software.
(Examples
of
life-critical
projects
are
certain
advanced
weapons
programs
or
air
traffic
control
programs):
47.
The
project
type
was
of
variable
scope
with
emergent
require-
ments:
48.
The
project
had
a
dynamic,
accelerated
schedule:
49. The
project
had
a
small
team
size
(20
members
or
less):
50.
The
project
had
no
multiple,
independent
teams
working
together:
51.
The
project
had
up-front,
detailed
cost
evaluation
done
and
approved:
52.
The
project
had
up-front
risk
analysis
done
and
evaluated
for
using
agile
method:
Section
3
–
Perception
of
success
of
the
agile
project
This
section
includes
aspects
of
your
perceived
level
of
success
of
the
agile
software
development
project
at
hand.
Responses
to
each
of
the
following
statements
range
from
1
to
7
as
follows:
1
Very
unsuccessful
2
Unsuccessful
3
Somewhat
unsuccessful
4
Neutral
5
Somewhat
successful
6
Successful
7
Very
successful
53.
The
project
was
successful
in
terms
of
quality
of
the
project
outcome
or
of
the
resulting
software
product:
54.
The
project
was
successful
in
terms
of
scope
and
requirements
of
the
project
being
met:
55.
The
project
was
successful
in
terms
of
timeliness
of
project
completion:
56.
The
project
was
successful
in
terms
of
costs
and
efforts
being
under
budget
or
within
estimates:
Section
4
–
Additional
comments
This
section
includes
one
free-form
text
area
where
you
are
invited
to
enter
any
additional
comments
on
any
matter
which
has
not
been
covered
in
the
survey.
Your
input
may
be
used
for
follow-up
for
clarification
or
for
further
exploration
if
necessary:
57.
Please
enter
any
additional
comments
or
thoughts
here:
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1673
Appendix
B.
Mapping
variables
to
survey
questions
Variable
Item
attribute
Variable
type
Data
type
Survey
question
Demographic
profile Thirteen
different
attributes
on
personal,
organizational,
and
project
information
Nominal
or
ratio
1–13
v1.
Management
commitment
i1.
Strong
executive
support Independent
Interval 14
i2.
Committed
sponsor
or
manager
15
v2.
Organization
environment
i3.
Cooperative
organizational
culture
instead
of
hierarchal Independent
Interval 16
i4.
Oral
culture
placing
high
value
on
face-to-face
communication 17
i5.
Organizations
where
agile
methodology
is
universally
accepted
18
i6.
Reward
system
appropriate
for
agile 19
i8.
Facility
with
proper
agile-style
work
environment
21
i31.
Appropriate
platform
technologies
and
tools
44
v3.
Team
environment
i7.
Collocation
of
the
whole
team Independent
Interval 20
i13.
Coherent,
self-organizing
teamwork 26
i36.
Projects
with
small
team 49
i37.
Projects
with
no
multiple
independent
teams
50
v4.
Team
capability i9.
Team
members
with
high
competence
and
expertise Independent
Interval 22
i10.
Team
members
with
great
motivation
23
i11.
Managers
knowledgeable
in
agile 24
i12.
Managers
who
have
light-touch
or
adaptive
management
style
25
i32.
Appropriate
technical
training
to
team
45
v5.
Customer
involvement
i14.
Good
customer
relationship Independent
Interval 27
i22.
Strong
customer
commitment
and
presence
35
i23.
Customer
having
full
authority 36
v6.
Project
management
process
i16.
Following
agile-oriented
requirement
management
process Independent
Interval 29
i17.
Following
agile-oriented
project
management
process 30
i18.
Following
agile-oriented
configuration
management
process
31
i19.
Good
progress
tracking
mechanism
32
i20.
Strong
communication
focus
with
daily
face-to-face
meetings 33
i21.
Honoring
regular
working
schedule
34
v7.
Project
definition
process
i15.
Project
scope
well-defined Independent Interval 28
i38.
Projects
with
up-front
cost
evaluation
done
51
i39.
Projects
with
up-front
risk
analysis
done
52
v8.
Agile
software
engineering
techniques
i24.
Well-defined
coding
standards
up
front Independent
Interval 37
i25.
Pursuing
simple
design
38
i26.
Rigorous
refactoring
activities 39
i27.
Right
amount
of
documentation
40
i28.
Correct
integration
testing 41
v9.
Delivery
strategy i29.
Regular
delivery
of
software Independent
Interval 42
i30.
Delivering
most
important
features
first
43
v10.
Project
nature
i33.
Project
nature
being
non-life-critical
Independent
Interval
44
v11.
Project
type
i34.
Project
type
being
of
variable
scope
with
emergent
requirement
Independent
Interval
45
v12.
Project
schedule i35.
Projects
with
dynamic,
accelerated
schedule Independent Interval 46
Appendix
C.
Factor
analysis
Component
Initial
eigenvalues
Extraction
sums
of
squared
loadings
Total
%
of
variance
Cumulative
%
Total
%
of
variance
Cumulative
%
1
9.362
24.005
24.005
9.362
24.005
24.005
2 4.267
10.942
34.947
4.267
10.942
34.947
3
3.610
9.257
44.204
3.610
9.257
44.204
4
3.044
7.805
52.010
3.044
7.805
52.010
5
2.712
6.953
58.963
2.712
6.953
58.963
6
2.243
5.751
64.714
2.243
5.751
64.714
7 2.101
5.388
70.102
2.101
5.388
70.102
8
1.587
4.069
74.171
1.587
4.069
74.171
9
1.559
3.998
78.169
1.559
3.998
78.169
10
1.410
3.615
81.784
1.410
3.615
81.784
11
1.314
3.369
85.153
1.314
3.369
85.153
12
1.159
2.972
88.126
1.159
2.972
88.126
13
1.084
2.781
90.906
14
0.833
2.135
93.042
15
0.725
1.859
94.901
16
0.485
1.244
96.145
17
0.398
1.022
97.166
18
0.311
0.798
97.965
19
0.286
0.733
98.697
20
0.225
0.576
99.273
21
0.192
0.493
99.766
22
0.091
0.234
100.000
23
0.000
0.000
100.000
24 0.000
0.000
100.000
25 0.000
0.000
100.000
1674 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Appendix
C
(Continued)
Component
Initial
eigenvalues
Extraction
sums
of
squared
loadings
Total %
of
variance Cumulative
%
Total
%
of
variance
Cumulative
%
26 0.000
0.000
100.000
27
0.000
0.000
100.000
28 0.000
0.000
100.000
29
0.000
0.000
100.000
30
0.000
0.000
100.000
31
0.000
0.000
100.000
32 0.000
0.000
100.000
33
0.000
0.000
100.000
34 0.000
0.000
100.000
35
0.000
0.000
100.000
36
0.000
0.000
100.000
37
0.000
0.000
100.000
38 0.000
0.000
100.000
39 0.000
0.000
100.000
Appendix
D.
Component
matrix
Component
1
2
3
4
5
6
7
1
p32
0.786
−0.187
−0.170
0.194
−0.306
0.047
−0.103
p15 0.760
−0.270
−0.047
0.094
−0.009
0.221
0.287
p26
0.757
−0.049
−0.006
−0.110
−0.062
−0.041
−0.504
p24 0.754
0.295
−0.219
0.044
−0.002
−0.322
−0.077
p10
0.745
−0.052
0.103
−0.064
−0.448
−0.032
−0.071
p11
0.712
0.095
0.018
−0.099
−0.156
−0.158
0.303
p21
0.711
−0.146
−0.144
0.199
−0.054
0.063
0.342
p23
0.672
0.115
−0.303
0.196
0.158
0.174
−0.122
p27 0.649
−0.043
0.288
−0.317
0.284
0.267
−0.286
p18
0.626
−0.151
−0.430
−0.511
0.031
−0.151
0.028
p8 0.604
0.443
−0.253
0.131
0.296
−0.139
−0.035
p4
0.536
−0.261
0.381
0.112
−0.069
−0.416
−0.037
p12
0.524
−0.469
0.314
−0.273
0.165
−0.184
0.108
p22
0.484
−0.280
−0.334
0.328
−0.125
0.233
0.065
p29
0.482
0.451
0.336
−0.264
−0.131
0.203
−0.016
p28 0.477
0.236
0.091
−0.089
−0.045
−0.078
−0.060
p14
0.453
−0.059
−0.093
0.119
0.265
0.381
−0.073
p16 0.425
−0.418
0.144
−0.148
0.022
0.386
0.197
p17
0.419
−0.253
0.274
−0.332
0.111
0.177
0.156
p7
0.412
0.289
0.261
0.373
0.288
−0.362
−0.027
2
p19
0.518
−0.648
−0.117
−0.360
0.127
−0.084
0.125
p25
0.167
−0.615
0.115
0.233
0.036
−0.281
−0.134
p5
0.324
0.603
0.119
−0.421
0.024
−0.153
0.100
p20
0.432
0.555
−0.257
0.490
0.011
−0.041
−0.131
p34
−0.095
0.544
0.170
−0.369
0.510
0.104
−0.018
p6
0.433
0.533
0.085
−0.176
0.016
0.281
0.202
p35
0.175
0.379
−0.342
−0.342
0.342
0.242
−0.370
3
p36
0.395
0.390
0.687
0.257
−0.172
−0.170
−0.027
p31
0.432
0.098
−0.657
−0.298
−0.097
−0.034
−0.025
p33
0.090
0.331
0.587
0.244
−0.010
−0.060
0.239
p3
0.003
−0.369
0.552
−0.122
0.088
0.352
−0.204
p13
0.462
−0.018
0.521
0.208
0.044
−0.024
−0.482
4
p38
0.091
−0.063
−0.368
0.666
0.354
0.098
0.089
p39 0.465
−0.193
−0.009
0.526
0.329
0.278
−0.142
5
p9
0.251
0.228
−0.004
0.085
−0.749
0.011
0.139
p37
0.017
−0.138
0.393
0.177
0.529
0.095
0.192
6
p1
0.359
−0.210
0.009
−0.168
0.285
−0.578
0.270
p30 0.167
0.163
0.228
0.076
−0.463
0.545
0.248
7
p2
0.123
0.261
−0.021
0.068
0.380
0.051
0.745
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1675
Appendix
E.
Analysis
of
variance
between
town
groups
Sum
of
squares
df
Mean
square
F
Sig.
v1 Between
groups
10.361
5
2.072
0.827
0.548
Within
groups 42.595
17
2.506
Total
52.957
22
v2 Between
groups
83.512
5
16.702
0.773
0.582
Within
groups
367.357
17
21.609
Total 450.870
22
v3 Between
groups
33.224
5
6.645
0.508
0.766
Within
groups 222.429
17
13.084
Total
255.652
22
v4 Between
groups
87.122
5
17.424
0.597
0.703
Within
groups
496.095
17
29.182
Total 583.217
22
v5 Between
groups 176.122
5 35.224
2.660
0.059
Within
groups
225.095
17
13.241
Total
401.217
22
v6 Between
groups
82.389
5
16.478
0.472
0.792
Within
groups 593.524
17
34.913
Total
675.913
22
v7 Between
groups
36.969
5
7.394
0.559
0.730
Within
groups
224.857
17
13.227
Total
261.826
22
v8 Between
groups 102.389
5 20.478
0.522
0.757
Within
groups
667.524
17
39.266
Total 769.913
22
v9 Between
groups
30.361
5
6.072
0.627
0.681
Within
groups
164.595
17
9.682
Total 194.957
22
v10 Between
groups
18.486
5
3.697
1.099
0.397
Within
groups 57.167
17
3.363
Total
75.652
22
v11 Between
groups
55.097
5
11.019
13.026
0.000
Within
groups
14.381
17
0.846
Total
69.478
22
v12 Between
groups 2.199
5
0.440
0.157
0.975
Within
groups
47.714
17
2.807
Total 49.913
22
Appendix
F.
Analysis
of
variance
between
agile
method
groups
Sum
of
squares
df
Mean
square
F
Sig.
v1 Between
groups 5.601
2
2.800
1.183
0.327
Within
groups
47.356
20
2.368
Total 52.957
22
v2 Between
groups
16.303
2
8.152
0.375
0.692
Within
groups
434.566
20
21.728
Total 450.870
22
v3 Between
groups
59.024
2
29.512
3.002
0.072
Within
groups
196.629
20
9.831
Total
255.652
22
v4 Between
groups
29.924
2
14.962
0.541
0.591
Within
groups
553.294
20
27.665
Total
583.217
22
v5 Between
groups
38.703
2
19.352
1.068
0.363
Within
groups
362.514
20
18.126
Total
401.217
22
v6 Between
groups
28.775
2
14.388
0.445
0.647
Within
groups
647.138
20
32.357
Total
675.913
22
v7 Between
groups
28.475
2
14.238
1.220
0.316
Within
groups
233.351
20
11.668
Total
261.826
22
v8 Between
groups
74.090
2
37.045
1.065
0.364
Within
groups
695.823
20
34.791
Total
769.913
22
v9 Between
groups
21.897
2
10.948
1.265
0.304
Within
groups
173.060
20
8.653
Total
194.957
22
v10 Between
groups
9.024
2
4.512
1.354
0.281
Within
groups
66.629
20
3.331
Total
75.652
22
v11 Between
groups
0.694
2
0.347
0.101
0.905
Within
groups
68.784
20
3.439
1676 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Appendix
F
(Continued)
Sum
of
squares
df
Mean
square
F
Sig.
Total 69.478
22
v12 Between
groups
6.256
2
3.128
1.433
0.262
Within
groups 43.657
20
2.183
Total
49.913
22
Appendix
G.
Analysis
of
variance
between
organization
type
groups
Sum
of
Squares df
Mean
Square
F
Sig.
v1 Between
groups
4.367
2
2.184
0.899
0.423
Within
groups
48.589
20
2.429
Total
52.957
22
v2 Between
groups
29.941
2
14.970
0.711
0.503
Within
groups 420.929
20 21.046
Total 450.870
22
v3 Between
groups
8.420
2
4.210
0.341
0.715
Within
groups
247.232
20
12.362
Total
255.652
22
v4 Between
groups 56.467
2
28.234
1.072
0.361
Within
groups
526.750
20
26.338
Total
583.217
22
v5 Between
groups
104.360
2
52.180
3.516
0.049
Within
groups
296.857
20
14.843
Total 401.217
22
v6 Between
groups
262.484
2
131.242
6.349
0.007
Within
groups 413.429
20
20.671
Total
675.913
22
v7 Between
groups
38.898
2
19.449
1.745
0.200
Within
groups
222.929
20
11.146
Total
261.826
22
v8 Between
groups 278.324
2
139.162
5.662
0.011
Within
groups
491.589
20
24.579
Total 769.913
22
v9 Between
groups
0.582
2
0.291
0.030
0.971
Within
groups
194.375
20
9.719
Total 194.957
22
v10 Between
groups
20.920
2
10.460
3.882
0.039
Within
groups 54.732
20
2.737
Total
75.652
22
v11 Between
groups
4.675
2
2.337
0.721
0.498
Within
groups
64.804
20
3.240
Total
69.478
22
v12 Between
groups 8.199
2 4.099
1.965
0.166
Within
groups
41.714
20
2.086
Total 49.913
22
Appendix
H.
Fischer’s
LSD
post
hoc
method
for
analysis
of
differences
among
individual
organizational
types
groups
Variable
(I)
Organis
(J)
Organis
Mean
difference
(I–J)
Std.
error
Sig.
v5 Has
own
product
Outsourcing
0.500
1.926
0.798
Mixed
(distributed)
4.857*1.994
0.024
Outsourcing Has
own
product
−0.500
1.926
0.798
Mixed
(distributed)
4.357*1.994
0.041
Mixed
(distributed)
Has
own
product
−4.857*1.994
0.024
Outsourcing
−4.357*1.994
0.041
v6 Has
own
product
Outsourcing
−1.000
2.273
0.665
Mixed
(distributed) 6.786*2.353
0.009
Outsourcing
Has
own
product
1.000
2.273
0.665
Mixed
(distributed)
7.786*2.353
0.004
Mixed
(distributed)
Has
own
product
−6.786*2.353
0.009
Outsourcing
−7.786*2.353
0.004
v8 Has
own
product
Outsourcing
1.125
2.479
0.655
Mixed
(distributed)
8.054*2.566
0.005
Outsourcing
Has
own
product
−1.125
2.479
0.655
Mixed
(distributed)
6.929*2.566
0.014
Mixed
(distributed)
Has
own
product
−8.054*2.566
0.005
Outsourcing
−6.929*2.566
0.014
v10 Has
own
product
Outsourcing
0.375
0.827
0.655
Mixed
(distributed)
2.232*0.856
0.017
Outsourcing
Has
own
product
−0.375
0.827
0.655
Mixed
(distributed)
1.857*0.856
0.042
Mixed
(distributed) Has
own
product
−2.232*0.856
0.017
Outsourcing
−1.857*0.856
0.042
*Mean
difference
column
represents
values
for
which
significance
≤
0.05.
D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678 1677
Appendix
I.
Analysis
of
variance
of
answers
between
different
team
role
groups
Sum
of
squares
df
Mean
square
F
Sig.
v1 Between
groups
10.040
2
5.020
2.339
0.122
Within
groups 42.917
20
2.146
Total
52.957
22
v2 Between
groups
32.670
2
16.335
0.781
0.471
Within
groups
418.200
20
20.910
Total 450.870
22
v3 Between
groups
30.486
2
15.243
1.354
0.281
Within
groups 225.167
20
11.258
Total
255.652
22
v4 Between
groups
12.667
2
6.334
0.222
0.803
Within
groups
570.550
20
28.528
Total 583.217
22
v5 Between
groups 11.017
2 5.509
0.282
0.757
Within
groups
390.200
20
19.510
Total
401.217
22
v6 Between
groups
20.696
2
10.348
0.316
0.733
Within
groups 655.217
20
32.761
Total
675.913
22
v7 Between
groups
2.776
2
1.388
0.107
0.899
Within
groups
259.050
20
12.953
Total
261.826
22
v8 Between
groups 72.863
2 36.432
1.045
0.370
Within
groups
697.050
20
34.853
Total 769.913
22
v9 Between
groups
3.590
2
1.795
0.188
0.830
Within
groups
191.367
20
9.568
Total 194.957
22
v10 Between
groups
3.819
2
1.909
0.532
0.596
Within
groups 71.833
20
3.592
Total
75.652
22
v11 Between
groups
11.112
2
5.556
1.904
0.175
Within
groups
58.367
20
2.918
Total
69.478
22
v12 Between
groups 2.546
2
1.273
0.538
0.592
Within
groups
47.367
20
2.368
Total 49.913
22
References
Anderson,
D.J.,
2010.
Kanban:
Successful
Evolutionary
Change
for
Your
Technology
Business.
Blue
Hole
Press,
Sequim,
WA.
Beck,
K.,
1999.
Embracing
change
with
extreme
programming.
Computer
32
(10),
70–77.
Beck,
K.,
Andres,
C.,
2004.
Extreme
Programming
Explained:
Embrace
Change.
Addison-Wesley
Professional,
Boston,
MA.
Bullen,
C.V.,
Rockart,
J.F.,
1981.
A
Primer
on
critical
success
factors,
Information
Systems
Research
no.
69.
Chow,
T.,
Cao,
D.B.,
2008.
A
survey
study
of
critical
success
factors
in
agile
software
projects.
The
Journal
of
Systems
and
Software
81,
961–971.
Coad,
P.,
Lefebvre,
E.,
Luca,
J.D.,
1999.
Chapter
6
Feature-driven
development.
In:
Java
Modeling
in
Color
with
UML:
Enterprise
Components
and
Process.
Prentice
Hall
PTR,
Upper
Saddle
River,
NJ.
Freudenberg,
S.,
Sharp,
H.,
2010.
The
top
10
burning
research
questions
from
prac-
titioners.
IEEE
Software
27
(5),
8–9.
Hansson,
C.,
Dittrich,
Y.,
Gustafsson,
B.,
Zarnak,
S.,
2006.
How
agile
are
indus-
trial
software
development
practices?
The
Journal
of
Systems
and
Software
79,
1295–1311.
Jørgensen,
M.,
Boehm,
B.,
2009.
Software
development
effort
estimation:
formal
models
or
expert
judgment?
(Viewpoints
article).
IEEE
Software
26
(2),
14–19.
Johansson,
C.,
2000.
Surprising
Results
from
a
measurement
study
–
is
software
measurement
an
exaggerated
and
over-emphasised
area.
In:
Published
on
CD-
ROM
in
the
3rd
European
Software
Measurement
Conference
FESMA-AEMES
2000,
18–20
October
2000,
Madrid,
Spain.
Kniberg,
H.,
Skarin,
M.,
2010.
Kanban
and
Scrum
–
Making
the
Most
of
Both,
Lulu.com.
McLeod,
L.,
MacDonell,
S.G.,
2011.
Factors
that
affect
software
systems
development
project
outcomes.
ACM
Computing
Surveys
43
(4),
1–56.
Moe,
N.B.,
Dingsoyr,
T.,
Dyba,
T.,
2010.
A
teamwork
model
for
understanding
an
agile
team:
a
case
study
of
a
Scrum
project.
Information
and
Software
Technology
52,
480–491.
Palmer,
S.R.,
Felsing,
M.,
2002.
A
Practical
Guide
to
Feature-Driven
Development.
Prentice
Hall
PTR,
Upper
Saddle
River,
NJ.
Rockart,
J.,
1979.
Chief
executives
define
their
own
information
needs.
Harvard
Business
Review
March/April,
81–92.
Shore,
J.,
Warden,
S.,
2008.
The
Art
of
Agile
Development.
O’Reilly
Media,
Inc,
Beijing
Sebastopol,
CA.
Smite,
D.,
Moe,
N.B.,
Agerfalk,
P.J.,
2010a.
Fundamentals
of
agile
distributed
software
development.
In:
Smite,
D.,
Moe,
N.B.,
Agerfalk,
P.J.
(Eds.),
Agility
Across
Time
and
Space.
Springer-Verlag,
Berlin,
Heidelberg,
pp.
3–7.
Smite,
D.,
Moe,
N.B.,
Agerfalk,
P.J.,
2010b.
Agility
across
time
and
space:
sum-
ming
up
and
planning
for
the
future.
In:
Smite,
D.,
Moe,
N.B.,
Agerfalk,
P.J.
(Eds.),
Agility
Across
Time
and
Space.
Springer-Verlag,
Berlin,
Heidelberg,
pp.
333–337.
Williams,
L.A.,
Cockburn,
A.,
2003.
Guest
editors’
introduction:
agile
software
devel-
opment:
it’s
about
feedback
and
change.
IEEE
Computer
36
(6),
39–43.
Zeller,
A.,
Zimmermann,
T.,
Bird,
C.,
2011.
Failure
is
a
four-letter
word
–
a
parody
in
empirical
research.
In:
Proceedings
of
the
7th
International
Conference
on
Predictive
Models
in
Software
Engineering,
ACM
New
York,
NY,
USA,
Article
No.
5.
Web
references
Khramtchenko,
S.,
2004.
Comparing
eXtreme
Programming
and
Feature
Driven
Development
in
academic
and
regulated
environments
[online]
Final
paper
for
CSCIE-275:
Software
Architecture
and
Engineering
(accessed
24.06.12),
pp.
1–24.
<http://www.extremeprogramming.org>
(accessed
24.06.12).
<http://www.versionone.com/Agile101/Methodologies.asp>
(accessed
24.06.12).
Larman,
C.
(video
interview),
http://www.infoq.com/interviews/larman-scrum-
large-organizations,
April
26,
2011,
On
the
Challenges
of
Scaling
Scrum
to
Large
Organizations
(accessed
24.06.12).
Ogle,
S.,
Kikhtenko,
A.,
Thomas,
P.
(video
– case
study
presentation),
http://www.infoq.com/presentations/The-Kiev-Experiment,
July
13,
2011,
The
Kiev
Experiment:
Evolving
Agile
Partnerships
(accessed
24.06.12).
Patton,
J.
(video
presentation),
http://www.infoq.com/presentations/Design-
Thinking,
May
18,
2011,
Using
Design
Thinking
to
Stop
Building
Worthless
Software
(accessed
24.06.12).
State
of
Agile
Development
Survey,
(PDF)
November
2011,
http://www.versionone.
com/state
of
agile
development
survey/11/
(accessed
24.06.12).
Stankovic,
D.
(blog
article),
September
2011,
http://www.expertaya.com/
2011/09/25/it-companies-in-my-town-nis-serbia-eastern-europe/
(accessed
24.06.12).
Dragan
Stankovic
is
a
Ph.D.
student
at
the
Faculty
of
Electronic
Engineering,
Univer-
sity
of
Nis,
in
the
field
of
Computer
Science.
His
main
research
interest
is
related
to
agile
methodologies,
modern
programming
languages
and
technologies
and
multi-
agent
systems.
He
holds
PMP
certificate
as
a
result
of
software
development
and
team
management
experience
in
IT
industry.
1678 D.
Stankovic
et
al.
/
The
Journal
of
Systems
and
Software
86 (2013) 1663–
1678
Vesna
Nikoli´
c,
Ph.D.
is
a
professor
in
the
Faculty
of
Occupational
Safety
in
Niˇ
s.
She
graduated
in
Philosophy
and
MA,
University
of
Belgrade
(Group
for
Andragogy).
She
is
a
PhD
at
the
Faculty
of
Occupational
Safety
in
Niˇ
s,
University
of
Nis.
Her
work
includes
12
monographs
(author
and
co-author)
and
more
than
160
bibliograph-
ical
items:
articles
in
science
and
professional
journals
as
well
as
in
proceedings
of
scientific
and
professional
conferences
in
the
field
of
adult
education,
knowl-
edge
management,
organizational
behavior
and
learning,
distance
education
and
e-learning,
management
and
human
resources
development.
Research
Interests:
education,
training
and
learning;
management
and
human
resources
development.
She
has
worked
as
member
in
10
research
projects.
Miodrag
Djordjevic
works
as
an
assistant
teacher
on
the
statistical
courses
at
Fac-
ulty
of
Science
and
mathematics,
University
of
Nis.
Currently
he
is
a
PhD
student.
His
research
interest
is
related
to
statistical
modeling
and
recently
to
spatial
point
pattern
analysis.
Dac-Buu
Cao,
Ph.D.
is
currently
Director
of
Product
Development
&
Support
Systems
at
Siemens
PLM
Software,
a
Business
Unit
of
the
Siemens
Industry
Automation
Division.
His
research
interests
include
software
quality
and
soft-
ware
engineering
methodologies.
Before
joining
Siemens,
he
had
been
working
in
software
development
and
IT
management
for
large,
multi-national
corpo-
rations
in
the
aerospace
and
telecommunications
industries.
Dr.
Cao
graduated
in
Computer
Science
from
University
of
California
at
Irvine
and
received
his
Ph.D.
in
IT
Management
from
Capella
University.
He
is
based
in
California,
USA.
