Int. J.

Human-Computer Studies 111 (2018) 1–11

Contents lists available at ScienceDirect

International Journal of Human-Computer Studies

journal homepage: www.elsevier.com/locate/ijhcs

Engendering cohesive software development teams: Should we focus on

interdependence or autonomy?
Adarsh Kumar Satindarlal Kakar
Alabama State University, 915 S Jackson St, Montgomery, AL 36104 United States

a r t i c l e i n f o a b s t r a c t

Keywords: Empirical evidence suggests that both autonomy and interdependence are important considerations in team de-
Team cohesiveness sign. But how do interdependence and autonomy affect team cohesiveness, an important antecedent of team
Autonomy performance? The results of this multi-year study with software development projects show that task interdepen-
Task interdependence
dence and task autonomy have both synergistic and antagonistic impacts on team cohesiveness. At high levels
Outcome interdependence
of outcome (goal) interdependence, task autonomy and task interdependence have a synergistic impact on team
cohesion, while at low levels of outcome interdependence, task autonomy and task interdependence have an
antagonistic impact on team cohesion. Further, taylorist teams showed lower cohesiveness compared to agile
teams.
© 2017 Elsevier Ltd. All rights reserved.

1. Introduction such as software development, this can lead to frequent adjustment of

Cohesion reflects the degree of attraction among group members
(Shaw, 1981). A study of cohesiveness is considered essential for un-
derstanding group dynamics in teams (Zander, 1979). Cohesiveness is
critical for social integration and sustenance of groups (O’Reilly et al.,
1989). Studies have shown that cohesive groups coordinate better and
display more altruistic behaviors (Berkowitz, 1954; Hogg, 1992; Shaw,
1981). Team members of cohesive groups willingly assist others, partic-
ipate in group activities and consider group goals as their own (Henry,
Arrow, and Carini, 1999; Moreland & Levine, 1984).
However, engendering cohesive teams can be tricky. Cognitive Eval-
uation Theory (CET) (Deci and Ryan, 1985) suggests that both auton-
omy and relatedness are fundamental human needs that should be met
to enhance intrinsic motivation of team members. Teams are therefore
designed to provide high levels of task interdependence as well as auton-
omy to its team members (Cannon-Bowers, Oser, and Flanagan, 1992;
Sundstrom et al., 1990). However, this creates a dilemma as high inter-
dependence may constrain autonomy and high autonomy may under-
mine interdependence (Janz, Collquitt, and Noe, 1997). Further, while
high interdependence is likely to enhance group cohesion, high auton-
omy might hamper it.
Autonomy is defining as little as possible how tasks should be per-
formed, practicing the principle of self-management (Herbst, 1974; Mor-
gan, 1986), and allowing as much independence in terms of work pace
and work methods as possible for performing tasks (Hackman and Old-
ham, 1976). However, for group tasks requiring high interdependence,
tasks, compromises, and conflicts (Niepce and Molleman, 1998). Keep-
ing this context in view, this study investigates the interplay between
task interdependence and autonomy in engendering team cohesiveness.
The aim is to get answers to the following questions: What is the trade-
off in deciding between task interdependence and autonomy for enhanc-
ing team cohesion? When should one focus on autonomy versus inter-
dependence?
These questions are relevant to all teams but particularly those en-
gaged in knowledge work such as software development. Depending
on the philosophy they subscribe to, the work in software develop-
ment is designed to provide different levels of task autonomy and in-
terdependence providing the variation necessary to comprehensively
investigate the research questions. Plan-driven software development
approaches prefer a hierarchical control and command team structure.
Managers not only assign tasks to the team members but also specify
how (process) they should be performed and by when (schedule) they
should be completed (Melnik and Maurer, 2006). By contrast, agile
software development approaches deploy autonomous self-organizing
teams (Moe, Dingsøyr, and Dybå, 2009). Agile teams set and accom-
plish their own goals through participation among team members, have
autonomy in the way they perform tasks, and repeatedly reorganize
by allocating work among themselves based on changing circumstances
(Nerur, Mahapatra, and Mangalraj, 2005).
It would therefore be interesting to examine autonomy and inter-
dependence in plan-driven versus agile software development teams
and how they affect team cohesion. To accomplish the aforementioned

E-mail address: akakar@alasu.edu

https://doi.org/10.1016/j.ijhcs.2017.11.001
Received 13 July 2016; Received in revised form 17 October 2017; Accepted 7 November 2017
Available online 11 November 2017
1071-5819/© 2017 Elsevier Ltd. All rights reserved.
A.K.S. Kakar
goals, this study first identifies the relevant constructs by gleaning con-
cepts from a multi-disciplinary review of literature and then develops
a theoretical model of relationship between the constructs. The model
is then tested with team members of industrial software development
projects. The findings are analyzed and their implications for the prac-
tice of software development in particular and work groups in general
are discussed.
2. Literature review
2.1. Autonomy and interdependence in the era of scientific management
Work design research began with the economic perspectives on the
division of labor and task specialization (Babbage 1835; Smith 1776).
Adam Smith (1776) suggested division of labor by breaking down com-
plex jobs into simpler jobs as a way of enhancing performance. Expand-
ing on these ideas Babbage (1835) pointed out the added advantages of
job simplification such as requirement of less skilled and hence cheaper
labor. Specialization and division of labor creates interdependencies
within work groups or departments (Saavedra, Earley, and Van Dyne,
1993; Thompson, 1967; van de Ven, Delbecq, and Koenig, 1976).
The concepts of Charles Babbage and Adam Smith influenced the
methods of software development during the early stages of its evolu-
tion. Methods such as the waterfall method (Royce, 1970) and its vari-
ants encouraged division of labor leading to specialized roles of busi-
ness analysts, system architects, programmers, and testers (Melnik and
Maurer, 2006). These plan-driven methods were also influenced by the
concepts of Taylor (1911, 1947) who introduced Scientific Management
with the aim of controlling every work activity, from the simplest to
the most complicated. He applied to workers the ideas Whitney (see
Mirsky and Nevins, 1952) earlier used for making interchangeable parts.
Taylor analyzed tasks into their minutest details and arrived at a
standardized process; the one best way to do the job (Kanigel, 1997),
just as Eli Whitney analyzed a musket into its smallest parts and made a
machine to manufacture each part (Mirsky and Nevins, 1952). Together
the ideas of Whitney, Taylor and Ford (of moving assembly line) ush-
ered in the era of mass production. As applied to software development,
these concepts led to the development of factory like concepts. Bemer
of General Electric (Bemer, 1969) was among its earliest proponents.
He suggested that General Electric adopt standardized tools to reduce
variability in programmer productivity and keep a database of histori-
cal records for management control. Mellroy of AT&T (Mellroy, 1968)
emphasized systematic reusability of code for enhancing productivity.
By the late 1960s, the term ‘software factory’ was in popular use
and became associated with computer-aided tools, management-control
systems, modularization, and reusability (Cusumano, 1989). Taylorist
approaches such as the waterfall model (Royce, 1970) and its vari-
ants promoted upfront requirements gathering, systems design, and lin-
ear sequential development phases. These concepts were implemented
through detailed planning, defined processes, coding standards, inspec-
tions and reviews, productivity metrics, and statistical quality control.
Efficiency of software development processes were measured through
the use of control charts. Process models such as Capability Maturity
Model (CMM) gained popularity for defining and improving software
development processes (Huh, 2001). Overall, these developments had
an adverse impact on autonomy of team members.
2.2. Autonomy and interdependence and the human relations movement
In the domain of manufacturing, while mass production resulted in
an improvement in the standard of living of society, it had deleterious
psychological consequences for the workers. Repetitive jobs were found
to be boring, tiring, dissatisfying and potentially damaging to mental
health (Fraser, 1947; Walker and Guest, 1952). These costs of division of
labor and task specialization diverted the focus of researchers to human
issues at work. Studies were conducted to investigate whether employee
2
Int. J. Human-Computer Studies 111 (2018) 1–11
satisfaction and motivation could be enhanced by improving working
conditions (Mayo, 1933, 1945; Roethlisberger & Dickson, 1939). Some
researchers proposed that enriched job characteristics such as enlarged
rather than narrow tasks improve employee motivation and satisfaction
(Herzberg, 1966; Herzberg, Mausner, and Snyderman, 1967; Turner and
Lawrence, 1965). Hackman and Oldham (1976) suggested that when
employees have freedom to schedule their work and decide on proce-
dures it increases the motivating potential of work.
This transition in focus from process to people, and from division of
labor and rigid task interdependencies to task autonomy and integra-
tion, was also seen in the evolution of software development methods
with the introduction of the Agile manifesto in 2001. Agile development
proponents questioned the assumption that change and uncertainty can
be controlled through a high degree of advanced planning and rigid pro-
cesses (Nerur, Mahapatra, and Mangalraj, 2005). Software developers
realized that while the Tayloristic plan-driven methods do work well
in stable conditions, under uncertain conditions, managers planning,
assigning and controlling tasks of software developers may not work.
Group members should be able to deal with disruptive events as and
when they arise. Agile methods therefore emphasize team and employee
autonomy in organizing and performing work.
However, despite these trends of increased employee autonomy and
integration of tasks into meaningful work, the importance of interde-
pendence did not decline. With tasks becoming more socially embed-
ded than at any other time in the past, work design researchers recog-
nize that work is inextricably intertwined with interactions among team
members and interpersonal relationships (Grant and Parker, 2009).
Therefore work in agile teams is not defined by industrial engineers
and assigned by supervisors but by self-organizing teams through mu-
tual adjustment amongst team members. Therefore, in today’s context
of uncertain business environments and rapidly evolving customer re-
quirements, it is reasonable to assume that both employee autonomy
and interdependence are important considerations in successful team
design.
2.3. Impact of autonomy and interdependence on team cohesion
But how do employee autonomy and interdependence impact team
cohesion? Cohesiveness is the degree to which team members like each
other, identify themselves positively with the team and want to re-
main its members (Hackman and Morris, 1975; Shaw, 1981). Two meta-
analyses (Evans and Dion, 1991; Mullen and Cooper, 1994) have re-
ported a positive relationship between cohesiveness and performance.
However, team cohesion is not a panacea for all ills. Cohesive teams
may be more susceptible to group think and may not generate the most
creative solution to problems due to increased conformity and con-
servatism in problem-solving approaches (Janis, 1972, 1982; McAvoy
and Butler, 2009). High team cohesiveness can also lead to ineffectual
decision making such as groupthink and the Alibene paradox (Janis,
1972, 1982; McAvoy and Butler, 2009). Abilene Paradox is a decision
taken by a group which no individual decision maker would have taken
(Harvey, 1974). In groupthink socio-psychological factors prevent dis-
sension and the individual accepts the view of the group as correct
(Janis, 1972, 1982; Manz and Sims, 1987).
Yet, cohesion in teams is critical for keeping the team members
aligned with a common purpose and goals Ramesh, Cao, Mohan, and
Xu, 2006). Team cohesion is a one of the six key facets of Team Work
Quality (Hoegl and Gemuenden, 2001). Without a sense of togetherness
and belonging no meaningful collaboration is possible in groups. Further
team cohesion promotes sharing of tacit knowledge amongst team mem-
bers. For example technicians are known to learn more about repairing
copiers by “hanging around swapping stories than from company man-
uals” (Fortune, 1991; Madhavan and Grover, 1998).
Hardy, Eys, and Carron (1995) noted that team cohesion provides
numerous psychosocial and work benefits outcomes of teams. Cohesive
teams demonstrate increased collective efficacy (Paskevich, Brawley,
A.K.S. Kakar
Dorsch, and Widmeyer, 1995) and greater team success (Carron, Col-
man, Wheeler, and Stevens, 2002). Cohesive team members are
less anxious (Eys, Hardy, Carron, and Beauchamp, 2003), more
satisfied (Widmeyer and Williams, 1991), have higher self-esteem
((Julian, Bishop, and Fiedler, 1966), conform to group norms
(Prapavessis and Carron, 1997), make personal sacrifices for the team
(Prapavessis and Carron, 1997), share responsibility for team failure
(Brawley, Carron and Widmeyer, 1987) and are less likely to indulge
in social loafing (Naylor and Brawley, 1992). Additionally, cohesive-
ness reduces dysfunctional conflicts. Breakdown in coordination are a
significant contributor to bugs and design flaws (Petre, 2004).
Empirical studies have shown that cohesive teams are effective
(McGrath, 1984; Prapavessis and Carron, 1997; Sundstrom et al., 1990;
Yang and Tang, 2004). They are more likely to produce better software
products than those riddled with conflicts (Carmel and Sawyer, 1998).
Some deleterious symptoms of lack of cohesion include political prob-
lems in teams (Bradley and Hebert, 1997) and “analysts not speaking
with developers and testers remaining independent of the rest of the
team” (Sawyer, 2004).
Work design research provides evidence (Champoux, 1991; Johns,
Xie, and Fang, 1992; Johnson and Johnson, 1989; Slavin, 1983; Stone,
1986; Wageman, 1995; Campion et al., 1993, 1996) that both autonomy
and interdependence are important considerations in team design. The
right blend of cooperation and autonomy are required to achieve flex-
ibility, responsiveness, and synergy in groups (Nerur, Mahapatra, and
Mangalraj, 2005). But increasing task interdependence may constrain
autonomy and increasing autonomy may reduce task interdependence.
So where does the balance lie? Further, how does one decide what lev-
els of autonomy and interdependence will produce the best results in
enhancing cohesiveness among team members? However, no study to
the best of our knowledge has investigated the interplay between task
interdependence and autonomy in designing work for engendering co-
hesiveness in teams engaged in knowledge work such as software devel-
opment.
2.4. Theory development
Studies have shown that autonomy provides higher job satisfaction
and motivation to knowledge workers than any other job characteristic
(Cheney, 1984; Goldstein and Rockart, 1984; Janz et al., 1997). Auton-
omy is the degree to which the job provides freedom, independence,
and discretion to the employee in scheduling work and in determin-
ing the procedures to be used in carrying it out (Hackman and Old-
ham, 1976). However, higher team member autonomy comes at a cost
to team cohesion (Moe, Dingsøyr, and Dybå, 2008). It can lead to fre-
quent adjustment of tasks, compromises, and conflicts within the team
(Niepce & Molleman, 1988). Software development team members rely
on other team members completing their tasks on schedule and with
requisite quality for timely and successful accomplishment of their own
tasks. As a result, team members instead of valuing their autonomy may
dislike the time and effort spent in negotiations and decision-making
processes that could have been utilized in completion of their own tasks
(Janz, Collquitt, and Noe, 1997); thereby reducing interpersonal inter-
action (Moe, Dingsøyr, amd Dybå, 2008). Limited interaction among
team members reduces the possibility that group cohesion will develop
(Sawyer, 2004) leading us to the following hypothesis:
Hypothesis 1. Autonomy will decrease cohesiveness of software devel-
opment teams
Interdependence is the defining characteristic of groups and the
reason why they are formed (Campion, Medsker, and Higgs, 1993;
Cartwright and Zander, 1968; Shea and Guzzo, 1987). Interdependence
among work teams exists because they contain interrelated tasks for
converting input into output. Kiggundu (1981, 1983) argued that task
interdependence is a job attribute with significant motivating potential.
Further he classified task interdependency into two types by differentiat-
3
Int. J. Human-Computer Studies 111 (2018) 1–11
ing between initiated and received task interdependence. Received task
interdependence is defined as the extent to which a person in a particu-
lar job is affected by the work-flow from one or more other jobs (van der
Vegt, Emans, and van de Vliert, 1998). Initiated task interdependence is
the extent to which work flows from one particular job to one or more
other jobs so that the performance of the latter depends on the initi-
ating job (van der Vegt, Emans, and van de Vliert, 1998). Pearce and
Gregersen (1991) argued that reciprocal interdependence, a character-
istic of most jobs, which occurs when employees initiate as well as re-
ceive interdependence, as in software development, would cultivate the
highest levels of felt responsibility and thus motivate extra-role helping
and citizenship behaviors. When both received and initiated interdepen-
dence exists, team members are more likely to put in efforts to develop
working relationships leading us to the following hypotheses:
Hypothesis 2. Task Interdependence will increase cohesiveness of soft-
ware development teams
To further examine the interactions between task interdependence
and autonomy we also examined the moderating and direct effects of
outcome interdependence on team cohesiveness. Outcome interdepen-
dence is defined as the extent to which team members believe that their
personal benefits and costs depend on successful goal attainment by
other team members (van der Vegt, Emans, and van de Vliert, 1998).
Deutsch (1949, 1973, 1980) and Kelley and Thibaut (1978) proposed
that when outcome interdependence is high, mutual cooperation pre-
dominates and when outcome interdependence is low competition pre-
dominates. Team members believe that other team members’ goal at-
tainment facilitates movement toward their own goals. In the case of
low outcome interdependence, team members believe that other team
members’ successful goal attainment makes them less likely to achieve
their goals.
As evidenced by research findings in social and organizational psy-
chology, group members working under circumstances of high, as op-
posed to low, outcome interdependence are more open-minded regard-
ing others’ arguments and desires, more concerned about each others’
outcomes, and more inclined to search for solutions and compromises
(Campbell and Pritchard, 1976; Deutsch, 1949, 1973, 1980; Guzzo,
1986; Johnson and Johnson, 1989; Johnson, Maruyama, Nelson, and
Skon, 1981; Tjosvold et al., 1991; Tjosvold and Deemer, 1980). Estab-
lishing common ground is essential for collaboration (Flor, 1998). At low
outcome interdependence members of a work team feel thwarted by the
sound job performances of fellow team members while at high outcome
interdependence members of a work team benefit from the sound job
performances of fellow team members (van der Vegt, Emans, and van
de Vliert, 1998). Positive outcome interdependence increases their trust,
commitment and cohesion leading us to the following hypotheses:
Hypothesis 3. Outcome Interdependence will increase cohesiveness of
software development teams
Theoretically, high and low degrees of outcome interdependence
may exist independent of the degree of task interdependence and au-
tonomy. Outcome interdependence is achieved through the way the
goals are defined and achieved and the way that performance is re-
warded (Johnson and Johnson, 1989; Wageman, 1995). For example,
group goals may be set at different levels of task interdependencies and
autonomy such as for programmers working independently as well as
those engaged in paired programming. However, low outcome inter-
dependence (e.g. team member does not see how his work relates to
overall project goals or end product) will exacerbate the impact of low
interdependence (e.g. team member is working independently on tasks
without much interaction with other team members) and low autonomy
(e.g. team member has little leeway in planning and executing his tasks,
supervisors tell give him deadlines for completion of task and also how
to perform them) on team cohesion. The team member working under
such conditions will feel stifled and increasingly isolated from his fel-
low team members as well as his supervisors to the detriment of team
cohesion.
A.K.S. Kakar Int. J. Human-Computer Studies 111 (2018) 1–11

By contrast, high outcome interdependence (such as employee re-

lates his work with overall team goals and group rewards are in play)
will magnify the impact of high interdependence (his work depends on
work outputs of one or more team members and his work output is used
by one or more team members) and high autonomy (he gets to estimate
his own work and how to accomplish it) on team cohesion. Common
goals and rewards mitigate the deleterious impacts of high autonomy
and augment the positive impact of high interdependence on group co-
hesion. Employees will use their autonomy to pursue group goals more
proactively and enthusiastically in collaboration with other team mem-
bers. They will view superior performance of fellow employees as en-
ablers and not as a threat and look forward to collaborating with them
to achieve group goals. When outcome interdependence is high, auton-
omy helps develop employee confidence and capabilities for carrying
out a wider range of responsibilities and tasks (Parker, 1998). Armed
with this higher role-breadth efficacy (Burr and Cordery, 2001; Parker,
1998; Speier and Frese, 1997) employees under conditions of high out-
come interdependence will seek more responsibility for external coordi-
nation (Batt, 1999) leading to development of more proactive role ori-
entations (Parker, Wall, and Jackson, 1997) and greater use of personal
initiative and engagement with other team members in accomplishing
tasks (Frese, Kring, Soose, and Zempel, 1996), thereby enhancing the
combined effect of interdependence and autonomy on team cohesion.
This leads us to the following hypothesis:

Hypothesis 4. At low level of outcome interdependence, task inter-

dependence and autonomy will impact team cohesion antagonistically,
while at high level of outcome interdependence, task interdependence
and autonomy will impact team cohesion synergistically
According to a typology of interdependence (Fig. 1) by
Tesluk et al. (1997) the degree of interdependence increases from
pooled to sequential to reciprocal to intensive. Pooled interdependence
does not involve any interaction between team members. Performance
of the group is an aggregation of individual team member’s perfor-
mance. In sequential interdependence, work flows unidirectionally
from one member to another. Reciprocal interdependence is similar to
sequential interdependence except that the workflow is bidirectional.
In intensive interdependence the entire group must interact with each
other to accomplish group goals.
According to a typology of interdependence (Fig. 1) by
Tesluk et al. (1997) the degree of interdependence increases from
pooled to sequential to reciprocal to intensive. Pooled interdependence
does not involve any interaction between team members. Performance
of the group is an aggregation of individual team member’s perfor-
mance. In sequential interdependence, work flows unidirectionally
from one member to another. Reciprocal interdependence is similar to
sequential interdependence except that the workflow is bidirectional.
In intensive interdependence the entire group must interact with each
other to accomplish group goals.
Plan driven methods of software development such as the waterfall
method and its variants promote conformance to plan and encourage
division of labor leading to specialized roles of business analysts, sys-
tem architects, programmers and testers (Melnik and Maurer, 2006).
In plan-driven methods tasks are process-driven, team members have
little autonomy, and points of employee interfaces are few. Sequential
interdependence predominates as can be seen from Fig. 2 for the water-
fall model (Royce, 1987). Typically, testers interact with coders but not
with designers, designers interact with requirement gatherers but not
with system implementers.
By contrast the agile methods deploy self-managing teams. Teams
and its members have more autonomy. Outcome interdependence is
high. Group goals are the norm and points of employee interface are
many. Practices such as pair programming, planning game, daily stand-
up meetings and frequent integration of code to produce working prod-
ucts in quick iterations represent intensive interdependence among
Fig. 1. Typology of interdependence (adopted from Tesluk et al., 1997).
group members in accomplishing tasks. This leads us to the following
hypothesis:
Hypothesis 5. Plan-driven methods of software development will be
lower in autonomy, task interdependence and outcome interdependence
than agile methods and will therefore result in lower team cohesion
3. Method
To test the proposed hypotheses we conducted a multi-year survey
with development team members of 34 software projects. The devel-
opers were employees of a university’s industry partners and graduate
students of the university who had to complete a software development
project with the industry partners which included 18 companies with 3
of them in the Fortune 500 list. The graduate students were all academ-
ically accomplished and were admitted to the graduate degree program
by invitation only. The type of projects included 14 which the industry
partners characterized as Waterfall method, 4 V-method, 9 Extreme pro-
gramming, 3 Scrum, 1 Crystal methodologies, 1 Dynamic Software de-
velopment method (DSDM), 1 Feature Driven Development (FDD) and 1
Lean Software Development Method (LSDM. This characterization was
vetted by trained research associates. Of the 34 projects 18 were new
software development projects and 16 were upgrades or customization
of existing software. The university has a policy of randomly assigning
the students to alphabetically listed projects in the ascending order of
their last names.
The capstone projects enable students of this large public university
located in the United States of America to work on industrial project
and provide them with job opportunities. The university has a high
placement rate and many of the students who work on the capstone

4
A.K.S. Kakar
Fig. 2. Sequential Interdependence of Plan drive methods (Royce, 1987).
projects are employed by the industry partners. The study was com-
pleted over a 4-year period involving 332 developers who answered a
paper-and-pencil questionnaire based survey at the end of completion
of their projects. The students worked on the project along with the de-
velopment team of the industry partners at their premises as well as at
the university. The overall response rate was 89%, 88% by students and
91% by employees of industry partners. Further responses ranged from
84% to 92% across teams. The projects lasted for a period between 4–6
months. The subjects were between 21–39 year old, 194 males and 148
females who worked on software development projects involving be-
tween 6 to 16 team members. The average age of the subjects was 28.4
years, average experience in industrial software development projects
was 6.3 years and the average number of team members working on the
projects was 10.
3.1. Variables used in the study
The independent variables are task interdependence, outcome in-
terdependence and autonomy of team members of software develop-
ment projects. The dependent variable is team cohesion. Tested mea-
sures from prior literature were adapted to capture data pertaining to
these variables.
Task Interdependence. Tested sub-scales (Kiggundu, 1983; Pearce
and Gregersen, 1991) of initiated and received interdependence con-
sisting of a total of 8 items were used. A sample item of initiated in-
terdependence from this scale is “To what extent do your colleagues
depend on you for information and advice?” A sample item of received
interdependence is: “To what extent do you depend on your colleagues
for doing your work well?”
Outcome Interdependence. A bipolar scale of six items (van der
Vegt, Emans, and van de Vliert, 1998) was used to measure outcome
interdependence. A sample item from this scale is: “When my colleagues
succeed in their jobs, it works out negatively/ positively for me”
Autonomy. The Job Diagnostic Survey (JDS) (Hackman and Old-
ham, 1974) list of 3 items was used to measure Autonomy. A sample
item from this scale is: “The job gives me considerable opportunity for
independence and freedom in how I do the work.”
Team Cohesiveness. The Yu and Chu (2007) list of 7 items based
on the Carron et al. (1985) group environment questionnaire was used
to measure team cohesiveness. A sample item (reverse coded) from this
scale is: “Members of our team would rather go out on their own than
get together as a group”
For a complete list of items used in the measures please see
Appendix A. While Autonomy and Team Cohesiveness used a 9-point
Likert scale with anchors of 1 (strongly disagree) and 9 (strongly agree)
or 1 (very little) and 9 (very much), Outcome Interdependence used a
5
Int. J. Human-Computer Studies 111 (2018) 1–11
bipolar scale anchored at 1 (negative) and 9 (positive). Scale items were
averaged to create an overall value for each construct. Responses were
coded such that high levels of the constructs are represented by high
values. Some items were reverse coded.
3.2. Procedure
Subjects answered a paper-and pencil based survey that captured
data on independent variables, task interdependence, outcome inter-
dependence and autonomy, and, dependent variable, team cohesion of
the software development project. The questionnaire items listed were
scrambled. Data on independent variables, task interdependence, out-
come interdependence and autonomy was collected from the subjects in
the first round of the study. Data on the dependent variables, team cohe-
sion was collected in the second round a week later. Previous research
demonstrates that the temporal separation between measures reduces
potential effects due to Common Method Variance (Sharma, Yetton, and
Crawford, 2009).
3.3. Method of analyses
To establish reliability and validity of the measures used in the study,
factor analysis was performed and internal reliabilities and the corre-
lation matrix of the measures were examined. Moderated Hierarchical
Multiple Regression (MHMR), a widely recommended method for test-
ing moderating relationships or interactions between independent vari-
ables (Cohen, 1978; Cortina, 1993; Dunlap and Kemery, 1987; Stone
and Hollenbeck, 1989), was used for analyzing the data. MHMR analy-
sis reveals how well each independent variable predicts the dependent
variable, after extracting variance due to other independent and control
variables in the regression equation and interaction effects after extract-
ing variance due to independent and control variables.
MHMR was therefore conducted to first test for the main effects of
independent variables task interdependence, outcome interdependence
and autonomy on team cohesion, and then for the two-way interaction
effects between task interdependence and autonomy and finally for the
moderating effect of outcome interdependence on the effects of task in-
terdependence and autonomy on team cohesion. Team size, gender and
years of software development experience of team members were con-
trolled for in the analysis, as they were not the variable of interest in
this study. Large team sizes make it more difficult for team members
to interact with all other team members given the dramatic increase
of possible individual links between team members as team size grows
(Steiner, 1966). It can thus affect collaborative task process (Hackman,
1987; Campion et al., 1993) and team cohesion.
A.K.S. Kakar
Table 1
Internal consistency reliability of scales.
Name of the scale Cronbach’s coefficient Alpha
Task Interdependence (TI) 0.80
Outcome Interdependence (OI) 0.91
Autonomy (A) 0.92
Team Cohesiveness (TC) 0.85
Table 2
Means, standard deviations, correlations.
Variable Mean Std Dev 1 2
TI 5.28 1.11 1
OI 5.23 0.90 0.28∗ ∗ ∗ 1
A 5.67 0.94 0.05 0.01
TC 6.29 0.83 0.15∗ ∗ ∗ 0.14∗ ∗
∗
p < .05 ∗∗
p < .01 ∗∗∗
p< .001
4. Results and analyses
The factor analysis procedure was done using IBM© SPSS© Statistics
Version 19. Dimension reduction was performed on the data pertaining
to the 4 measurement scales. The results of Varimax rotation showed
that the 4 factors extracted represented each of the 4 scales. All items of
a scale (Task Interdependence: T1 to T8, Outcome Interdependence: O1
to O6, Autonomy: A1 to A3 and Team Cohesion: C1 to C7) loaded on
the respective factors (highlighted in bold in Appendix B). Convergent
and discriminant validity between scales were evident (see Appendix B)
by the high loadings within factors (>.50) and no cross loadings (>.40)
between factors. The internal consistency reliability of the scales used in
the study: task interdependence, outcome interdependence, autonomy
and team cohesion were then examined. As can be seen from the Table 1,
the Cronbach’s coefficient alpha for each factor extracted is greater than
.70.
Table 2 provides the means and standard deviations of the data col-
lected in this survey. From the correlation between variables in Table 2 it
is clear that none of the correlations are too high (> 0.65) demonstrating
that each scale is adding something new. As predicted task interdepen-
dence and outcome interdependence have a positive impact on team
cohesion while task autonomy has a negative impact on team cohesion,
thus supporting Hypotheses 1, 2 and 3.
Before analyzing the results of MHMR in Table 3, the normal prob-
ability plot was examined to ascertain the normal distribution of resid-
uals. The Variance Inflation Factor (VIF) option was included in the
analyses to explore the extent of multicollinearity in the results. All the
VIF values were less than 1.5 indicating a lack of multicollinearity in
the results (Hair, Black, Babin, Anderson, and Tatham, 2006).
Results from MHMR analysis in Table 3 show a significant (p < .01)
three-way interaction among task interdependence, outcome interde-
pendence and autonomy in predicting team cohesion. For analyzing the
interactional impacts we performed a simple slope test as recommended
by Aiken and West (1991). Further we also conducted a slope difference
test suggested by Dawson and Richter (2006) to determine if the differ-
ence in slopes calculated by the Aiken and West (1991) method at 1
standard deviation (1SD) above mean and 1 standard deviation (1 SD)
below mean of the moderating variables is significant.
Analyses of the three way interaction reveals that at high outcome in-
terdependence (1 Standard Deviation above mean) and high task inter-
dependence (1 Standard Deviation below mean) autonomy has a signif-
icantly (p < .01) positive impact (B = 0.432) on team cohesion while at
high outcome interdependence (1 Standard Deviation above mean) and
low task interdependence (1 Standard Deviation below mean) autonomy
has a non-significant (p > .05) impact on team cohesion. Further, at low
outcome interdependence (1 Standard deviation below mean), and high
task interdependence (1 Standard Deviation above mean) as well as low
task interdependence (1 Standard deviation below mean), Autonomy
Int. J. Human-Computer Studies 111 (2018) 1–11
has a significantly (p < .05) negative impact (B = −0.229, −0.172) on
team cohesion. Thus Hypothesis 4 was fully supported.
Number of items Further, Table 3 shows, the two-way interaction effect of autonomy
8
and task interdependence on team cohesion was significant (p < .001)
6 but negative. While we report this finding only for the sake of com-
3 pleteness, the interpretation of the two-way interaction is constrained
7 by the presence of the significant three-way interaction. The presence of
a significant (p < .01) three way interaction supports Hypothesis 4. The
synergistic (positive effect) of task interdependence and autonomy on
team cohesion at high outcome interdependence as well an antagonistic
3 4 effect (negative impact) of task interdependence and autonomy on team
cohesion at low outcome interdependence were observed as expected.
Further, t-tests conducted for ascertaining the difference in means
1 showed that software development projects using agile methods which
-0.19∗ ∗ ∗ 1 were found to be significantly (p < .05) higher than plan-driven methods
in all the three criteria: task interdependence, outcome interdependence
as well as autonomy were also significantly higher in team cohesion (see
Table 4). Thus Hypothesis 5 was also supported.
5. Discussion
Thus, overall the suggested model of relationships between task in-
terdependence, outcome interdependence, autonomy, and team cohe-
sion was supported by data. The results of the study show that autonomy
has a significant positive impact on team cohesion only when both task
as well as outcome interdependence is high. When the team members’
perception of outcome dependence is low, an increase in task autonomy
as well as task interdependence can be counterproductive for enhancing
team cohesion. Therefore, software projects that wish to enhance team
cohesion should focus on enhancing each: autonomy, task and outcome
interdependence.
The validity of this approach is evidenced from the results presented
in Table 4 when interpreted further in the context of the practices of
the two major paradigms of software development. The study findings
of higher cohesion in teams adopting agile methods are not only con-
sistent with the findings across multiple empirical studies in the past
(Cockburn and Highsmith, 2001; Dyba and Dinsoyr, 2008; Layman,
Williams, and Cunninghma, 2004; Mann and Maurer, 2005; Mannaro,
Melis, and Marchesi, 2004; Melnik and Maurer, 2006), but also, as ex-
pected, the result of outcome interdependence converting the negative
two-way interactional impacts of task interdependence and autonomy
on team cohesion (Step 3, Table 3) into a positive three-way interac-
tional impact (Step 4, Table 3).
Unlike the heavy-weight process driven approach of plan-driven
methods, Agile processes are typically light weight (unlike plan-driven
methods). The focus in agile methods is on establishing a self-organizing
team culture that emphasizes common responsibilities and goals and yet
individual team members are trusted to decide for themselves the best
way to perform a task. Practices such as collective ownership of code
promote positive outcome interdependence. It implies that the code is
owned by everyone and can be changed by anyone to improve the sys-
tem (Beck, 1999). Autonomous self organizing teams use planning game
or sprint planning meetings to plan for the next development iteration
(or sprint). Developers have autonomy to estimate their own stories
(Whitworth and Biddle, 2007). All team members participate in these
meetings where interdependence among team members in achieving the
goals of the upcoming iteration gets highlighted (Beck, 1999; Alliance,
2008). Developing working products in iterations enhances interaction
and interdependence among team members (Ramesh, Cao, Mohan, and
Xu, 2006; Whitworth and Biddle, 2007). At the completion of iteration
retrospectives are conducted where team members collaboratively dis-
cuss their performance in the previous iteration and identify strategies
for improvement (Alliance, 2008). The effect of these agile practices is
borne out by the findings of the study (Tale 4) which show that agile
methods are more successful in enabling positive outcome interdepen-
dence among team members than plan-driven methods. By establishing
6
A.K.S. Kakar Int. J. Human-Computer Studies 111 (2018) 1–11

Table 3
Moderated hierarchical multiple regression analysis results for team cohesiveness.

Step Variables added in each step Change in R-square (∆R2 ) 2) Regression coefficients (𝛽)

1 Control variable
Gender, Experience, Team Size 0.04∗ 0.02, 0.05∗ , 0.04∗
2 Main effects
Task Interdependence (TI) 0.19∗ ∗ ∗ 2.99∗ ∗ ∗
Outcome Interdependence (OI) 0.18∗ ∗ ∗ 2.48∗ ∗
Autonomy (A) 0.09∗ ∗ -1.64∗
3 Two way interaction
A ∗ TI 0.06∗ ∗ - 3.41∗ ∗ ∗
4 Three way interaction
A ∗ TI ∗ OI 0.09∗ ∗ ∗ 4.97∗ ∗

Note: ∆R is the incremental variance explained by each predictor after the other predictors have been
2

entered into the equation within each step. Total ∆R2 = 0.63
∗
p < .05 ∗ ∗ p < .01 ∗ ∗ ∗ p<.001; N = 332

Table 4
Comparison of agile and plan-driven methods.

Variables Agile methods Plan-driven methods Difference in means

Mean Standard deviation N Mean Standard deviation N

Task Interdependence (TI) 5.54 1.12 163 5.03 0.98 169 0.51∗ ∗ ∗
Outcome Interdependence (OI) 5.60 0.85 163 4.88 1.06 169 0.72∗ ∗ ∗
Autonomy (A) 6.66 0.98 163 4.74 0.93 169 1.92∗ ∗ ∗
Team Cohesiveness (TC) 6.53 1.19 163 6.05 1.03 169 0.48∗ ∗ ∗
∗∗∗
p < .001

collective responsibility and ownership, the agile methods are thus able
to simultaneously leverage the salutary effects of high autonomy and
high task interdependence in enhancing team cohesion.
However, although software development methods are broadly clas-
sified into two categories, the Agile methods and the Plan-driven or Tay-
lorist methods, within each category there are many different methods
each with their own principles and practices making comparisons be-
tween them confusing. For example, there are many Agile methods cur-
rently in use such as Extreme programming, Scrum, Crystal methodolo-
gies, Dynamic Software development method (DSDM), Feature Driven
Development (FDD) and Lean Software Development Method (LSDM)
with each focusing heavily on some of the principles of the agile mani-
festo and completely ignoring others making it impossible to reach any
conclusions on specific agile methods and their use (Conboy and Fitzger-
ald, 2004). The sample size did not permit further statistical analyses of
differences within these two major paradigms.
Therefore the results only broadly reflect the distinction between
Agile methods and plan-driven methods, although they do provide use-
ful insights into the characteristic differences between the two major
paradigms of software development. However, it needs to be pointed
out that these paradigms neither originated nor are exclusive to soft-
ware development. They originated in manufacturing and the vast body
of literature on work design. These paradigms are also consistent with
literature on general organizational theory. While plan-driven methods
represent the ‘mechanistic’ structures associated with routinized tasks,
codified knowledge and centralized decision-making appropriate for sta-
ble conditions, agile methods represent the ‘organic’ structures associ-
ated with tacit knowledge sharing and decentralized decision-making
appropriate for more uncertain environments (Boehm, 2002; Boehm and
Turner, 2004; Burns and Stalker, 1961; Vinekar, Slinkman, and Nerur,
2006). Past research suggests that both types of teams are important for
organizational success. While mechanistic structures influence exploita-
tive behavior and attainment of goals related to process, stability, and
efficiency, organic structures promote explorative behavior and attain-
ment of goals related to flexibility, adaptability, and innovation (Burns
and Stalker, 1961; Duncan, 1976; He and Wong, 2004; Jansen, Van den
Bosch, and Volberda, 2005; O’Reilly and Tushman, 2004; Tushman and
O’Reilly, 1996). Thus the findings of the study although conducted in
the context of software development projects might be applicable to all
teams in general.
Nevertheless, the findings of the study should be viewed in the light
of its limitations. The use of self-report of team members to the variables
used in the survey raises the issue of common method bias inflating the
effect size. However, the study was designed to introduce temporal sep-
aration between user responses which has the effect of mitigating com-
mon method bias (Sharma, Yetton, and Crawford, 2009). Additionally,
the methods bias is unlikely to produce such inflation for moderation
effects (Schmitt, 1994); the interaction effects are more likely to be at-
tenuated rather than inflated (Evans, 1985).
Finally, the causal relationship suggested in the study may be con-
tested on philosophical and methodological grounds. Causal relation-
ships can be extremely complex and inconclusive and cannot be resolved
mathematically or statistically (DeLong and Summers, 1994). Further,
temporal precedence, a key condition of causality (Hume, 1977) is of-
ten difficult to detect (Simon, 1953). A strong case is therefore made
in literature for the adopting a “theory-based discovery of causal rela-
tionships” (Lee, Barua and Whinston, 1997). Accordingly, we have de-
fended the causal direction proposed in the study based on theoretical
reasoning. We also argue that team cohesion builds later over time. In
terms of precedence, the stage is set first by different levels of the pro-
posed causal variables, autonomy and interdependence, depending on
the methodology adopted by the team.
5.1. Contribution and practical implications
Cohesion is considered important for team success. Cohesive groups
demonstrate higher commitment to group tasks and achieving group
goals than non-cohesive groups (Berkowitz, 1954; Shaw, 1981). Group
cohesion is also known to positively enhance team performance
(Basadur, 1997; Balthazard et al., 2004; Yang and Tang, 2004). Keeping
this context in view, this study, a first of its kind, models and tests the
relationship between autonomy, task interdependence, outcome inter-
dependence and their impact on team cohesion. The model is found to
be valid. By expounding and testing the complex relationships between
these constructs the study provides a systematic way of designing teams

7
A.K.S. Kakar
for enhancing team cohesion without compromising higher levels of ei-
ther task interdependence or autonomy.
While the direct impact of task interdependence is positive for team
cohesion, the direct impact of autonomy is negative for team cohesion.
However, just as task interdependence is considered a key characteris-
tic of teams, autonomy has a positive impact on team member moti-
vation, facilitates rapid adjustment to changing environments and pro-
motes innovation. The findings of synergistic impacts of high autonomy
and high task interdependence on team cohesion at high outcome inter-
dependence thus resolves an apparent dilemma in designing teams by
accomplishing the goal of enhancing team cohesion without incurring
the detrimental effects of low autonomy.
Software development is a knowledge-intensive endeavor
(Robillard, 1999) rooted in innovation management and creativity
(Brooks 1997; Carayannis and Coleman 2005; Conboy and Morgan,
2010; Cougar 1990; Elam and Mead 1987; Gallivan, 2003; Lobert and
Dologite 1994; Nambisan and Wilemon, 2000). Although, individual
creativity is important and crucial, software development is rarely an
individual undertaking but creative cooperation of the entire team
(Leonard and Sensiper, 1998). Software development thus typically
represents teams that create complex products and services through
integration of the unique skills, diverse knowledge, and cognitive
abilities of the knowledge workers with varied personalities (Blackler,
1995; Capretz, 2003). The unpredictable and evolving nature of knowl-
edge work makes helping and sharing behaviors among team members
critical for successful outcomes (Janz, Collquitt, and Noe, 1997). It
is not surprising that team cohesion is considered a prerequisite for
creative and innovation behaviors of knowledge teams (Hülsheger,
Anderson, and Salgado, 2009; West and Farr, 1989; Woodman et al.,
1993) as it provides a safe environment in which team members feel
free to challenge the status quo and explore new ways of doing things
(King et al., 1991; West and Wallace, 1991). By providing deeper
insights into team structures and variables that promote team cohesion,
the study findings thus have useful implications for all teams engaged
in innovation and knowledge work such as software development.
Further, the study findings provide pointers to managing software
development teams in the context of the rapidly changing nature of work
as well as the environment under which the work is undertaken. Due
to decentralization of work processes and globalization, virtual teams
are becoming increasingly prevalent. These geographically dispersed
virtual team members communicate and coordinate their work with
each other mostly impersonally through voice or video-conferences and
emails. Effective supervision and coordination among team members of
such virtual teams is therefore challenging. Additionally, software is in-
creasingly integrated with physical products requiring the deployment
of cross-functional teams in the development and maintenance phases.
Cross functional teams comprising business users from across functional
areas and engineering groups from multiple disciplines lack hierarchical
authority (Bligh et al., 2006).
Work in such teams is accomplished through trust, negotiations and
relational contracts (Powell, 1990) making team cohesion unavoidable
for achieving results. However, identifying and resolving team disputes
and engendering team cohesion is particularly difficult leading to im-
paired performance (Bell and Kozlowksi, 2002; Duarte and Snyder,
1999; Hertel, Geister, and Konradt, 2005). The findings of the study in-
dicate that enhancing outcome interdependence by setting group goals
and team based rewards can provide a means of increasing cohesion
among group members. Thereby facilitating geographically dispersed
team members and sub-groups from different disciplines to realize their
common stake in the success of the project and motivating them to par-
ticipate willingly in interdependent tasks while retaining their auton-
omy.
Int. J. Human-Computer Studies 111 (2018) 1–11
Finally, the study highlights the essential differences between the
two major paradigms of software development, the agile and the plan-
driven method. “Theoretically comprehending the distinction between
agile methods and plan-driven methods is a concern begging for re-
search attention.” (Dingsoyr, Nerur, Balijepally, and Moe, 2012). This
study suggests that the distinction may lie in the way the two teams are
designed. Agile methods were introduced as a reaction to the process
dominated approach of plan-driven methods. When processes become
heavy weight and compliance is enforced, they hamper creativity and
flexibility at work. Additionally, they inhibit agility in responding to un-
certainty and change. Further, processes that specify how work should
be done inhibit employee autonomy which is considered a key factor
in work motivation. By setting collective goals and highlighting task in-
terdependence (through frequent face to face interactions in the form
of daily stand-up meetings and team planning exercises) but leaving
the choice on how to perform the individual tasks to the team mem-
bers, agile methods enhance team cohesion by harnessing the syner-
gistic impacts of higher outcome interdependence, task e interdepen-
dence and autonomy. Further, keeping in view the salutary impacts of
team cohesion on its performance, the study also provides a reason for
the effectiveness and increasing popularity of agile methods compared to
plan-driven methods of software development (Abrahamsson, Conboy, and
Wang, 2009; Dyba and Dingsøyr, 2008).
Appendix A. Measures used in the study
Measures and Items
Team Cohesiveness
I am not happy with my share of resources for performing my tasks
I am unhappy with the level of my team’s desire to excel
This team does not give me enough opportunities to improve my personal
performance
I do not like the way the team is managed
Members of our team would rather go out on their own than get together as a
group
Members of our team do not stick together outside the context of work
Our team members have conflicting aspirations in terms of team performance
Task Interdependence - Received
To what extent do you depend on your colleagues for information and advice?
To what extent do you depend on your colleagues for materials, means, and
other things you need?
To what extent do you depend on the presence, help, and support of your
colleagues?
To what extent do you depend on your colleagues for doing your work well?
Task Interdependence - Initiated
To what extent do your colleagues depend on you for information and advice?
To what extent do your colleagues depend on you for materials, means, and
other things they need?
To what extent do your colleagues depend on your presence, help, and support?
To what extent do your colleagues depend on you for doing their work well?
Outcome Interdependence
It (benefits/hinders) me when my colleagues attain their goals.
The things my colleagues want to accomplish and the things I want to
accomplish are (compatible/ incompatible).
It is (advantageous/ disadvantageous) for me when my colleagues succeed in
their jobs.
When my colleagues succeed in their jobs, it is at my (expense/benefit).
My concerns and those of my colleagues are (harmonious/ clashing).
When my colleagues succeed in their jobs, it works out (positively/ negatively)
for me.
Autonomy
The job gives me considerable opportunity for independence and freedom in
how I do the work
The job denies me any chance to use my personal initiative or judgment in
carrying out the work. (Reverse coded)
The job provides substantial freedom, independence, and discretion to the
employee in scheduling his work and in determining the procedures to be used
in crying it out.