Conference PaperPDF Available

Using Agile Practices to Build Trust in an Agile Team: A Case Study

Authors:

Figures

Content may be subject to copyright.
Using Agile Practices to
Build Trust
in
an
Agile
Team
: A
C
Orla McHugh
, Kieran Conboy, Michael Lang
orla.mchugh@nuigalway.ie
;
kieran.conboy@nuigal
way.ie
;
m
i
chael.lang@nuigalway.ie
Business Information Systems, J.E. Cairnes School of Business & Economics,
Na
tional Un
i
versity of Ireland Galway
Abstract
:
Trust is an important aspect of any software d
evelopment team, but particularly
with self
-
managing teams
as team members are very dependent on one another. Agile teams
are consid
ered to be self
-
managing and t
hey employ
many
different agile practices
to function
as an agile team
. While there have b
een
many studies of
trust in software deve
l
opment teams
few have examined trust in an agile context with even less focus on how specific agile pra
c-
tices may contribute to trust.
The purpose of this study is to examine how
three
agile pra
c
tice
s
-
the daily stan
d
-
up, iteration planning and iteration retrospective
-
may
support and facilitate
trust
in an
agile team
.
A
n exploratory
case study of one agile team
was conducted
.
The
fin
d-
ings
indicate tha
t
while factors
such as environment
al
conditions and personal char
acte
r
istics
of team members
must be considered
,
agile practices can
also
contribute to building trust
among team me
m
bers
. They may also
high
light
a lack of trust
.
1
Introduction
Agile software development
(ASD)
refers to a group of agile m
ethodologies that
focus on developing software in
short time periods (iterations). They
allow requir
e-
ments to evolve and change during iteration
s
, encou
r
age close collaboration between
agile
teams and users, and have teams that are self
-
organising and cros
s
-
functional
(Agile Alliance, 2001)
.
ASD
ha
s
evolved since the mid
-
1990’s
and there are now
many different
agile
met
h
odologies in existence such as eXtreme Programming
(XP), Scrum, Dynamic Systems Development Method (DSDM) and Feature Driven
Development (F
DD).
These methodologies
are often called “lightweight” metho
d-
ologies as
they
differ in their approach to the traditional predictable
plan
-
driven
method of developing software, which requires software teams to follow many pro
c-
ess
es,
and to produce lots o
f documentation
(Boehm, 2002)
.
The A
gile
M
anifesto places great emphasis on the
agile
team and the
role of the
ind
i
vidual
s within the team. Teams should be self
-
organising and self
-
managing,
contain motivated
individuals
, be provided with
the environment
and su
p
port they
need, and
be
trus
ted
to get the job done
(Agile Alliance, 2001)
.
With ASD the team
2
Orla McHugh, Kieran Conboy and Michael Lang
is
provided with substa
n
tially more control than
it
would have had when using a
plan
-
driven approach to software development.
This is a dr
a
matic change for
the
project manager
, who
has
traditionally
been
the primary controller
(Nerur, Mah
a-
patra and Mangalara, 2005)
.
P
roject ma
n
agers
now
need to place great trust in their
team
members
to
make the right decisions and
complete their tasks in a timely ma
n-
ner.
One
way of
ensuring that this
may
occur
is
through the various agile pra
c
tices
that are used by the agile team
1.1 Research Objective and Motivation
Research in the area of ASD has grown in recent years due to the increase in the
number of software project t
eams that use an agile methodology
(Abrahamsson,
Conboy and Wang, 2009; Conboy, 2009; McEvoy and Butler, 2009)
.
Each agile
methodology details various practices that distinguish it from other agile methodol
o-
gies, but they each follow the same underlying ag
ile principles
(Agile Alliance,
2001)
where a practice can be described as a “common way of ac
t
ing”, which is
accepted by a group of individuals as the “correct way to do things”
(Hansson, Di
t-
trich, Gustafsson and Zamak, 2006)
.
Agile teams can choose to ad
opt the agile pra
c-
tices that suit their environment or that work well for them, bearing in mind that
these practices may span several agile methodologies
(Elssamadisy, 2007; Hansson
et al., 2006).
These agile practices may be technical (e.g. test driven de
ve
l
opment,
contin
u
ous integration), relate to planning (e.g. iteration planning, daily stand
-
up), or
could relate to the agile env
i
ronment (e.g. co
-
located team, self
-
organising team).
The objective of this study is to
explore
how trust
amongst
agile
tea
m members
can develop and be nurtured as a result of using agile practices, which in turn may
d
e
velop positive team outcomes such as
foster
ing
better relationships
/cohesiveness
amongst team members
or
improved team performance.
Previous studies hig
h
lighted
the importance of trust in agile teams
(Das and Teng, 2001; Mayer, Davis and
Schoorman, 1995; Nerur et al., 2005)
, but little has been said about how the use of
agile practices can increase or decrease trust among team members,
which is a mot
i-
vation for t
his research.
There have
also
been recent calls for further research that is
more practice
-
focused
(Dybå and Dingsøyr, 2008)
and to investigate how each di
s-
tinct agile practice can help to optimise the performance of an ASD team
(Maruping,
Venkatesh and Ag
arwal, 2009)
. Consequently, t
hree pra
c
tices were selected for the
purposes of this study
(s
ee Table 1)
,
on the basis that
they are
amongst
the
more
commonly used agile practices
by
practitioners
(Version One, 2009)
.
Each of these
practices
is
related to th
e management
and control
of an agile project and
require
s
the
collective
participation of all team members
with a
focus on people,
communic
a-
tion,
intera
c
tion and teamwork
.
The remainder of this paper is s
tructured as follows.
Section 2 provides an ove
r-
vi
ew of the literature on teams, agile teams
and trust
and then
introduce
s the r
e
search
question
. Section 3 provides details on the case organisation. Section 4
d
e
tails
the
methodological approach for this study. Section
5
presents the findings from the case
study and the final section discusses the findings, details the limitations of the r
e-
search and outlines recommendations for further r
e
search.
Using Agile Practices to Build Trust in an Agile Team: A Case Study
3
Table
1.
Agile practices studied
(Beck and Andres, 2005; Elssamadisy, 2008,
Schwaber and Beedle, 2002)
Agile P
ractice
Description
Daily Stand
-
Up
The daily stand
-
up is a short daily status team meeting lasting a maximum
of 10
-
15 minutes typically conducted at the same time each day. The
meeting is conducted with team members standing up. During the meeting
team m
embers explain briefly what they accomplished since the previous
meeting, what will be completed by the next meeting and indicate any
impediments that may pr
e
vent them from completing these tasks.
Iteration Planning
The iteration planning session is a mee
ting that takes place at the start of
each iteration where the team collectively define and plan tasks that must
be completed during the next iter
a
tion.
Iteration Retr
o-
spective
An iteration retrospective is a meeting that is held at the end of each iter
a-
t
ion where the project team reflects on what went well in the iteration,
what did not, and what could be i
m
proved for future iterations.
2
Background
2.1
Teams
Teams are
groups of individuals that work together, are dependent upon one another
and have one
or more tasks to perform
in order to accomplish various goals
(Hac
k-
man, 1990; Mayer et al., 1995)
.
Teams should comprise of individuals who are tec
h-
nically competent, are productive, committed to the team, and have good pro
b
lem
solving and interpersonal s
kills
(
Jurison,
1999)
.
There is also value in ensuring that a
team has a mix of pe
r
sonality types,
both introvert and extrovert,
which can lead to a
more successful team
(Jurison, 1999)
.
There are many conditions that must be met in
order for teams to be e
ffective such as: creating a team that can work well t
o
gether;
ensuring the team are committed to the organisation; providing the team with auto
n-
omy to make decisions; and creating a supportive environment that provides the
team with all the necessary reso
urces and skills in order for them to conduct their
work
(Wageman, 1997; Wageman, Fisher and Hackman, 2009)
.
Teams can be manager
-
led or they can be self
-
governing and self
-
managing
(Hackman, 1990)
.
Self
-
governing teams set their own goals, select new mem
bers,
and
manage and ex
e
cute work of their own design
(Hackman, 1990)
.
Self
-
managing
teams are teams that have responsibility for managin
g their own work and beha
v-
iours
but, others usually make deci
sions
about goals, team structure, and organis
a-
tional sup
ports
(Barker, 1993; Cohen, Chang and Ledford, 1997; Manz and Sims,
1987)
.
Both types of tea
ms
are empowered and
have autonom
y to make decisions
about their
tasks and the processes that they u
se, which are traditionally the
respo
n-
sibility of supervisors an
d managers
(Alper, Tjosvold and Law, 1998; Cummings,
1978)
.
To perform well as
a team all members must
be committed to the team and
must feel that they have the support of other members
(Bishop, Scott and Burroughs,
2000)
as t
he relationship
between
indivi
duals within teams can impact on the dyna
m-
ics of the team
(Gruenfeld, Mannix, Williams and Neale, 1996)
. For e
x
ample, teams
4
Orla McHugh, Kieran Conboy and Michael Lang
of individuals that are more familiar with each other may be more effective at sha
r-
ing information and views than those who are not
(Gruenfeld et al., 1996)
.
2.
2
A
gile
teams are
considered
self
-
managing and self
-
governing
(Cockburn and
Highsmith, 2001)
.
Yet, it cannot be assumed that by pu
t
ting a group of individuals
together in a team and calling them
‘self
-
managing’ mea
ns they
are
automat
i
cally
agile
(Moe, Dingsøyr and Dybå, 2010)
.
While the o
p
timal size of an agile team has
been debated,
ASD t
eams are typically small with
no more than ten
team members
(Schwaber and Beedle, 2002)
. Team members
should
have a range of skil
ls
, be
cross
-
functional
and have the ability to complete the r
e
quired tasks
(Elssamadisy,
2008)
.
A t
e
am
must
be
empowered to make dec
i
sions and
is
responsible for meeting
the goals of each iteration in whatever way it deems a
p
propriate
(Schwaber and
Beedle
, 2002)
.
However, the team must conform to any existing standards within
the organisation such as coding standards, hardware/software platform
s
etc.
(Schw
a-
ber and Beedle, 2002)
.
T
o en
sure
a
team
pro
duces quality work an appropriate and supportive enviro
n-
ment must be available to team members
,
for example,
ensuring availability of r
e-
quired tools,
and
open
-
office space to facilitate open communication.
There is also a
necessity for t
eam members
to
be cooperative,
collaborative,
trusting, have good
relation
ships
with each other, and be able to make decisions quic
kly
(Cockburn and
Highsmith, 2001)
.
I
t has been questioned whether agile methodologies are suitable
for a di
s
tributed team for many reasons including the possibility that distributed team
members are
less likely to feel part of the same team as co
-
located team me
m
bers
(Ramesh, Cao and Mohan, 2006)
. These can be all
e
viated somewhat by
site visits
,
the facilitation of collaboration and knowledge sharing and supplementing informal
co
m
munication with docu
mentation
(Ramesh et al., 2006)
.
2.
3
Trust
T
rust has been studied in many different contexts
,
yet there is little agreement on a
single definition
with the term used in many different ways
(Blomqvist, 1997;
Kramer, 1999; Lewicki, McAllister and Bies, 1998;
McKnight, Cummings and
Chervany, 1998; Rousseau, Sitkin, Burt and Camerer, 1998)
.
One such example is
that presented by Lewicki
(1998)
who
states that “trust is the confident positive e
x-
pectations regarding another’s’ conduct (words, actions and decisions
)”.
A second
definition by McKnight et al.
(1998)
define trust to mean that “one party b
e
lieves in,
and is willing to depend on, another party”, which is of great importance in an env
i-
ronment where individuals must interact and work together to fulfil a co
mmon goal.
Trust, or a lack of trust, can exist
such
between individuals, groups and organ
i
sations
(Das and Teng, 2001)
with
trust
foster
ing
cooperation among
st
parties
(Rousseau et
al., 1998)
and a lack of trust causing suspicion or a lack of confidence i
n other pa
r-
ties
(Kramer, 1999)
.
Using Agile Practices to Build Trust in an Agile Team: A Case Study
5
As organisational teams become more diverse with team members from a variety
of backgrounds and culture, the development of trust between all members is e
x-
tremely important for them to work together effectively
(Mayer et al
., 1995)
.
I
nd
i-
viduals with different personality types, exper
i
ences and cultural backgrounds vary
in
propensity in how likely they are to trust other
s
(Hofstede, 1980)
with
level
s
of
trust
evolving
or diminishing
over time as they
interact with each other
and o
b
serve
each other
(Das and Teng, 2001; Mayer et al., 1995)
.
Distributed teams face
other
challenges such as
lack of control,
lack of cultural understanding,
miscommunic
a-
tion, limited opportunity to communicate orally due to time differences and lack o
f
team morale and trust between team me
m
bers
(Ramesh et al., 2006).
The emergence of self
-
managing agile teams increases the importance of trust
among
team
me
m
bers
as
members
are relatively free to develop the processes they
prefer and to set targets they
consider appropriate
(Das and Teng, 2001; Mayer et al.,
1995).
Team members that collaborate and trust each other are imperative for the
success of an agile project, which may be difficult for deve
l
opers who are used to
working
predominantly
on their own
(Nerur et al., 2005)
.
I
ndividuals or
teams
must
believe that
each
individual
within the
team
has the ability, knowledge, and comp
e-
tence to complete the tasks required and they must also have high personal and moral
integrity
(Mayer et al., 1995)
.
Therefore
, i
t is
important to mai
n
tain and strengthen
trust between team members
.
It may take some time and effort for an organisation to
build a culture of trust amongst team members
(Nerur et al., 2005)
,
but it is possible
that this may
be facilitated and suppor
ted by
the
use of agile prac
tices.
Prior r
esearch
in this
important
area is limited, which
leads
us
to the
fo
l
lowing
research question:
How do agile practices contribute to building trust in an agile software
develo
p-
ment team?
To answer
this
research ques
tion
(
s
ee research model in Fig.
1)
a case study a
p-
proach
is used where a single agile team is studied. This research is part of ong
o
ing
research for a Ph
.D.
and to date data has been collected from one team. At this point
this research is exploratory and
data will be co
l
lected from several other teams in the
near future.
Fig.
1
.
Research model
6
Orla McHugh, Kieran Conboy and Michael Lang
3
The
Case
Organisation
Studied
The organisation selected for this
case
study is a large multi
national
financial se
r-
vices
organisation
with offices located worldwi
de
.
A
decision
was made by
the H
ead
O
ffice in the United States
to
introduce a custom
is
ed version of
an agile methodo
l-
ogy
across the organisation
. The Research & Development (R&D) division
in
Ir
e-
land
was
the first
within the organisation to pilot the use o
f
an
agile methodolog
y
for
developing software
.
T
he project studied is a long
-
term project that
was
in existence
for two years at
the time of the study
and it is envisaged to continue for at least a
n-
other year. The project involves the d
e
velopment of a set
of back
-
end W
eb services
that are used by various front
-
end appl
i
cations for developing financial analysis
documents. The end users are financial analysts across several business units, a
l-
though the direct custo
m
ers are the IT groups in six different busi
ness units who
develop the front
-
end applications. This results in a number of different custo
m
ers,
all whom have
compe
t
ing needs.
The team
composition has changed intermittently since its inception.
When
data
collection
commenced
the team was
composed o
f
ten
individuals
distributed between
the United States,
Ireland
and India.
The development team
was
primarily based in
Ir
e
land with the Quality Assurance (QA)
function
based in India and
a
database
specialist and customers based in the United States. The
customer
was
not directly
i
n
volved in the project on a day
-
to
-
day basis with the analyst acting as the proxy
customer. S
hortly after data collection commenced
,
the two
QA
team me
m
bers
based
in India, who were both testers,
departed from
the team. Recruitme
nt of two r
e-
placement team members is currently taking place
, but these will be
now
based in
Ireland
.
All but one of the team
members inte
r
viewed
is
very experienced
,
with most
of their experience obtained in a non
-
agile environment. A profile of the
t
eam
at the
start of data collection
is d
e
tailed in Table 2.
Table
2.
Team P
rofile
Role
Software develo
p-
ment experience
Experience in
o
r
ganisation
Exper
i
ence in the
agile team
Location
Project Manager [P1]
13 years
8 years
3 years
Ireland
Analyst [A1]
15 yea
rs
2.5 years
2 years
Ireland
Database Specialist
[DB1]
15 years
5 years
11 months
USA
Developer [D1]
10 years
3 years
3 years
Ireland
Developer [D2]
10 years
3 years
6 months
Ireland
Developer [D3]
12.5 years
2.5 years
1.5 years
Ireland
Developer [D4]
2.5 years
2.5 years
2.5 years
Ireland
Developer [D5]
10.5 years
4.5 years
1 year
Ireland
Tester [T1]
Departed team
Departed team
Departed team
India
Tester [T2]
Departed team
Departed team
Departed team
India
Three week iterations are used
by this
agile project team
. The iteration planning
meeting and iteration retrospective meetings are
generally
combined
into one mee
t-
ing (a
p
proximately
one
hour in duration) with distributed team members available on
a conference call
. The first 15 minutes of this
meeting consists of the iteration retr
o-
Using Agile Practices to Build Trust in an Agile Team: A Case Study
7
spective. The project manage
r asks
team member
s
in turn to briefly co
m
ment on
their work in the previous iteration, to indicate what went well and what can be i
m-
proved for future iterations. The remainder of the meeti
ng focuses on iteration pla
n-
ning
where tasks (user stories) for the next iteration are agreed upon, and est
i
mates
are reviewed. Team members are aware of the user st
o
ries that are assigned to them
prior to the meeting and each team member will have prepare
d a time estimate for
each task.
Daily
stand
-
ups are held four days a week as on the fifth day a project team mee
t-
ing
is held instead of the daily stand
-
up meeting. Daily stand
-
up meetings ge
n
erally
last 10
-
15 minutes and take place in an office as this
facilitates a confe
r
ence call with
distributed team members. As with the iteration retrospective
,
the project ma
n
ager,
or senior developer, if the project manager is not present, directs the mee
t
ing. All
team member
s in turn
briefly com
ment on what has bee
n completed since the prev
i-
ous daily stand
-
up, what they are currently working on and whether there are any
‘blockages’ inhibiting the completion of
a
task. In the event that further discu
s
sion is
required in relation to a task(s) this will typically take
place amongst
affected
team
members following the compl
e
tion of the meeting.
4 Research Design
Case studies are particularly appropriate for
exploratory research which is
at an early
stage of maturity
(Benbasat, Goldstein and Mead, 1987)
. Access to the tea
m in que
s-
tion was readily available, and it was felt that the opportunity should be utilized to
conduct a qualitative study and gain an understanding of the agile practices in more
detail. An interview guide was developed from the literature on
teams,
agil
e metho
d-
ologies, and
trust
. It predominantly contained open
-
ended questions as this provided
the researchers with the opportunity to ask additional questions
(Cooper and
Schindler, 2001)
.
Sample interview questions are available in
the A
p
pendix.
Dat
a coll
ection took place over a four
month period. Each interview followed a
similar structure
.
Details on the project and on the number and type of agile pra
c
tices
utilized by the team were gathered from the first inte
r
viewee only. It was felt that it
was only n
ecessary to ask these questions once and it would min
i
mize the amount of
time required to interview the remaining participants.
All interviewees provided
details on their background, and level of experience
,
and this was then fo
l
lowed with
a number of que
s
tions under different headings that were asked to each interviewee.
Semi
-
structured interviews were used to capture the responses of each of the
eight
participants
. This gave the interview a structure, but also allowed thoughts and
personal experiences t
o emerge from participants.
Seven
of the
eight
interviews
co
n
d
u
cted were face
-
to
-
face interviews. The remaining interview was conducted
using a co
n
ference call as this individual was based in the United States.
The two
individuals in India were part of the
team when a number of interviews were co
n-
ducted, so references
are
made to these in the findings even though these team me
m-
bers were not interviewed.
All interviews were conducted at the offices of the o
r-
ganisation. The interviews lasted approximately one
hour each
. All interviews were
recorded and
tra
n
scribed
.
The
transcriptions were
reviewed,
coded and
categorised
8
Orla McHugh, Kieran Conboy and Michael Lang
based on the interview guide
.
The categories were then sub
-
divided into further cat
e-
gories in order to
ide
n
tify patterns and themes and to
va
lidate the data from different
individuals
(Miles and Huberman, 1999)
.
The findings
were
analysed and
validated
by cross
-
checking the findings
with each of the other partic
i
pants.
5
Findings
The findings are
now
presented
detailing how the agile practices
have impacted
positively and negatively
on trust in an agile team
.
5.1 Team Composition
and Trust amongst Team Members
The
team studied is predominantly a well
-
established,
experienced
,
self
-
organising
team with team
members appearing to have a good work
ethic and track record of
delivering on what ha
d
been promised.
Team members are very collegiate and su
p-
portive of each other
and appear to work together as a unit with many items di
s-
cussed collectively.
The team
look
out for each other
and make sure that
when som
e-
thing goes wrong…it is very much a team effort to fix it
[D5]
.
A lot of trust exists between team members.
All team
members believe that their
colleagues are competent and can complete the tasks allocated to them.
Individuals
work on designated
tasks becoming experts in a particular area.
As a result, t
eam
members
trust and accept that their colleagues are honest when determining est
i-
mates and can be believed when they say that a task is co
m
plete.
The project manager does not micro
-
manage and
trusts team members to
work a
good solid day [D1]
. He also trusts the team to acc
u
rately define estimates for tasks
as
they
[developers]
will have more context than me
[P1]
and to then deliver on
those estimates. It is rare for other team me
m
bers or the pr
oject manager to question
a time estimate:
p
lanning estimates aren’t really collective decision they’re just
presented by developers as their individual times and agreed
[D1].
This was co
r-
roborated by the project manager who
doesn’t tend to take a lot of d
ecisions [P1]
.
I
nstead
,
decisions
are made by the team.
5.
2
Building Trust with
Agile Practices
All three agile practices are
an important component of building trust in an agile
team.
In particular, the stand
-
up is a
daily touch
-
point for all team member
s, which
requires
team members (co
-
located and distri
b
uted) to meet and communicate with
each other on a daily basis
and
keep
s
the lines of communication open
[D4]
. Spea
k-
ing to each other on such a regular basis
improves communica
tion,
helps ind
i
viduals
to
better un
de
r
stand each other,
become familiar with their personalities and traits
and be more comfortable in their interactions with each other
leading to i
n
creased
levels of trust
.
At the start of each meeting there is usually some banter b
e
tween the
dif
ferent team locations, which
probably helps you to develop a relatio
n
ship there
that you are not really
aware
of
[D3]
. It also
sets a good tone [D4]
for the meeting.
Using Agile Practices to Build Trust in an Agile Team: A Case Study
9
This interaction helps to build a rapport and trust between team members over time.
The pr
actices
help with understanding people
… as the more that is spoken fr
e
quently
…a bond kind of builds up
[D5]
. They have
also resulted in a
good culture of just
picking up the phone
[D4]
to ask another team member a que
s
tion or speaking to
another team memb
er informally outside of meetings. Team members
do not feel
that they need to wait for the daily stand
-
up to take place in order to discuss a pro
b-
lem
and trust that their co
l
leagues will provide them with the required support
.
All three practices provide
an open forum for knowledge sharing, transparency
and feedback where
the i
n
formation sharing is important. It
s good to know you can
be frank, throw your ideas out there [A1
]
. These practices
help to build trust
amongst team members because
they are having
it [meetings] on a more regular
basis [P1]
and
people get more comfortable
[speaking]
over time [D5]
. Individuals
are encouraged to voice their opinions in all three meetings without fear of repercu
s-
sions and no
-
one has ever
been
reproached for expressing
an opinion
[D4]
.
If a task
takes longer than estimated the individual is not reprimanded, nor looked on neg
a-
tively, but i
n
stead is asked
did we do the estimate wrong, or have you got something
that is blo
c
king you? [A1]
and is helped to complete the task.
The meetings provide
team members with an
opportunity to question and once you
get a valid answer
back…,
well then that does help
[with trust]
[A1]
. If the environment was not as
supportive there may be a ten
dency for individuals to
become more conservativ
e
when [they] plan
[D4]
so as to avoid negative repercussions, which could
be very
detri
mental [D4]
to the pr
o
ject.
In particular, the agile practices have helped to alleviate the possibility of distrust
that can be experienced with distributed team mem
bers from different cu
l
tures. As
the team is distributed across three different cultures it can be difficult for team
members to build good relationships with other distributed team members, especially
when
you haven’t met face
-
to
-
face [D4]
. Participation
by the QA (Indian) team in
the daily stand
-
up and the planning/retrospective meetings helps to build trust with
them as the QA team have a tendency to r
e
frain from being too vocal and are
fairly
timid kind of guys, they don’t really say much other than ‘th
is is what I did’ and ‘this
is what I’m going doing today’ [D2]
. This may be
a cu
l
tural thing or may be the lack
of experience in the team
[D2]
.
This is of particular importance to the project ma
n-
ager who has had some trust concerns with the distributed te
am, but the
stand
-
up is a
great way to keep on top of it [pr
o
gress] [P1]
. The team
know very quickly
[P1]
of
any actual
or potential delays, which can be addressed immediately.
A lot of conve
r-
sation takes place
that wouldn’t happen if these pra
c
tices weren
’t being used [P1]
.
The project manager
believes
that
these
practices
ha
ve
helped with trust as
an
y-
thing that encou
r
ages conversation between people is going to build up a level of
trust
between developers
[P1]
. The
daily stand
-
up in particular
ha
s
made i
t easier for
distributed team members to feel part of the team
because of the continuous comm
u-
nication between the team, it helped me feel part of the team
[DB1]
.
This is partic
u-
larly important
with distributed team members
as difficulties
were
exper
i
enced
on
several occasions
with the QA team in India where
t
hey chop and chang
e
the
m
[team
members] regularly
[
D
2]
resulting in the regular re
-
building of
trust and
relatio
n-
ships.
New team members also integrated faster into the team and quickly built trust
10
Orla McHugh, Kieran Conboy and Michael Lang
lev
els with other team members because they were required to participate in the daily
stand
-
ups, iteration planning and retrospectives from the outset.
5.3
Impediments to Building Trust
Team members do not consider the
customer
part of the team and t
here i
s
a
lack of
trust be
tween the customer and the team.
There are a number of reasons for this. The
customer does not
partake
to any great extent in any of the three agile practices, even
though they are invited
to participate
. Therefore, regular communicatio
n b
e
tween the
team and the customer is limited.
Response times from the customer are very slow…
it can be hard to get their time…
there can be mis
u
n
derstandings…they have their
own agenda
[D2]
and it can
get to the stage where you
[the team]
may have a chat
with the cu
s
tomer and they would ask you to do X, Y and Z… and we get them to
send an email so we have it in writing [D3]
. The
team do not trust that the customer
will review
releases of the software
in a timely manner
and
it
s frustrating to go back
ther
e [to the
customer] if there is nothing happening [A1]
.
R
egular particip
a
tion and
interaction by the customer could benefit the team and increase trust b
e
tween the
parties
. This was demonstrated to some extent when
a site visit
took place
by a team
member
to the United States
as it encouraged a lot more
[face
-
to
-
face]
conversation
[with the cu
s
tomer] [D1]
and was of great benefit to the team
.
While the agile practices have had a positive impact on building trust and rel
a-
tions with distributed team members
they could be improved further
.
Lack of face
-
to
-
face communication and regular site visits have been shown to increase levels of
trust amongst distribute team members
(Ramesh et al., 2006)
.
In this organisation
t
hese could be all
e
viated to some extent thr
ough the use
of
technology such as vi
deo
-
conferencing
, which is available for use within the company
.
6
Discussion and Conclusion
These findings contribute to the literature on trust and agile teams by
attempting to
provid
e some insight into how
daily stan
d
-
up meetings, iteration planning and iter
a-
tion retrospectives
contribute to
building
trust in an agile team.
Overall, the team
stu
d
ied have reported a
predominantly
positive view of the
se three
agile practices.
Regular usage of the agile practices has res
ulted in the development and fostering of
relationships and increased levels of trust between all team members that may not
have existed othe
r
wise.
While
the agile practices
are not the only factors that help to
increase trust in the team, they are acknowl
edged to be a contributing factor.
They
can
also
hig
h
light
where there is a lack of trust between
individuals
due to lack of
participation in the agile pra
c
tices.
I
t is important for an organisation to build a culture of trust among
team me
m
bers
(Nerur et
al., 2005)
. The co
-
located
team
in particular
trust each other
very much,
which may be due to a number of different factors. The team studied was very
e
x-
perienced and
cohesive
.
They are
very
commi
t
ted to the team and are supportive of
Using Agile Practices to Build Trust in an Agile Team: A Case Study
11
each other, all of w
hich helps to build trust
(Bishop et al., 2000)
.
The majority of the
team were co
-
located
sitting in very close proximity of each other, which facil
i
tates
face
-
to
-
face communication and allow
ed
team members to participate in or contri
b-
ute to informal conve
rsations
,
if neces
sary. However, the level of trust
b
e
tween the
team and the
customer
,
who
is typically part of
an agile
team
, was low.
In this pa
r-
ticular project the lack of participation by the customer in the daily stand
-
up, iter
a-
tion planning and itera
tion retr
o
spectives has had an impact on the relationship with
the customer. As a result, the team do not place a great deal of trust in the cu
s
tomer.
This suggests that lack of participation by any key team member in these agile pra
c-
tices can result in th
e d
e
velopment of a lack of trust.
As a consequence of using an agile met
h
odology the team
had autonomy to make
their own decisions, set their own deadlines for an iter
a
tion and could control what
they do within the team
which were defined during the iter
a
tion planning meeting
.
The project manage
r listened
to the team,
did
not appear to micromanage and gene
r-
ally support
ed
the decisions made by the team. The enviro
n
ment itself
was
very
supportive and using
these
agile practices
has
provided an o
p
portunity fo
r trust to
foster and develop among team me
m
bers.
This suggests that it is important for the
project manager to allow the team to self
-
manage, to make their own decisions, and
to support them in whatever way possible to help the team to build relationships
with
each other
, resulting in a potential increase in trust, stronger team
spirit,
and i
m-
proved
pe
r
formance of the team.
Distributed software development teams face particular challenges, particularly
in relation to trust, culture, and communication when
the time zones vary dramat
i-
cally
(Ramesh et al., 2006)
and it is important to find ways to address these pro
b-
lems. One possible way is to use agile practices which provide distributed team
members with a facility to communicate and interact with the team
on a regular basis
and help them to feel part of the team. Daily meetings encourage a certain amount of
informal communication, such as social conversations as the start of a meeting,
which can contribute to breaking down any cultural barriers that may exi
st and buil
d-
ing a relationship with the team members. This may lead to an i
n
crease in the levels
of trust between team members as c
urrent concerns can be raised and discussed
,
ideas and problems can be shared and advice provided in a constructive way. Fee
d-
back is obtained regularly and team members can form their own opinion as to
whether other team members are competent and can be trusted to co
m
plete good
quality work on time. These meetings in addition to the iteration planning and iter
a-
tion retrospective
meetings also provide transparency on tasks and whether or not
tasks are being co
m
pleted on time.
People are extremely important in an agile team and it is imperative that they can
work together, have good relationships, and trust each other to deliver
on what is
promised
(Nerur et al., 2005)
. As the demand for
agile
software development conti
n-
ues it is important that trust is a core element of a team. Many different agile pra
c-
tices may contribute to trust amongst team me
m
bers, but
the
findings
of this s
tudy
are a first step towards understanding how three diffe
r
ent agile practices can support
and facilitate trust in an agile team.
Some of the fin
d
ings presented here may be of
benefit to practitioners when trying to identify the characteristic of individu
als or
teams who may be suitable for ASD, or where practitioners are attempting to dete
r-
12
Orla McHugh, Kieran Conboy and Michael Lang
mine the benefit of implementing these agile practices.
At the same time it is impo
r-
tant to remember that another agile team in a different enviro
n
ment may not use
thes
e agile practices in the same way and as a result may not have the same
positive
e
x
perience.
This research is limited by virtue of the fact that a single case study is uti
l
ized as
the research method. The findings are ther
e
fore, only representative of thi
s team.
While the team was initially distributed across three continents, team members in
one of the locations departed from the team during data collection and were not
replaced locally. The perspectives of these team members may have provided diffe
r-
ent i
nsights into the agile practices used as they were distributed team members of a
different culture.
A second limitation relates to the number of practices studied. This
research only focused on
three practices. F
u
ture research should examine other agile
pr
actices to d
e
termine if they
also
impact on trust amongst
agile
team members.
Appendix
This appendix details a sample of the interview questions asked to participants as
part of this study in relation to trust.
1. Do these agile practices encourage/enabl
e trust among your team me
m
bers?
2. How do they do this/inhibit/prevent this?
3. Can you provide an example to demonstrate this?
4. Do these agile practices encourage/enable trust with team members that are di
s-
tributed?
5. How do they do this/inhibit/preve
nt this?
6. Do these agile practices encourage/discourage individuals to talk freely
to other
team members about difficulties
that they may have in relation to
the project
?
References
Abrahamsson, P., Conboy, K. and Wang, X. (2009) Lots
done, more to do: The current state
of agile systems development research, European Journal of Information Systems,
Vol.
18
(4), pp. 281
-
284.
AgileAlliance (2001) "Manifesto for Agile Software Development" [Online] Available at:
(
www.agilemanifesto.org)
,
Alper, S., Tjosvold, D. and Law, K. S. (1998) Interdependence and Controversyin Group
Decision Making: Antecedents to Effective Self
-
Managing Teams, Organizational
Behavior and Human Decision Processes, Vol.
74
(1), pp. 33
-
52.
Barker, J. R. (1993) Tightening the Iron Cage: Concertive Control in Self
-
Managing Teams,
Administrative Science Quarterly, Vol.
38
(3), pp. 408
-
437.
Beck, K. and Andres, C. (2005)
Extreme Programming Explained: Embrace Change,
2nd edn,
A
ddison
-
Wesley, Boston, MA.
Benbasat, I., Goldstein, D. K. and Mead, M. (1987) The Case Research Strategy in Studies of
Information Systems, MIS Quarterly, Vol.
11
(3), pp. 368
-
386.
Using Agile Practices to Build Trust in an Agile Team: A Case Study
13
Bishop, J. W., Scott, K. D. and Burroughs, S. M. (2000) Support, commitment,
and employee
outcomes in a team environment, Journal of Management, Vol.
26
(6), pp. 1113
-
1132.
Blomqvist, K. (1997) The many faces of trust, Scandinavian Journal of Management, Vol.
13
(3), pp. 271
-
286.
Boehm, B. (2002) Get Ready for Agile Methods, With Ca
re, IEEE Computer, Vol.
35
(1), pp.
64
-
69.
Cockburn, A. and Highsmith, J. (2001) Agile Software Development: The People Factor,
IEEE Computer, Vol.
34
(11), pp. 131
-
133.
Cohen, S. G., Chang, L. E. I. and Ledford, G. E. J. (1997)A Hierarchical Construct of S
elf
-
Management Leadership and its Relationship to Quality of Work Life and Perceived
Work Group Effectiveness, Personnel Psychology, Vol.
50
(2), pp. 275
-
308.
Conboy, K. (2009) Agility from first principles: Reconstructing the concept of agility in i
n-
format
ion systems development, Information Systems Research, Vol.
20
(3), pp.
329
-
354.
Cooper, D. R. and Schindler, P. S. (2001)
Business Research Methods,
8th edn,
McGraw Hill,
London, England.
Cummings, T. G. (1978) Self
-
Regulating Work Groups: A Socio
-
Technica
l Synthesis, The
Academy of Management Review, Vol.
3
(3), pp. 625
-
634.
Das, T. K. and Teng, B.
-
S. (2001) Trust, Control, and Risk in Strategic Alliances: An Int
e-
grated Framework, Organization Studies, Vol.
22
(2), pp. 251
-
283.
Dybå, T. and Dingsøyr, T. (200
8) Empirical Studies of Agile Software Development: A Sy
s-
tematic Review, Information and Software Technology, Vol.
50
(9
-
10), pp. 833
-
859.
Elssamadisy, A. (2007)
Patterns of Agile Practice Adoption: The Technical Cluster
,
C4Media,
USA.
Elssamadisy, A. (2008
)
Agile Adoption Patterns: A Roadmap to Organizational Success
,
Addisson Wesley, USA.
Gruenfeld, D. H., Mannix, E. A., Williams, K. Y. and Neale, M. A.(1996) Group Compos
i-
tion and Decision Making: How Member Familiarityand Information Distribution
Affect
Process and Performance, Organizational Behavior and Human Decision
Processes, Vol.
67
(1), pp. 1
-
15.
Hackman, J. R. (1990)
Groups that Work (and those that don't). Creating Conditions for
Effective Teamwork
,
Jossey
-
Bass Inc. San Francisco, CA.
Hansson, C.
, Dittrich, Y., Gustafsson, B. and Zarnak, S. (2006) How Agileare Industrial
Software Development Practices?, Journal of Systems and Software, Vol.
79
(9), pp.
1295
-
1311.
Hofstede, G. (1980) Motivation, Leadership, and Organization: Do American Theories Ap
ply
Abroad?, Organizational Dynamics, Vol.
Summer
, p42
-
63.
Jurison, J. (1999) Software Project Management: The Manager's View, Communications of
the AIS, Vol.
2
(17), pp. 1
-
50.
Kramer, R. M. (1999) Trust and distrust in organizations: Emerging perspectives,
enduring
questions, Annual Journal of Psychology, Vol.
50
(1), pp. 569
-
598.
Lewicki, R. J., McAllister, D., J. and Bies, R. J. (1998) Trust and Distrust: New Relationships
and Realities, Academy of Management Review, Vol.
23
(3), pp. 438
-
458.
Manz, C. C. an
d Sims, H. P., Jr. (1987) Leading Workers to Lead Themselves: The External
Leadership of Self
-
Managing Work Teams, Administrative Science Quarterly, Vol.
32
(1), pp. 106
-
129.
Maruping, L. M., Venkatesh, V. and Agarwal, R. (2009) A Control Theory Perspectiv
e on
Agile Methodology Use and Changing User Requirements, Information Systems
Research, Vol. isre.1090.0238.
14
Orla McHugh, Kieran Conboy and Michael Lang
Mayer, R. C., Davis, J. H. and Schoorman, F. D. (1995) An Integrative Model ofOrganiz
a-
tional Trust, Academy of Management Review, Vol.
20
(3), pp.
709
-
734.
McEvoy, J. and Butler, T. (2009) The role of project management in ineffective decision
making within Agile software development projects, European Journal ofInform
a-
tion Systems, Vol.
18
(4), pp. 372
-
383.
McKnight, D. H., Cummings, T. G. and Cher
vany, N. L. (1998) Initial Trust Formation in
New Organizational Relationships, Academy of Management Review, Vol.
23
(3),
pp. 473
-
490.
Miles, M. and Huberman, A. (1999)
Qualitative Data Analysis
,
Sage, London.
Moe, N. B., Dingsøyr, T. and Dybå, T. (2010) A
teamwork model for understanding an agile
team: A case study of a Scrum project, Information and Software Technology, Vol.
52
(5), pp. 480
-
491.
Nerur, S., Mahapatra, R. and Mangalara, G. (2005) Challenges of Migrating to Agile Metho
d-
ologies, Communications
of the ACM, Vol.
48
(5), pp. 72
-
78.
Ramesh, B., Cao, L. and Mohan, K. (2006) Can Distributed Software Development be agile?,
Communications of the ACM, Vol.
49
(10), pp. 41
-
46.
Rousseau, D. M., Sitkin, S. B., Burt, R. S. and Camerer, C. (1998) Not sodiffer
ent after all: A
Cross
-
Discipline View of Trust, Academy of Management Review, Vol.
23
(3), pp.
393
-
404.
Schwaber, K. and Beedle, M. (2002)
Agile Software Development with Scrum
,
Prentice Hall,
NJ, USA.
VersionOne (2009) State of Agile Development Survey 20
09 (Accessed: 31 March 2010)
[Online]. Available at
http://pm.versionone.com/StateofAgileSurvey.html
Wageman, R. (1997) Critical Success Factors for Creating Superb Self
-
Managing Teams,
Orga
nizational Dynamics, Vol.
26
(1), pp. 49
-
61.
Wageman, R., Fisher, C., M. and Hackman, J. R. (2009) Leading Teams when the Time is
Right: Finding the Best Moments to Act, Organizational Dynamics, Vol.
38
(3), pp.
192
-
203.
... Our findings provided that agile female managers can increase team effectiveness with trust. Managers can improve their firm's performance by creating positive trust among employees because it is critical for a manager to enable the team to self-manage, make their own decisions and assist them in any way possible in order to help the team create connections with one another, potentially leading to an increase in trust, better team spirit and higher team performance [88]. People are crucial in an agile team, and they must be able to collaborate, form positive connections and trust one another [86,89,90]. ...
Article
Full-text available
The need for organizations to adapt to constant change means the challenges of implementing an agile strategy. Therefore, the purpose of the study is to analyze the role of agile women leadership and team effectiveness by looking into the mediating effect of interpersonal trust based on a cross-sectional quantitative study with a sample of 269 employees from Poland and Turkey. Questionnaires were distributed to individuals in companies having women leaders or managers. The three questionnaires required the respondents to answer questions regarding the perception of agile leadership, trust and team effectiveness. By using SPSS, demographics, descriptive statistics and tests of normality were determined. Smart PLS version 3.0 was used for confirmatory factor analysis, internal accuracy and validity estimates, hypothesis checking and mediation testing. Results of PLS-SEM indicated interpersonal trust has a full mediation role between agile women leadership in shaping team effectiveness. The population of this study are working for organizations of just two countries; hence, the generalizability of the findings to other settings is unknown. Our findings contribute to the literature on women agile leadership and team effectiveness by demonstrating how the growth in trust to managers contributes to the emergence of team effectiveness and the agile leadership trend over time. This study will therefore contribute to the understanding of organized teams’ effectiveness in the perspective of agile women leadership and trust of supervisors
... Team members who work together and trust each other are essential to the success of an agile organization. [31]. ...
Article
Full-text available
The current changes in the business environment, which are accompa-nied by strong technological developments, have led to the acceleration of change and the constant need to adapt to the market. At present, companies have to cope with a number of changes, both in terms of the implementation of new technolo-gies, changes in the content and scope of work of employees and in the overall approach to management. An agile approach to leadership and the creation of self-managed teams is a trend that has gained in popularity in recent years. Many researches already point to the fact that agile teams increase the flexibility of the organization and contribute to higher employee satisfaction with work. However, the transition from the classic rigid approach to employee management to agile is challenging and many organizations approach it only cautiously. The main goal of the study was to analyze the level of implementation of self-organized teams and the level of employee participation in planning their work tasks in Slovak companies and to examine the differences based on the size of the organization. When collecting data, we focused on 50 companies while obtaining information from the HR department on employee management. We found out that up to 74% of Slovak companies do not plan to implement agile principles within their teams. An interesting fact is that more SMEs than large companies are interested in this trend. Survey has also shown that only 8% organizations enable employees to plan tasks independently. Especially in large companies, scheduling tasks with a supervisor is very important. Slovakia, as an industrial country, is significantly affected by technological changes, but the adaptation of technologies without ap-propriate changes in management may not lead to the expected results in the con-text of future competitiveness.
... Team members who work together and trust each other are essential to the success of an agile organization. [31]. ...
Chapter
Full-text available
The current changes in the business environment, which are accompanied by strong technological developments, have led to the acceleration of change and the constant need to adapt to the market. At present, companies have to cope with a number of changes, both in terms of the implementation of new technologies , changes in the content and scope of work of employees and in the overall approach to management. An agile approach to leadership and the creation of self-managed teams is a trend that has gained in popularity in recent years. Many researches already point to the fact that agile teams increase the flexibility of the organization and contribute to higher employee satisfaction with work. However, the transition from the classic rigid approach to employee management to agile is challenging and many organizations approach it only cautiously. The main goal of the study was to analyze the level of implementation of self-organized teams and the level of employee participation in planning their work tasks in Slovak companies and to examine the differences based on the size of the organization. When collecting data, we focused on 50 companies while obtaining information from the HR department on employee management. We found out that up to 74% of Slovak companies do not plan to implement agile principles within their teams. An interesting fact is that more SMEs than large companies are interested in this trend. Survey has also shown that only 8% organizations enable employees to plan tasks independently. Especially in large companies, scheduling tasks with a supervisor is very important. Slovakia, as an industrial country, is significantly affected by technological changes, but the adaptation of technologies without appropriate changes in management may not lead to the expected results in the context of future competitiveness.
... The team members received fast responses to their questions on Slack. Frequent communication builds trust and awareness of tasks and how they affect each other [51]. Further, project participants kept each other informed on what they were doing, which increased the transparency between sites. ...
Preprint
Full-text available
Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 hours 45 minutes per week on average in scheduled meetings and 8 hours 54 minutes in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.
... The team members received fast responses to their questions on Slack. Frequent communication builds trust and awareness of tasks and how they affect each other (McHugh et al., 2010). Further, project participants kept each other informed on what they were doing, which increased the transparency between sites. ...
Article
Full-text available
Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 h 45 min per week on average in scheduled meetings and 8 h 54 min in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.
... These daily and weekly routines rely on multiple technical and social" practices (Thummadi, Shiv, Berente, & Lyytinen, 2011;). A number of scholars have characterized different ASD practices into technical and social groups (Asnawi, Gravell, & Wills, 2011;Chow & Cao, 2008;McHugh, Conboy, & Lang, 2011;Mnkandla & Dwolatzky, 2007;Robinson & Sharp, 2005b;Treude & Storey, 2009). Drawing on this body of literature, Hummel, Rosenkranz, and Holten, (2015) conducted a qualitative study and proposed a new construct called "social agile practices." ...
Article
IT department culture has been widely recognized as an important factor that influences the adoption of agile practices. Yet, the research pertaining to the relationship between IT department culture and agile practices usage remains underexplored. This study proposes and tests the relationships between four competing cultural forms and two types of agile practices - social and technical. The findings contribute to the extant literature by integrating the competing values model of culture into the literature on factors affecting agile development at the IT department level.
Article
Context Organizations are adopting agile practices in distributed software development in order to develop quality software in less time. Using agile software development in distributed set up has its own set of challenges pertaining to face to face interactions, collaboration, time zone and cultural differences. A strong presence of trust helps to overcome these challenges. A relatively lesser number of empirical studies on multidimensional perspective of trust in distributed agile software development has motivated this study. Objective This study aims to develop a comprehensive framework to build trust in distributed agile teams. Method This study is based on Grounded Theory research methodology which involves 40 agile practitioners from diverse domains belonging to 19 different software organizations located across seven different countries. Besides, observations in two different software organizations were also performed to gather data. Data has been gathered in the form of semi-structured interviews and field notes. Result Qualitative data analysis resulted into five different contributing categories for building trust amongst distributed agile teams. These categories represent multidimensional perspectives that influence trust building amongst agile team members working across different parts of the world. Conclusion This study culminates into a framework for building trust in distributed agile teams. The proposed framework has been developed empirically and has five components that influence trust building. These components are related to working environment, leadership, organizational, personal and socio cultural perspectives. The multidimensional perspective of trust was investigated from an agile practitioners view through their real-life project experiences. Organizations and software practitioners may utilize the results of this study to create a hospitable environment for building trust while practicing agile in a distributed environment.
Article
Background Metrics teams play an increasingly important role in handling data and information in modern software development organizations; they manage their companies’ measurement programs, collect and process data, and develop and distribute information products. Metrics teams can comprise several roles, and their set-up can differ between companies, as can the metrics maturity of host organizations. These differences impact the effectiveness and quality of a team’s measurement program. Objective Our objective was to design and evaluate a model to describe the characteristics of a mature metrics team, which efficiently designs, develops, maintains, and evolves its organization’s measurement program. Method We conducted an action research study on four metrics teams of four distinct companies. We designed and evaluated a domain-specific model for assessing the maturity of metrics teams – MeTeaM – and also assessed the four metrics teams per se. Results Our results were two-fold: the creation of the metrics team maturity model MeTeaM and a template to assess metrics teams. Our evaluation showed that the model captures the characteristics of successful metrics teams and quantifies the maturity status of both the metrics teams and their host organizations. Conclusions More mature metrics teams score higher in the MeTeaM model than less mature teams. The assessment provides less mature metrics teams with valuable insights on what factors to improve. Such insights can be shared with and acted upon successfully with their organizations.
Conference Paper
Full-text available
Virtual teams rely on enterprise social networking tools such as Slack to collaborate efficiently. While such tools contribute to making the communication more synchronous and support distributed agile development, there are several challenges such as how to interact with each other and how to balance the communication with other types of communication mechanisms such as meetings, e-mail, and phone. In this paper, we describe and discuss how a distributed global project used Slack. Some of the challenges we identified were related to language problems, using too much direct messaging when communicating, and unbalanced activity (33% of the users accounted for 86% of the messages). The positive aspects of using the tool were increased transparency, team awareness, and informal communication. Further, Slack facilitates problem-focused communication which is essential for agile teams. Our study stresses the importance of reflecting on how virtual teams use communication tools, and we suggest that teams decide on guidelines on how to use the tools to improve their coordination.
Chapter
This research contributes to the body of knowledge in information systems development (ISD) with an empirical investigation in the form of a case study that demonstrates the positive impact of the agile development and project management method Scrum on team leadership in information systems and software development projects. It also provides a useful operationalization of the concept through six identified indicators for team leadership. Despite the fact that the case unit had challenges with the use of Scrum, the indicators identified the areas where the company had managed to exploit the potential of Scrum and its practices with regard to increasing team leadership. The research results are discussed with regard to the existing Scrum literature and briefly related to complex adaptive systems (CAS) as a foundation for ISD and agile development.
Article
Full-text available
This field study investigated whether perceived team support and team commitment relate to employee outcomes differently than perceived organizational support and organizational commitment. A LISREL analysis was conducted on data from 380 manufacturing plant employees and 9 supervisors. Job performance was related to team commitment; intention to quit was related to organizational commitment ; and organizational citizenship behavior was related to both team and organizational commitment. Commitment mediated the relationships between support and the outcome variables.
Article
Full-text available
Arguably, the most critical time frame for organizational participants to develop trust is at the beginning of their relationship. Using primarily a cognitive approach, we address factors and processes that enable two organizational parties to form relatively high trust initially. We propose a model of specific relationships among several trust-related constructs and two cognitive processes. The model helps explain the paradoxical finding of high initial trust levels in new organizational relationships.
Article
Full-text available
We propose a new theoretical framework for understanding simultaneous trust and distrust within relationships. grounded in assumptions of multidimensionality and the inherent tensions of relationships. and we separate this research from prior work grounded in assumptions of unidimensionality and balance. Drawing foundational support for this new framework from recent research on simultaneous positive and negative sentiments and ambivalence. we explore the theoretical and practical sig- nificance of the framework for future work on trust and distrust relationships within organizations.
Article
Full-text available
This paper explores the paradoxical role of the external leaders of self-managing work teams. Observation, interviews, group elicitations, and a literature search were used to identify salient leader behaviors in a medium-sized manufacturing plant that had been operating for several years under a system of self-managing work teams. A self-management leadership questionnaire was developed to measure the 21 leader behaviors identified. Correlations with overall leadership-effectiveness ratings generally indicated that the external leaders' most important behaviors are those that facilitate the team's self-management through self-observation, self-evaluation, and self-reinforcement. The study suggests that there is a legitimate role for external leaders of self-managing work teams but that it differs from traditional and participative leadership roles.
Article
The abstract for this document is available on CSA Illumina.To view the Abstract, click the Abstract button above the document title.
Article
Self-regulating work groups are a promising alternative to traditional forms of work design. Their emergence from socio-technical systems theory and field experimentation is discussed, and their theoretical bases and implementation strategies presented. Managerial functions appropriate to their design and supervision are also proposed.
Article
Examined the critical success factors for a superb self-managing team. 43 self-managing teams at Xerox were assessed. Each team participated in a 2-hr interview; their managers provided descriptions of how they were set up; and each team member completed an extensive survey about the team. Teams were identified as superb or ineffective. Results indicate that the quality of a team's design had a larger effect on its level of self-management than coaching: the superb teams showed stronger signs of self-managing than poorly designed teams. Seven features emerged as the ones most likely to be seen in superb teams and not in ineffective teams: clear, engaging direction; a real team task; rewards for team excellence; basic material resources; authority to manage the work; team goals; and team norms that promote strategic thinking. (PsycINFO Database Record (c) 2010 APA, all rights reserved)
Article
In this paper, I provide an ethnographic account of how an organization's control system evolved in response to a managerial change from hierarchical, bureaucratic control to concertive control in the form of self-managing teams. The study investigates how the organization's members developed a system of value-based normative rules that controlled their actions more powerfully and completely than the former system. I describe the organization and its members and provide a detailed account of the dynamics that emerged as concertive control became manifest through the members' interactions. This account depicts how concertive control evolved from the value consensus of the company's team workers to a system of normative rules that became increasingly rationalized. Contrary to some proponents of such systems, concertive control did not free these workers from Weber's iron cage of rational control. Instead, the concertive system, as it became manifest in this case, appeared to draw the iron cage tighter and to constrain the organization's members more powerfully.