How Agile Practices Impact Customer Responsiveness and Development Success - A Field Study

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/315498894
How Agile Practices Impact Customer Responsiveness and Development

Success: A Field Study
Article in Project Management Journal · April 2017

DOI: 10.1177/875697281704800208
CITATIONS READS
59 1,694
4 authors, including:
Jan Recker Christoph Rosenkranz

University of Hamburg University of Cologne
335 PUBLICATIONS 11,312 CITATIONS 133 PUBLICATIONS 1,223 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Generating Innovations in IT Outsourcing Engagements View project
Circular Economy in the Digital Age View project
All content following this page was uploaded by Jan Recker on 13 October 2017.
The user has requested enhancement of the downloaded file.

PAPERS How Agile Practices Impact Customer
Responsiveness and Development
Success: A Field Study
Jan Recker, QUT Business School, Queensland University of Technology, Brisbane, Australia
Roland Holten, Faculty of Economics and Business Administration, Goethe University Frankfurt,
Germany
Markus Hummel, Senacor Technologies AG, Eschborn, Germany
Christoph Rosenkranz, Faculty of Economics, Business and Social Sciences, University of
Cologne, Germany
ABSTRACT ■ INTRODUCTION
A
gile methods for information systems development, such as
Agile information systems development Extreme Programming (Beck, 1999) or Scrum (Schwaber & Beedle,
methods have become popular; how- 2002), have become popular in today’s software industry because
ever, which specific agile practice to use they reportedly provide ways to improve an information systems
remains unclear. We argue that three types development team’s flexibility in terms of the ability to embrace and respond
of agile practices exist—for management, efficiently and effectively to changing requirements (Conboy, 2009; Lee & Xia,
development, and standards—which affect 2010; MacCormack, Verganti, & Iansiti, 2001).
the customer responsiveness of software In the literature, two streams of research inform the current understand-
teams differently. We examine this theory ing of agile information systems development. One stream has focused
in a field study of a large organization. We largely on the management of agile teams (Lee & Xia, 2010; McHugh, Conboy,
find that agile practices improve software & Lang, 2014; Whitworth & Biddle, 2007). This research suggests that agile
team response effectiveness or efficiency, information systems development can lead to successful development if
but not both. Agile standards do not improve and when teams are autonomous and diverse (Lee & Xia, 2010) or cohesive
response mechanisms but are still important and motivated (Whitworth & Biddle, 2007). A second stream of research has
to successful information systems devel- examined agile methodologies and their use (Erickson, Lyytinen, & Siau, 2005;
opment. Our findings help discriminating Maruping, Venkatesh, & Agarwal, 2009; Maruping, Zhang, & Venkatesh, 2009;
agile practices and yield insights into how Pikkarainen, Haikara, Salo, Abrahamsson, & Still, 2008). This work shows,
information development projects should for instance, that different cultures favor different agile methods (Iivari &
be managed. Iivari, 2011), and that agile methods have a positive impact on project success
(Serrador & Pinto, 2015).
KEYWORDS: information systems Our ambition is to integrate the two streams of research. We believe this
development; agility; agile practices; move is important because it allows for understanding of the interdependen-
customer responsiveness; field study; cies between the social (teams—the structure) and the technical (agile tools
panel survey and methodological procedures—the technology and tasks) in the sociotech-
nical work that is information systems development information systems
development (Bostrom, Gupta, & Thomas, 2009; Winter, Berente, Howison,
& Butler, 2014). We also believe this move is timely, because an understand-
ing of the interdependencies between the social and technical components
of information systems development requires a thorough understanding of
each component, which is provided in isolation by the two existing streams
in the literature. In making this move we can examine the contributions of
each component relative to each other (i.e., the social versus the technical)
Project Management Journal, Vol. 48, No. 2, 99–121
and also evaluate the contribution offered by the joining of the components
© 2017 by the Project Management Institute
(i.e., the socio-technical).
Published online at www.pmi.org/PMJ
April/May 2017 ■ Project Management Journal 99

How Agile Practices Impact Customer Responsiveness and Development Success
PAPERS
Specifically, we focus on how differ- extended model informs the agility of during an information systems develop-
ent agile practices (the technical compo- information systems development teams ment project life cycle. Response extensive-
nent) affect customer responsiveness of and information systems development ness describes the extent, range, scope,
agile teams (the social component). This success. We examine our research model or variety of software team responses
has not yet been addressed in the existing using panel data gathered in a field study to customer inquiries, and response effi-
literature. By making this move, we can from a sizable agile development initia- ciency relates to the time, cost, resources,
also address an ecologically fundamen- tive within a large retail organization. or effort associated with software team
tal problem of agile development, that Our research contributes to the lit- responses (Lee & Xia, 2010, p. 90).
of method comparison (Conboy, 2009): erature in several ways: Theoretically, we The key elements of agile approaches
What are the effects of different agile prac- provide an extended model of informa- to information systems development usu-
tices? And, which agile practices from tion systems development agility that ally include close collaboration among
which available methodologies should be draws attention to different types of agile stakeholders, intensive iteration and
employed in information systems devel- practices and their relative influence on rapid prototyping, openness to changing
opment projects? While statements such software team response effectiveness and requirements, and the eschewal of heavy-
as those in the Agile Manifesto (Fowler & efficiency. This is an important extension weight processes and formal documenta-
Highsmith, 2001) portray agile informa- to the literature, which thus far has exam- tion (Conboy, 2009). Thus, the label of
tion systems development as a coherent, ined team characteristics as antecedents agile information systems development is
simple, and clear concept, the reality of to agility (Lee & Xia, 2010). Empirically, an umbrella term for a number of distinct
agile is much different, much messier we compare different agile practices with methodologies organized around some
(Conboy, 2009), and requires interpreta- different agile methodologies in terms common principles. In a literature review
tion of what is essential and what is less of how they contribute to information (Hummel, Rosenkranz, & Holten, 2013),
essential (Iivari & Iivari, 2011). systems development success, in turn we found that some of these principles
We will show that the problem of providing empirical evidence about the and practices (such as pair programming
selecting agile practices is far from sim- efficacy of different agile practices, which or onsite customers) have received signif-
ple, yet of significant value to the litera- helps to discriminate the “methodology icant attention in the literature, whereas
ture and practice: For the literature on jungle” (Conboy, 2009). other practices (such as collective code
agility, differentiating between varying We proceed as follows. First we ownership or continuous integration)
types and components is helpful, as it review the prior research on agile infor- have not. Moreover, the impact on agility
helps to identify subsets of practices mation systems development and the and the relative value of those practices
(Ågerfalk, Fitzgerald, & Slaughter, 2009) different constituent practices that char- that have been examined in the literature
with different effects on different com- acterize agility. Next we describe our (e.g., pair programming) remains incon-
ponent parts of agility (Conboy, 2009). research model and develop our propo- clusive (Balijepally, Mahapatra, Nerur,
For the practice on agility, this move sitions. We then provide a description of & Price, 2009), signifying a lack of clar-
yields ecological and pragmatic value to the research methods used and exam- ity in our theoretical understanding of
organizations. Companies typically have ine our data. We discuss findings and agility. This has been also alluded to as
more design freedom in selecting a set implications and then provide a review the missing “theoretical glue” (Conboy,
of practices—the technical component of limitations and contributions. 2009, p. 330) of agile information systems
of agile—which they can employ, train, development. Yet, independent of the
or in case discard, than they have in Prior Research inconclusive and imbalanced academic
selecting the structure and composition Agile Information Systems Development debate over the value of different agile
of information systems development Agile information systems development practices, the industry practice of infor-
teams—the social component of agile. approaches such as Scrum (Schwaber mation systems development has seen
To meet our objective, we start with & Beedle, 2002), Extreme Programming the widespread adoption of the different
the model of information systems devel- (Beck, 1999), and Crystal (Cockburn, available methodologies in recent years
opment agility proposed by Lee and 2001) purportedly provide ways to (Dingsøyr, Nerur, Balijepally, & Moe,
Xia (2010), which focuses on the effec- improve a team’s agility in terms of the 2012; VersionOne, 2015).
tiveness and efficiency of agile teams’ ability to embrace and respond to chang- Two lines of argument inform the cur-
responses to changes demanded by cus- ing requirements (Conboy, 2009; Lee & rent understanding of a nascent ‘theory
tomers. We then extend this model by Xia, 2010). Following Lee and Xia (2010), of agile.’ The first, proposed by Lee and
identifying different types of agile prac- we define information systems develop- Xia (2010), argues that agile information
tices, viz., development practices, man- ment agility as a development team’s abil- systems development is fundamentally
agement practices, and agile standards ity to efficiently and effectively respond people-centric and recognizes the value
and norms. We then examine how this to user or customer requirement changes of team members’ competencies in
100 April/May 2017 ■ Project Management Journal

bringing agility to information systems of integration between the two streams: 2006). Inevitably, this has led to the emer-
development processes; therefore, the both lines of research examine agile gence, adoption, and use of multiple vari-
team’s characteristics are important (Lee information systems development from ations or implementations of ‘textbook’
& Xia, 2010, p. 90). This research has a team angle but choose different lenses methodologies. In turn, different agile
shown that two factors affect response and measures to do so. For example, the practices are employed in any given proj-
extensiveness and response efficiency: study by Lee and Xia (2010) examined ect, which are parts of one or more ‘text-
(1) team diversity—the heterogeneity information systems development suc- book’ methodologies (Berente, Hansen, &
within the team in terms of individual cess in terms of software functionality Rosenkranz, 2015). In essence, that makes
attributes, such as age, gender, ethnic and completion on-time and on-bud- the selection of which agile practices to
background, education, functional back- get, whereas Maruping, Venkatesh, and use a choice problem for practitioners.
ground, tenure, and technical abilities; Agarwal (2009) and Maruping, Zhang, Much in the same way that agile-
and (2) team autonomy—the degree of and Venkatesh (2009) used project qual- in-use differs between organizations
discretion and independence granted ity in terms of bug severity and software (VersionOne, 2015), the scholarly atten-
to the team in scheduling the work, complexity as measures. tion devoted to the different available
determining the procedures and meth- We argue that it is both feasible and practices also varies and some prac-
ods to be used, selecting and deploying prudent to integrate these two primary tices are viewed as more prominent.
resources, hiring and firing team mem- views on agility, and to extend their For example, literature such as those
bers, assigning tasks to team members, primary unit of interest toward more provided by Hummel et al. (2013) and
and carrying out assigned tasks. salient choice factors: the question of Dingsøyr et al. (2012) show that there
A second line of research in the liter- which methodology or practice to use in is a large body of work on pair pro-
ature, which has proceeded quite inde- agile information systems development gramming (Balijepally et al., 2009)
pendently, focuses on the behavior and (Conboy, 2009). but relatively little work on collective
management of information systems code ownership (Maruping, Zhang, &
development teams in terms of how they The Differences Between Agile Practices Venkatesh, 2009). What remains miss-
can be both enabled and restricted in Several agile information systems devel- ing is an understanding of the various
their autonomy and flexibility to respond opment approaches are described in agile practices in terms of (1) their spe-
to changing requirements (Maruping, textbooks (e.g., Beck, 1999; Schwaber & cific effects on agility, (2) their relative
Venkatesh, & Agarwal, 2009), and how Beedle, 2002), covering rules to follow in value, and (3) their comparative benefits
they can be enabled to coordinate terms of the actions and outcomes that for information systems development
(Maruping, Zhang, & Venkatesh, 2009). are required, prohibited, or permitted. (Ågerfalk et al., 2009). This situation
Both lines of research have in com- Agile information systems develop- leads to the challenge of parsimony
mon that the primary unit of interest is the ment approaches-in-use, however, are (Conboy, 2009) in that many practices
team that is using agile methodologies. often not followed by the book; rather likely share redundancies and dupli-
While we agree that team characteristics they can be characterized as a combi- cation. Still, practices remain the key
are important, these usually are seen as nation of practices taken from differ- design element for organizations and
input factors to the information systems ent methodologies (Abrahamsson, Salo, management and are the most salient
development process (Siau, Long, & Ling, Ronkainen, & Warsta, 2002; Fitzgerald, factor in designing interventions and
2010), and as such, rather static and less Hartnett, & Conboy, 2006). The diversity guidance for how to engage in success-
amenable to change for an information of agile methodologies, along with pat- ful information systems development.
systems development project at any given terns of common components and prac- In the following section, we propose a
point in time. For example, it is hard to tices across them, therefore suggests that classification for the differentiation of
conceive that information systems devel- information systems development is not agile practices based on the mode and
opment managers can choose anything or a question of approach (Wang, Conboy, locus of control these practices provide.
do much about team diversity with given & Cawley, 2012), method (Conboy, 2009),
and fixed resources in terms of avail- or methodology (Maruping, Venkatesh, Theory Development
able team members within a company. & Agarwal, 2009), but rather a ques- To overcome the challenge of parsimony
The same holds for team autonomy— tion of practices that team members can (Conboy, 2009), the means that allow
one cannot simply command it, so how choose to enact as a methodology-infor discrimination of agile practices
does one bring about independence and use (Fitzgerald, 1997). need to be discovered. We suggest that
self-organization within a team, without Different practices from different one purposeful way of discrimination
a considerable allowance of time? approaches are often chosen at the start is examining the ways in which agile
The second problem in the current of a project to tailor the methodology to practices provide the means to main-
level of understanding pertains to a lack specific project settings (Fitzgerald et al., tain control over information systems

PAPERS
development. Our basic assumption is Through examining how guide- 2. A second set of practices focuses
that, even though agile information sys- lines and rules are embodied in agile on the development element and
tems development promotes flexibility practices, and falling back on other ensures developers’ autonomy,
and autonomy, the practices by which approaches that try to categorize specifying rules of self-regulation
agility is enacted still provide some practices (Bourque & Fairley, 2014; and self-monitoring. In the context
degree of structure or constraints to proj- Jacobson, Ng, McMahon, Spence, & of information systems development,
ect teams, which is important in the man- Lidman, 2012), we suggest that at least “development work” is everything
agement of team work (Barki & Hartwick, three sets of agile practices be distin- that the team does to meet the goals of
2001) to avoid detrimental outcomes due guished. Table 1 summarizes our defi- producing an IS matching the require-
to individual volition (Cohen & Bailey, nitions of the types of agile practices, ments and addressing the opportu-
1997) or “free-wheeling” (Boehm, 2002). which we discuss in turn: nity presented by the stakeholders.
In other words, agile information sys- These practices provide autonomy
tems development does not equate with 1. One set of agile practices primarily sets to single developers and rules about
methodological or managerial anarchy. out to support the management of how to monitor and regulate their
Instead, much like the traditional information systems development proj- actions. Although these practices
approaches to software development ects. Information systems development require intense interaction with one
or project management, agile practices, is a significant endeavor that typically or more peer developers, their focus
while promoting certain team work takes many weeks to complete, affects is nonetheless on constraining the
properties such as flexibility, autonomy, many different people (the stakehold- actions of the individual developer,
and self-regulation, still encompass ers), and involves a development team and therefore on the self-regulation of
means that ensure that “individuals (rather than a single developer). Any goals and self-monitoring of progress.
working on projects act according to an practical method must describe a set So the focus of development prac-
agreed-upon strategy to achieve desired of practices to effectively plan, lead, tices is on self-control and the tasks
objectives” (Kirsch, 1996, p. 1). Pair pro- and monitor the efforts of the team. for software development rather than
gramming, for example, provides fairly Practices in this set seek to describe procedures that affect the progres-
strict and precise guidelines about how and enforce behaviors, processes, and sion of a project itself. For example,
individuals should collaborate in code procedures that must be followed dur- practices from Extreme Programming
development (Beck, 1999, p. 58): “There ing information systems development in this group are pair programming
are two roles in each pair. One part- projects, and that concerns how the (PP), prescribing the interaction
ner, the one with the keyboard and the projects as such unfold. Typical exam- of coder and reviewer in a team of
mouse, is thinking about the best way to ples are the practice of daily stand-up peers at one workstation (Vidgen &
implement this method right here. The meetings (STM) from Scrum, enforc- Wang, 2009), and continuous code
other partner is thinking more strategi- ing high communication frequency integration (CCI), enforcing regular
cally: Is this whole approach going to between team members in short and rigorous feedback on new code
work?” Other practices such as stand-up meetings (Pikkarainen et al., 2008), integrated into the whole system’s
meetings, sprint planning, or backlog and the practice of small releases (SR) code (Xiaohu et al., 2004).
grooming also follow clear behavioral from Extreme Programming, which 3. A third set of practices prescribes
and procedural norms and rules for how enables rapid feedback from customers standards and norms that the whole
these engagements should proceed. (Xiaohu, Xu, He, & Maddineni, 2004). team must follow. The development
Type of Agile Practice Definition Examples of Agile Practices

Management practices Rules and procedures for joint discussions by providing behaviors, Daily stand-up meetings; small
processes, and artifacts that must be followed in team meetings releases
Development practices Rules that provide autonomy to developers to determine themselves what Pair programming; continuous code
actions are required and how to execute them and which emphasize self- integration
regulation of goals, processes, and progress
Standards and norms Stipulation of acceptable team behaviors by sharing development Collective code ownership; coding
standards and norms of artifacts and components (code) and reinforcing standards
shared behavior through shared objects
Table 1: Types of agile practices with examples.

work is guided by these practices, practices can be evaluated in terms of efficiently respond to changing cus-
which make up the team’s ways of how they affect agility understood as tomer requirements.
working. The team evolves their way response extensiveness and efficiency, Third, we distinguish management
of working alongside their under- and how they influence the outcomes of practices from development practices
standing of their mission and working agile development. Figure 1 illustrates and agile standards and norms as dis-
environment. As their work proceeds, this model. cussed in Table 1.
they continually reflect on their way The research model has three com- We now discuss propositions that
of working and adapt it to their cur- ponents. First, we follow Lee and Xia link the concepts in our research model.
rent context, if necessary. These prac- (2010) and define information systems We start by positing that agility posi-
tices socialize certain norms among development success as the relevant tively impacts information systems
team members (e.g., responsibility dependent variable of agile develop- development success. Successful infor-
for code written by others and giving ment. We conceptualize success in mation systems development largely
peers the responsibility for their own three dimensions. First, software func- depends on meeting customer require-
code) and reinforce shared rituals and tionality, as the extent to which the ments in the delivery of software. If
experiences (e.g., thinking about side delivered software meets functional responses made to changes of customer
effects their own code might have). goals and end-user requirements (Lee requirements are extensive, it implies
For example, coding standards (CS), & Xia, 2010; Weitzel & Graen, 1989). that they include broad and detailed
which prescribe rules all developers Second, process performance, to pro- information about how requirements
have to follow when developing code vide a resource-oriented view on the translate to software functionality. This
(Hazzan & Dubinsky, 2003), and col- on-time and on-budget completion in turn should also lead to elevated
lective code ownership (CCO), which of the project (Wallace & Keil, 2004). customer satisfaction. Responding effi-
gives each team member responsi- Third, customer satisfaction, because it ciently means that development teams
bility for all the codes (Xiaohu et al., is one of the fundamental principles of can swiftly alter software when require-
2004), belong to this set of practices. agile information systems development ments change, in turn increasing per-
as advocated in the Agile Manifesto formance of the development process.
(Fowler & Highsmith, 2001). Together, the more agile a team oper-
Propositions Second, we again follow Lee and ates, the more successful the outcomes
We now develop a research model Xia (2010) and define agility as the of the projects should be and we there-
to evaluate our assertion that agile ability of agile teams to extensively and fore propose:
P1: Agility positively affects information

systems development success.
Agile development
practices Next, we examine how agility
is influenced by the three different
Information systems
Pair programming P2 kinds of agile practices we propose.
development success
First, agile development practices,
Agility Customer such as pair programming and con-
satisfaction
Agile standards Software team tinuous code integration, provide
response P1
and norms guidelines for individuals to focus on
extensiveness
P4 Process software testing, simplifying code, or
Collective code performance
ownership enhancing code quality through peer
Software team
response efficiency review. Importantly, through these
Software mechanisms of self-control and auton-
functionality omy, these practices help to avoid or
Agile management
practices detect errors at an early stage of devel-
opment, which in turn frees capacity
P3
Stand-up meetings in the development process that would
otherwise be used for refactoring, bug
fixing, or code revision. The free capac-
ity, in turn, allows project members to
Figure 1: Research model.
develop more extensive responses to

PAPERS
customer change requests. We therefore We therefore propose a direct impact methodologically, theoretically, and
propose: on information systems development empirically. Methodologically, mea-
success: suring and testing hypotheses on all
P2: Development practices supporting the available agile practices would be
self-control and autonomy positively P4: Agile standards and norms enforcing a cumbersome effort, one that is bet-
affect software team response shared rituals and artifacts positively ter achieved programmatically through
extensiveness. affect information systems development replication (Berthon, Pitt, Ewing, &
success, but not software team response Carr, 2002) rather than in one study.
Agile management practices, such extensiveness or efficiency. Theoretically, describing the under-
as daily stand-up meetings (Schwaber lying rationale and justificatory logic
& Beedle, 2002) and small releases Together, these four propositions of orchestration for multiple practices
(Beck, 1999) specify rules and proce- allow for a meaningful evaluation of would be hard to achieve, whereas on a
dures, which prescribe behaviors and agile practices in terms of types and more abstract level (such as the one we
processes that must be followed. They effects. This is the core thesis of our propose), we can develop conceptual
therefore control how a software team model as shown in Figure 1: The agility logic that links differents practices to
reacts to changed requirements and of software teams in terms of response different mechanisms and in turn differ-
which procedures it follows in mak- extensiveness and response efficiency ent outcomes. Empirically, given that we
ing changes during development. will impact information systems devel- studied agile development in one orga-
For example, they stipulate how to opment success (P1). This has been nization as discussed following, we had
decide on how many of the features demonstrated before (e.g., Lee & Xia, to make compromises between exten-
in the product backlog to include in 2010; Sabherwal & Chan, 2001); how- siveness and measurement of study and
the next release. Feature-related deci- ever, now our model additionally pro- the constraints imposed on us by both
sions are commitments toward the poses that agility of the team can be the partner organization regarding sur-
responses to customer requirements influenced by the appropriate deploy- vey length and procedures as well as
changes. By forcing the team to criti- ment of specific kinds of agile practices. the particular practices employed in the
cally match available resources (time Management practices such as stand-up field situation.
and money) with customer requests, meetings or retrospectives and develop-
commitments become realistic and can ment practices such as pair program- Research Method
therefore be met more readily. A posi- ming or continuous code integration Field Study Design
tive effect will be more restrictive and impact the two orthogonal dimensions To evaluate our research model, we were
faster responses to change requests. of agility—response extensiveness (P2) faced with the choice of multiple case
We therefore propose: and response efficiency (P3)—but not studies, a cross-sectional survey across
both. On the other hand, agile standards information systems development proj-
P3: Management practices specifying rules and norms will not impact customer ects in multiple organizations, and an
and behavioral procedures positively responsiveness but will have a direct in-depth field study of agile develop-
affect software team response efficiency. impact on successful information sys- ment in one organization. We decided
tems development (P4). on the latter. Our motivation was three-
As a third kind of agile practice, we We make one note about our re fold: First, the literature reports mul-
examine agile standards and norms. search model. We deliberately con- tiple case studies and cross-sectional
During agile development, the responsi- structed it on an abstract, conceptual surveys on agile information systems
bility for delivered software code can be level, using propositions rather than development (Hummel et al., 2013) but
enforced using norms such as collective hypotheses. In turn, our definitions few field studies, which allowed us to
code ownership or coding standards. come with an inevitable “openness generate contrast in empirical insights.
Since these standards and norms relate of meaning” (Kaplan, 1998/1964, pp. Second, rather than collect data on the
to existing code—that is features of the 62–79). This means that we developed entire population under study as in a
product to be built—they do not directly propositions for evaluation about kinds cross-sectional design (that is, all teams,
relate to the team’s ability to respond to of development practices, management whether they use agile approaches or
customer requests extensively or effi- practices, and standards and norms in not), we wished to examine only indi-
ciently. Nonetheless, we expect posi- general, rather than precise hypoth- viduals with the specific characteris-
tive impacts on customer satisfaction eses about certain types of practices tic of using agile information systems
and technical software functional- (such as collective code ownership, development. This also offers the poten-
ity, for example, because of enforced pair programming, or refactoring) in tial of identifying potential confounding
responsibility for the delivered code. particular. Our rationale was motivated factors via the control variables. Finally,

the field study design offered us the concerning the introduction and use of This allowed us to gather reflective data
potential to confront our hypotheses agile information systems development on past and current projects and their
with a real world situation through the mainly concerned the project organiza- outcomes, in turn increasing the valid-
detailed study of a single organization. tion and management structure, which ity of the self-report measures for our
In turn, this move maximized ecologi- is still organized in a traditional way so dependent variable.
cal validity, which we believe is of par- that the employment of agile practices is The limitation that ensued was that
ticular importance given the industry sometimes hindered by the demand for we could not control for person–project
relevance and popularity of agile infor- delivering detailed documents such as relations. Still, this approach allowed
mation systems development. business plans and requirements speci- us to assume that respondents are well
In our field study, we surveyed proj- fications. The goal of the division is to aware of both (1) the agile practices
ect personnel working in agile software employ agile practices in more projects they actually used and (2) the actual
teams at a large international retailer in the foreseeable future. outcomes achieved in any of their past
that operates roughly 1,000 stores and projects in terms of how responses to
employs more than 180,000 people. The Procedures customer requests were handled and
large majority of stores in the retail We studied the rapid delivery program which development outcomes were
organization offer food, liquor, and in the retail organization. Our study achieved. Additionally, this procedure
general merchandise. The information spanned a period of eight months and allowed us (3) to align the causal logic
technology division in the organization included three points of measurement of our arguments (that practices influ-
is responsible for operations and the to be able to collect data near the begin- ence agility and in turn information
back office. It distinguishes between ning, middle, and end of agile devel- systems development success) with the
two types of information systems development projects. This procedure was temporal mechanisms of data collection
opment projects. Large projects are similar to that followed by Maruping, (in the sense that we first captured data
managed in a program called ‘strategic Venkatesh, and Agarwal (2009). on practices in use and later data on
delivery.’ Projects in this program are At the first point of measurement, we outcomes).
run in a more traditional, waterfall- distributed an online questionnaire to During each round, we sent out
type approach, whereas smaller proj- the software development department, reminders to increase the response
ects are managed in a program called in which we asked for demographics rate. Participants who filled out all three
‘rapid delivery,’ which follows agile and captured control variables such as questionnaires could win registration to
approaches. software team autonomy and diversity an agile conference and an iPad.
The information technology divi- (Lee & Xia, 2010). The second question- The online surveys were created
sion delivers two to three large projects naire was distributed three months later using the open source tool, LimeSur-
per year following traditional informa- to the people who completed the first vey. Management provided us with a
tion systems development approaches. questionnaire. In the second question- list of the 360 employees involved in the
Other, often smaller projects are man- naire, we captured responses about a information technology division and
aged using agile approaches by the varied set of agile practices in use dur- relevant product and customer depart-
rapid delivery team; this team deliv- ing the software development projects ments, including names and email
ers more than 10 small projects in a the respondents were currently involved addresses. The invitations for the survey
year. The main goal of introducing agile in. Lastly, we distributed the third ques- participation were sent out via emails,
approaches in the rapid delivery pro- tionnaire three months after the second which contained a personalized link
gram was to increase the delivery turn- questionnaire to all those who had com- for each employee. The personalized
around time for projects. pleted the first and second question- links allowed us to track the responses
In this division, the term agile infor- naires. In the third questionnaire, we of the same individual over the three
mation systems development is not captured responses about the outcomes measurement periods.
used as a reference to a specific agile of the projects they were involved in, The level of our research model
methodology; rather it is understood as well as the perceptions about team is the team level but operationally we
as the iterative delivery of working agility and cohesion during the course collected data from individuals. This
software and the frequent involvement of the project. Based on the discus- procedure was carried out in similar
of the customer throughout the project. sions with the partner organization, we studies with the intent to understand
Overall, the employees of the division assumed that participants of our study the behavior of a team by examining
consider their own maturity in agile as who work in the rapid delivery program data from individual team members
low to medium. Agile practices were should have delivered, on average, two (e.g., Guinan & Cooprider, 1998; Keil,
introduced in 2011 and have not been projects in the time span between the Rai, & Liu, 2012). Although we cannot
implemented in all projects. Challenges second and the third questionnaires. control for all subtle variations within

PAPERS
each team, we ensured that we exam- both of which reflective scales existed and team diversity (DIV) from Lee and
ined data only from those respondents (Maruping, Venkatesh, & Agarwal 2009; Xia (2010), as control variables. We
that were team members across all Maruping, Zhang, & Venkatesh 2009). decided to include these measures to
points of measurement. Agility was measured with the two allow us to compare our model with
scales for software team response exten- their model and a fully integrated
Measurement siveness (EXT) and efficiency (EFF) pro- model, as part of a post-hoc analysis of
In developing measurements to cap- vided by Lee and Xia (2010). our results.
ture data about our propositions, one Information systems development Appendix A lists all measures.
key decision for us was which type of success was operationalized as a Items were measured using 7-point
practice to capture to reflect on the second-order reflective construct with Likert scales, ranging from “Strongly
kind of practice our research model and three dimensions. First, we measured Disagree” to “Strongly Agree,” with three
propositions related to. The reason for the dimension “software functional- exceptions: software team response
thus is because, as indicated in Table 1, ity” (SF) reflectively as proposed by extensiveness (EXT) was measured
multiple types of practices could relate Lee and Xia (2010). Second, since we as ordinal percentage (from 0% to
to the three kinds of practices we dis- were not able to collect objective suc- 100%), which was transformed into a
tinguish, viz., management or develop- cess measures for the on-time and 6-point scale. Software team response
ment practices or agile standards and on-budget completion of the proj- efficiency (EFF) was measured on a
norms. In working with our partner ects, we decided to combine those two 7-point Likert scale, ranging from “Very
organization, however, it became clear dimensions in one perceptive measure little” to “Very much.” Like Lee and Xia
(1) that not all practices available in called “process performance” (PPF), (2010), we reversed the software team
textbooks were in use, and (2) that we as proposed by Wallace et al. (2004). response efficiency item scores for data
could not administer an extensive sur- Third, we included “customer satisfac- analysis such that higher scores indi-
vey that would allow us to measure all tion” (CSF) as a dimension of infor- cate higher response efficiency. Cus-
potential practices. mation systems development success tomer satisfaction (CSF) was measured
In deciding on our measurement because satisfying the customer is one on a 7-point semantic differential scale.
strategy, we therefore followed the fol- of the fundamental principles of agile We varied some scale labels in order to
lowing criteria in selecting specific agile information systems development, reduce the influence of the measure-
practices: as advocated in the Agile Manifesto ment instrument on the answers of the
(Fowler & Highsmith, 2001). Customer participants (Fowler, 2001). We worded
1. Coverage: We sought to examine prac- satisfaction was measured by adapting items in the first two questionnaires
tices across a range of popular meth- the reflective semantic differential scale such that they referred to the current
odologies, such as Scrum and Extreme by Bhattacherjee (2001). development project of the participants
Programming. We make two notes about this oper- (as proposed by Hsu, Lin, Cheng, &
2. Measurement: We sought to focus on ationalization of information systems Linden, 2012). The items of the last
practices with existing scales in the development success. First, it differs questionnaire referred to the comple-
academic literature rather than hav- on two counts according to Lee and tion of said development project so
ing to invent new measures. Xia (2010): (1) we operationalized two that we were able to capture the project
3. Relevance: The practices we focus of the success dimensions differently; outcome.
on are popular in use (VersionOne, and (2), because we had no access to
2015). objective data, we used only reflective Data Analysis
4. Access: We selected practices in use perceptual measures for each first-order Descriptive Statistics
at the partner organization. For exam- construct. Second, we did not measure Of the 102 participants who provided
ple, practices associated with Crystal information systems development suc- complete responses to the survey at
(Cockburn, 2001) were not in use. cess across a sum of projects; rather, measurement point 1, 79 participants
each individual rated the most recent responded to the second survey and
As a result, we selected the man- project he or she was involved in. This 71 responded to all three surveys,
agement practice “stand-up meeting” is an accepted and often used way of equaling an effective response rate of
(STM) and used an existing reflective measuring (Keil, Mann, & Rai, 2000; 19.7% and an overall attrition rate of
scale originally proposed by So and Nidumolu, 1995; Wallace, Keil, & Rai, 30.4%. Both the overall attrition rate and
Scholl (2009) for measurement. We 2004) and one we could agree on with pattern of attrition of 22.6% (between
selected the development practice “pair our partner organization. points 1 and 2) and 10.1% (between
programming” (PP) and the standard Finally, we decided to also include points 2 and 3) characterize our sam-
“collective code wwnership” (CCO), for the scales for team autonomy (AUTO) ple as consisting of “high lurkers”

(Lugtig, 2014) with declining yet stable
Individual Variables Results Project Variables Results
response patterns.
Experience in information systems development Team size
The average age of the participants
was 43 years and the average reported , 1 Year 0.0% 5 or less 9.9%
team size was 38. All main roles typi- , 1–2 Years 4.2% 6 to 10 21.1%
cally associated with agile information , 2–5 Years 8.5% 11 to 20 12.7%
systems development—namely devel-
, 5–10 Years 21.1% 21 to 50 12.7%
opers, product owners, and Scrum-
Masters—were well represented in our . 10 Years 31.0% More than 50 14.1%
sample. The product owner role is the Not specified 35.2% Not specified 29.6%
most frequently incorporated role of the Experience in agile information systems development Project domain
participants (22.5%), which is similar
, 1 Year 0.0% Retail 66.2%
to the reported occurrence of this role
in agile practitioner surveys (e.g., Kim, , 1–2 Years 22.5% Logistics 2.8%
2013, p. 3). Still, because the share of , 2–5 Years 18.3% Not specified 29.6%
product owners in our sample appeared , 5–10 Years 4.2%
high, we decided to check for response
. 10 Years 2.8%
bias between product owners and all
other roles. To that end, we compared Not specified 52.1%
latent variable scores for all constructs Project role
using an independent sample t-test. Product owner 22.5%
There were no significant differences Project manager 11.3%
between product owners and other
ScrumMaster 9.9%
respondents for any construct except
for software functionality (t 5 2.183, Quality assurance/testing 9.9%
p 5 0.032), which was evaluated higher Developer 8.5%
by product owners. This seems reason- Information technology manager 8.5%
able given that the role of the product
Architect 5.6%
owner is to assume content author-
ity; that is, as the key stakeholder the Agile coach 4.2%
product owner needs to have a vision Other 21.1%
of what he or she wishes to build and Table 2: Descriptive statistics of final survey sample.
convey that vision to the information
systems development team. Thus we
suggest that no substantial response First, we ran Harman’s One Factor Test. common method bias (Podsakoff et al.,
bias is present. The results of the principal component 2003).
As expected, the majority of par- analysis show that only 24.5% of the
ticipants were included in information variance is explained by one single fac- Measurement Validation
systems development projects for the tor, providing initial evidence that com- We analyzed the data using partial least
retail domain and most participants mon method bias is not an issue in squares analysis with SmartPLS (Ringle,
were highly experienced in informa- our data (Podsakoff, MacKenzie, Lee, & Wende, & Will, 2005). We evaluated
tion systems development. Table 2 sum- Podsakoff, 2003). Second, we used the established guidelines (Gefen, Rigdon,
marizes the selected descriptive data Marker-Variable Technique (Malhotra, & Straub, 2011; Goodhue, Lewis, &
about participants and projects. The Kim, & Patil, 2006). The results show Thompson, 2012; Hair, Hult, Ringle,
high number of unspecified answers that significant paths in the model with- & Sarstedt, 2014; Ringle, Sarstedt, &
likely resulted from participants being out the inclusion of the marker variable Straub, 2012) in order to decide whether
allowed not to answer demographic stay significant when the marker vari- to use partial least squares or
questions, which was a requirement able is included in the model, indicat- covariance-based structural equation
imposed on us by the partner organiza- ing that common method bias is not a modeling. Partial least squares model-
tion in order to decrease survey fatigue serious concern. Third, we separated ing is appropriate for analyzing our
by their employees. measurement by distributing three data because we needed to explore dif-
We evaluated the possibility of com- questionnaires at different points in ferent variants of our research model
mon method bias through three tests. time, thereby reducing the likelihood of in order to appropriately evaluate our

PAPERS
for items CCO1 and CCO3, which were

Cronbach’s Composite
Construct Alpha Reliability AVE Mean SD just below this threshold (Hair et al.,
2014). Loadings on the intended latent
Collective Code Ownership (CCO) 0.82 0.87 0.57 4.16 1.71
variable were also well above the cross-
Customer Satisfaction (CSF) 0.88 0.92 0.74 5.03 1.18 loadings on other variables (Straub
Software Team Response 0.92 0.94 0.73 3.32 1.51 et al., 2004). We conclude that indicator,
Extensiveness (EXT) convergent, and discriminant validity is
Software Team Response 0.89 0.92 0.65 3.46 1.66 sufficiently present in our data.
Efficiency (EFF) Finally, we examined the hierarchi-
Pair Programming (PP) 0.99 0.99 0.98 2.57 1.79 cal construct of information systems
development success, which we mod-
Process Performance (PPF) 0.94 0.97 0.94 4.23 1.94
eled as a reflective first-order, reflec-
Software Functionality (SF) 0.94 0.96 0.85 5.62 1.20 tive second-order construct. ISD
Stand-up Meeting (STM) 0.96 0.97 0.88 4.04 2.29 success is manifested by the dimen-
Note: AVE 5 Average Variance Extracted; SD 5 Standard Deviation sions of customer satisfaction, process
Table 3: Construct statistics. performance, and software functional-
ity, because for an information systems
development project to be successful,
propositions, for which an exploratory construct information systems develop- high values in all those three dimensions
approach to data analysis is preferred. ment success. are needed. We followed guidelines for
Also, partial least squares modeling is Table 3 summarizes the reliabil- evaluating hierarchical constructs in
especially suited for evaluating research ity, average variance extracted, mean, partial least squares modeling (Wright,
models with hierarchical constructs, and standard deviation of the latent Campbell, Thatcher, & Roberts, 2012):
which was the case in our setting variables. Table 4 summarizes con- First, we evaluated the measurement
(Wetzels, Odekerken-Schröder, & Van struct correlations and the evalua- model including only the first-order
Oppen, 2009). tion of the Fornell-Larcker criterion. constructs in order to ensure scale vali-
We modeled all scale items as reflec- Relevant thresholds for reliability and dation. Due to the uneven number of
tive indicators of their theorized latent discriminant validity are met (Fornell indicators of the first-order constructs,
construct. The measurement validation & Larcker, 1981; MacKenzie, Podsakoff, we used the standardized latent vari-
also includes the first-order constructs & Podsakoff, 2011; Straub, Boudreau, & able scores of each dimension as indi-
customer satisfaction, process per- Gefen, 2004). Table 5 shows the load- cators of the second-order construct in
formance, and software functionality, ings and cross-loadings of the latent order to evaluate the structural model
which serve as the basis for the struc- variables. Loadings on the designated and the explained variance.
tural evaluation of the second-order variables were higher than 0.7, except
Structural Model Evaluation
We estimated a structural model with
the view to evaluate the proposi-
Construct CCO CSF EFF EXT PP PPF SF STM tions in our conceptual model. To be
Collective code ownership (CCO) 0.75 faithful in our evaluation of the prop-
Customer satisfaction (CSF) 0.38 0.86 ositions, in estimating the structural
Software team response 0.10 0.14 0.81 model, we included all constructs from
efficiency (EFF) the research model and included asso-
Software team response 0.02 0.32 0.85 ciations between:
20.39
extensiveness (EXT)
1. the development practice (pair pro-
Pair programming (PP) 0.04 0.03 20.05 0.23 0.99 gramming), management practice
Process performance (PPF) 0.20 0.45 0.23 0.08 0.18 0.97 (stand-up meetings), and standards
Software functionality (SF) 0.34 0.75 0.24 0.12 0.02 0.54 0.92 and norms (collective code ownership)
to both software team response exten-
Stand-up meeting (STM) 0.48 0.11 20.01 20.13 0.28 0.13 0.4 0.94
siveness and efficiency;
Note: Diagonal elements represent the square root of the average variance extracted. Off-diagonal
2. the development practice (pair pro-
elements are the correlations among latent constructs.
gramming), management practice
Table 4: Construct correlations and Fornell-Larcker criterion analysis.
(stand-up meetings), and standards

Construct Item CCO CSF EFF EXT PP PPF SF STM
Collective code CCO1 0.620 0.156 0.155 20.030 20.113 0.045 0.083 0.321
ownership (CCO) CCO2 0.712 0.208 0.067 0.041 0.071 0.222 0.251
20.055
CCO3 0.683 0.182 0.212 20.030 20.001 0.133 0.123 0.315
CCO4 0.832 0.319 20.100 0.133 0.091 0.068 0.270 0.421
CCO5 0.872 0.408 0.170 20.046 0.058 0.283 0.407 0.438
Customer satisfaction (CSF) CSF1 0.351 0.859 0.127 0.244 0.015 0.524 0.813 0.149
CSF2 0.210 0.813 0.076 0.291 20.145 0.381 0.608 0.040
CSF3 0.358 0.899 0.123 0.261 0.096 0.371 0.610 0.069
CSF4 0.357 0.858 0.138 0.296 0.114 0.287 0.542 0.119
Software team response EFF1 0.030 0.128 0.784 20.298 0.128 0.195 0.154 0.042
efficiency (EFF) EFF2 0.026 0.044 0.831 0.224 0.169 0.029
20.425 20.168
EFF3 0.121 0.136 0.912 20.356 20.100 0.182 0.209 20.004
EFF4 0.022 20.018 0.676 20.176 0.113 0.232 0.092 20.024
EFF5 0.145 0.198 0.886 20.352 20.034 0.195 0.254 0.026
EFF6 0.128 0.124 0.725 20.212 20.103 0.106 0.229 20.147
Software team response EXT1 20.020 0.111 20.285 0.810 0.093 0.078 0.010 20.319
extensiveness (EXT) EXT2 0.195 0.874 0.295 0.030 0.058
20.001 20.344 20.122
EXT3 0.062 0.267 20.376 0.922 0.224 0.087 0.106 20.083
EXT4 0.118 0.352 20.242 0.793 0.129 0.048 0.220 20.024
EXT5 20.021 0.298 20.370 0.880 0.215 0.068 0.109 20.090
EXT6 20.038 0.377 20.342 0.827 0.189 0.072 0.121 20.059
Pair programming (PP) PP1 0.052 0.031 20.012 0.244 0.984 0.208 0.047 0.255
PP2 0.037 0.043 20.077 0.225 0.992 0.144 0.015 0.281
PP3 0.040 0.017 20.056 0.207 0.988 0.178 20.001 0.289
Process performance (PPF) PPF1 0.189 0.421 0.214 0.117 0.194 0.973 0.519 0.124
PPF2 0.191 0.461 0.235 0.023 0.154 0.966 0.531 0.129
Software functionality (SF) SF1 0.403 0.704 0.162 0.158 0.013 0.504 0.939 0.187
SF2 0.327 0.732 0.185 0.156 0.044 0.516 0.951 0.093
SF3 0.269 0.745 0.232 0.145 20.037 0.516 0.942 0.063
SF4 0.247 0.561 0.313 20.033 0.070 0.455 0.847 0.070
Stand-up meeting (STM) STM1 0.393 0.018 0.085 20.164 0.215 0.077 20.007 0.903
STM2 0.444 0.132 20.041 20.121 0.325 0.160 0.156 0.955
STM3 0.456 0.093 20.033 20.142 0.251 0.094 0.087 0.939
STM4 0.480 0.133 20.006 20.079 0.219 0.128 0.136 0.950
Table 5: Item cross-loadings.
and norms (collective code own- 3.

between software team response 30% of the variance in information sys-
ership), and both software team extensiveness and efficiency as pro- tems development success, and 11% and
response extensiveness and effi- posed by (Lee & Xia, 2010). 19% of software team response exten-
ciency to the reflective second order siveness and efficiency, respectively.
construct software development suc- The structural model results are Concerning the proposed relation-
cess; and shown in Figure 2. The model explains ships in the model, our data show that, as

PAPERS
Agile management Agility Information systems development success

practices 2
R = 0.11
Stand-up meeting –0.29** Software team

(STM) response
extensiveness (EXT)
0.14ns –0.44***
0.38*** Customer
satisfaction
Agile standards (CSF)
and norms 0.03ns 0.90***
R2 = 0.30
Collective code Information systems Process
0.30*** 0.33** 0.69***
ownership development success performance
(CCO) (ISDS) (PPF)
–0.19ns
0.03ns 0.91*** Software

functionality
0.34*** (SF)
Agile development 0.21ns
practices
Software team
response efficiency
Pair programming (EFF)
(PP)
0.10ns
R2 = 0.19
Note: ***p<0.01, **p<0.05, *p<0.1, dashed lines denote insignificant paths
Figure 2: Structural model results.
proposed by Lee and Xia (2010), software associated with either software team multicollinearity issues for our struc-
team response extensiveness and effi- response extensiveness or efficiency. tural model results. Concerning effect
ciency are both significantly associated Table 6 reports effect sizes (f2) and sizes: the effects from software team
with ISD success (b 5 0.38, p , 0.01 variance inflation factors (VIF) for all response extensiveness on software
for software team response extensive- exogenous constructs. All variance team response efficiency and software
ness and b 5 0.34, p , 0.01 for software inflation factors values are well below team response extensiveness on infor-
team response efficiency). The manage- the threshold of 5.0, indicating no mation systems development success are
ment practice stand-up meetings was
negatively associated with software team
response extensiveness (b 5 20.29,
Variable EXT EFF Information Systems Development Success
p , 0.05) and not significantly related to
CCO 0.016 0.041 0.111
either software team response efficiency
or information systems development (1.303) (1.323) (1.377)
success. Conversely, the development PP 0.094 0.009 0.001
practice pair programming was positively (1.095) (1.197) (1.209)
associated with software team response
STM 0.066 0.029 0.001
extensiveness (b 5 0.30, p , 0.01) and
not significantly related to either software (1.407) (1.499) (1.543)
team response efficiency or information EXT 0.211 0.150
systems development success. Finally, (1.124) (1.361)
the standards and norms collective code EFF 0.133
ownership was positively related to infor-
(1.235)
mation systems development success
Table 6: Effect sizes (variance inflation factors) for exogenous constructs.
(b 5 0.33, p , 0.05) but not significantly

medium, whereas the effects from pair
CCO EFF EXT ISDS PP STM
programming and stand-up meetings
CCO 0.209 0.135 0.326
on software team response efficiency
and from collective code ownership on EFF 20.337
information systems development suc- EXT 20.438 0.376
cess are small. The effect of software ISDS
team response efficiency on information
PP 0.095 0.302 0.026
systems development success, too, is
small (but at the upper range). STM 20.189 20.287 0.032
Table 7: Path coefficients in model with mediator (software team response efficiency) in
Post-hoc Analyses the model.
We performed several post-hoc analy-
ses to examine the robustness of our 2. Variations in the mediator account the mediator (software team response
results. First, we decomposed infor- significantly for the variations in the efficiency) explains a large share of
mation systems development success dependent variable (information sys- the effect from software team response
into its three constituent dimensions tems development success), which is extensiveness on information systems
and re-estimated the structural model. given in our model. development success. Furthermore, the
Appendix B provides details of this anal- 3. When paths between the indepen- variance accounted for statistic (21.598)
ysis. The results are comparable with dent variable (software team response for the construct software team response
those illustrated in Figure 2. extensiveness) and mediator (soft- efficiency is negative, which classifies
Second, we compared our model ware team response efficiency) and the type of mediation as a full mediation
with two alternative conceptualizations: between the mediator (software team effect (Hair et al., 2014, p. 225).
(1) the model by Lee and Xia (2010), response efficiency) and dependent
which we replicated with our data; and variable (information systems devel- Discussion
(2) an integrated model that adds to opment success) are controlled, a pre- Summary of Findings
our model the team characteristics viously significant relation between the Table 9 summarizes the insights gained
autonomy and diversity from Lee and independent (software team response from our propositions and summarizes
Xia (2010). Appendix C provides these extensiveness) and dependent vari- our interpretations; in turn, we discuss
details; again, we find that our results are ables (information systems devel- the notable findings.
robust against these additional analyses. opment success) changes its value Regarding Proposition P1, our
Third, we carried out a mediation significantly. This is the case for our research confirms that agility is an
analysis to better understand the results model, because we have a change from important predictor of information sys-
we obtained about the relation between the model with mediator in the path tems development success and thereby
software team response extensiveness coefficient for software team response corroborates the findings by Xia and Lee
and efficiency to information systems extensiveness 2. information sys- (2010); like them we found that exten-
development success. Specifically, we tems development success, from 0.376 sive responses to changing customer
were interested in ascertaining whether down to 0.240 in the model without the requirements induces lowered response
and how the construct software team mediator (see bold and underscored efficiency, suggesting that extensive
response efficiency mediates the rela- numbers in Tables 7 and 8). responses require additional response
tion between the constructs software efforts, which decreases response effi-
team response extensiveness and infor- We interpret these results as a strong ciency. Moreover, same as Xia and Lee
mation systems development success. indicator for mediation. In other words, (2010), we also found that software team
Tables 7 and 8 summarize the results
from this analysis. A variable functions
CCO EXT ISDS PP STM
as a mediator when it meets three con-
ditions (Baron & Kenny, 1986): CCO 0.151 0.401
EXT 0.240
1. Variations in the independent variable ISDS
(software team response extensiveness)
PP 0.300 0.049
account significantly for variations in
STM 20.294 20.031
the presumed mediator (software team
response efficiency), which is given in Table 8: Path coefficients in model without mediator (software team response efficiency) in
the model.
our model.

PAPERS
practices. Software teams enact specific

No Relevant Empirical Results Interpretation
practices; in so far, both groups (their
P1 Software team response extensiveness Agility is an important predictor of information
characteristics) and their behaviors (the
is significantly positively related to systems development success, both in terms
practices they use) are important and
information systems development success. of responding extensively and efficiently
Software team response efficiency to customer requirements. These results inter-dependent components of agil-
is significantly positively related to corroborate those of Lee and Xia (2010). ity. At the same time, our findings indi-
information systems development success. cate that the existing models are not
perfect, with overall medium variance
P2 Pair programming is significantly positively Pair programming in agile development is
related to software team response important to ensure good quality in software explained and not being completely rep-
extensiveness; it is not significantly development, in turn allowing the team to licable; other theories might be needed
related to customer response efficiency or respond broadly and comprehensively to to understand and provide support for
information systems development success. inquiries. the effects of agility in information sys-
P3 Stand-up meetings are significantly Stand-up meetings reduce a team’s ability to tems development.
negatively related to software team respond broadly and comprehensively. Their Abrahamsson, Conboy, and Xiaofeng
response extensiveness. They are not influence on efficiency is mediated through (2009) stressed the need to understand
significantly related to software team response extensiveness. what constitutes agility. While on the
response efficiency or information surface we replicate the importance of
systems development success. software team response effectiveness
P4 Collective code ownership is significantly Collective code ownership does not affect and software team response efficiency
positively related to information systems a team’s ability to respond to customer to agility, we also go a step further than
development success but not to agility. requirements changes. Xia and Lee (2010). They considered
Table 9: Findings about propositions. software team response effectiveness
and efficiency to be similar or nearly
identical dimensions of agility, whereas
response efficiency contributes to pro- whether or not a team responds effec- we show that they are affected differently
cess performance, customer satisfaction, tively or efficienctly. Development prac- by agile practices. This finding leads to
and software functionality, which is par- tices (viz., pair programming), on the new research questions. For example,
ticularly noteworthy because we used other hand, directly impact the range of using Conboy’s (2009) taxonomy of agil-
different scales to measure information response of a software team to customer ity, only one of his categories—rapid
systems development success. Xia and requirements because they provide local change—is covered by software team
Lee (2010) report positive relations from best practices that can optimize the out- response efficiency and extensiveness.
additional efforts for response efficiency put created during development work. This suggests that future research needs
to on-time completion, on-budget com- Management practices, finally, inhibit to address the other categories of Con-
pletion, and software functionality, and the range of responses, and in doing so boy’s (2009) taxonomy—for example,
we now find that similar positive flow on indirectly improve response efficiency. economy, quality, simplicity, or learn-
effects accrue for process performance As for the specific practice of stand-up ing from change—to examine which
and customer satisfaction. meetings, this may depend on whether other constituent elements form the
Regarding propositions P2 through the customer or product owner is part agility of software teams.
P4, our data suggest that different kinds of the daily meetings. If not, team meet- A second line of research could
of agile practices impact agility, and in ings take time away from discussions expand on our empirical design, for
turn ISD success, in different ways. We for clarifying requirements with custom- example, by studying compare software
find that standards and norms (viz., col- ers or product owners, speeding up the team responsiveness and efficiency
lective code ownership) are important response process. across projects, and identify improve-
direct antecedents of successful informa- ments or decline in them over time. This
tion systems development but they do not Implications for Research includes studies under which conditions
influence how software teams respond to Our research provides a rationale for and goals with which teams, customers,
customer requirements. This is because how and why selected used agile prac- and practices; and what detrimental
standards and norms enforce a group tices relate to successful information or advantageous effects on software
behavioral culture, which is character- systems development projects. In doing response effectiveness and efficiency
ized by group members agreeing on ways so, we believe our work extends on are obtainable. A further step would
of working. Yet, they do not influence or the previous studies on team charac- then link them to information systems
prescribe outcomes of such shared rou- teristics as antecedents to agility. We development success. This could be
tines and rituals, and thus do not impact extend this research with a focus on expanded to a contingency model of

agile information systems development we need to explore which facets (Sarker, Our results on the impact of soft-
and to a configuration inventory, which Munson, Sarker, & Chakraborty, 2009), ware team response efficiency and soft-
specifies a “fit” between specific infor- components (Conboy, 2009), or patterns ware team response extensiveness on
mation systems development situations (Baskerville, Pries-Heje, & Madsen, 2011) information systems development suc-
and corresponding agile practices. This of agility are affected by which practice cess reiterate further that focusing only
also includes a comparison of using sets. on quick and rapid changes may not
different agile practices in different set- We also showed that different prac- yield desirable results for agile proj-
tings (e.g., such as co-located versus tices provide different effects on agility ects, which reinforces the adage that
distributed, Sarker & Sarker, 2009). and the outcomes of information sys- agile development should not neces-
There are also interesting implica- tems development. Our findings sug- sarily mean fast development. When
tions for theory that follow from our pro- gest that management and development software teams focus on expanding
posed categorization of agile practices practice practices have divergent but the range and comprehensiveness of
into three distinct sets: management not necessarily opposite effects on agil- their responses, their ability to respond
practices, development practices, and ity, and they highlight the core roles of as quickly as possible diminishes, but
standards and norms. Our empirical standards and norms to successful out- the implications for success increase.
data suggest that practices are indeed a comes. Future research should investi- Information systems development team
core component driving agility in infor- gate the effect of practices other than the members need to be incentivized to not
mation systems development and may ones we studied, both in isolation and in just respond as quickly as possible, but
be equally, or even more, essential and combined use settings. For example, to respond reasonably quickly and with
vital than teams and their members’ stand-up meetings should be examined enough detail and understanding of the
characteristics (which is backed by our in combination with other practices situation, domain, and problem at hand.
comparisons of different models in such as having an onsite customer. A final implication here is that orga-
Appendix C): Good developers or good nizations should prioritize software team
teams may well be necessary for agility Implications for Agile Development response extensiveness through practices
and information systems development Projects in Particular such as pair programming, and closely
success, but good teams using suitable For practitioners, our findings help monitor their use of management prac-
practices are even better. This finding to take the first steps in answering an tices, such as daily stand-ups, so as not
can now provide the impetus for sev- important question: Which agile prac- to reduce their response extensiveness.
eral studies: for example, a future study tices from which available methodolo-
might elaborate on the fit between situ- gies should be employed in information Implications for Project Management
ational characteristics and suitability of systems development projects? Our in General
agile practices. The important part here results suggest that the answer is contin- As was the case in our study, much of
may be that agile information systems gent on the goals: If the goal is to directly the research on agile projects focuses
development teams take charge of their improve information systems develop- on information systems development
own ways of working and select the ment success without caring about agile and software development initiatives or
practices that benefit them the most. behavior and without any changes in industries (e.g., Qumer & Henderson-
Another direction for future work may team behavior or composition, stan- Sellers, 2008; Wells, 2012). Still, there is
stem from a need for further theorizing: dards and norms such as collective code also evidence to suggest that agile meth-
The empirical differences we uncovered ownership can help to generate success- ods can be of benefit to project man-
may require new theories that explain ful outcomes without affecting software agement in general (Conforto, Salum,
the effect of different practices. For team responsiveness at all. By con- Amaral, da Silva, & de Almeida, 2014).
example, models of group behavior or trast, if long-term changes are possible, For instance, startup companies or ven-
team work mechanisms (Ilgen, Hollen- agile management practices and agile ture companies often use agile practices
beck, Johnson, & Jundt, 2005; Kozlowski development practices provide an abil- to structure daily work processes besides
& Ilgen, 2006) might be suitable for ity to direct teams’ abilities to respond software development (Sutherland &
investigating the effect of management to customers efficiently or effectively, Altman, 2009; 2010). This also leads to
practices rather than development prac- thereby improving agility, which in turn, combining agile practices from Scrum
tice practices, whereas theories build- provides management interventions to with lean management practices from
ing on models of self-regulation and positively affect information systems Kanban (Wang et al., 2012), and many
self-organization (Karhatsu, Ikonen, development success. In addition, the practices of agile information systems
Kettunen, Fagerholm, & Abrahamsson, choice of agile practices may be more development are similar to their coun-
2010; Varela, 1984) may be more salient for practitioners than attempting terparts in lean operations management,
appropriate for the latter. Similarly, to “configure” their teams. which are increasingly also adopted for

PAPERS
project management. Moreover, agile contributing to software teams. The upside robust against variations in measure-
information systems development meth- of this approach is that we can collect ment of the dependent variable. Our
ods such as Scrum have their roots in data on experiences accrued from more approach to data collection is also sus-
new product (non-software) develop- than one project, as done, for example, by ceptible to common method bias; yet
ment (Takeuch & Nonaka, 1986), and are Lee and Xia (2010). Still, more research we conducted several tests and found no
not necessarily specific for the software is encouraged to increase the validity of indication that systematic bias is pres-
industry. Our findings should therefore our results by replicating our study on the ent. Fourth, we collected data from the
be transferable, at least to some degree, to team level rather than the individual level. agile development efforts from one large
other (non-software) projects in general. Second, due to the restrictions of organization. Our findings and their
For example, the use of standards our field study regarding survey length, interpretations are thus bounded to the
and norms is advisable in every kind we operationalized agile management single industry (retail) and organization
of project. Management practices, such practices, development practices, and (large) that we studied. However, we
as stand-up meetings, can be employed standards and norms only with one note that our dataset is also original in
independently of whether or not the construct each. In turn, the interpreta- that most other studies consider cross-
product is software. Development prac- tions of our findings in relation to the sectional data from efforts across many
tices, such as pair programming, can be propositions about the kinds of prac- organizations and heterogeneous teams.
translated to a general project practice to tices (development versus management
work in pairs on complex tasks and prob- practices versus standards) are empiri- Conclusion
lems (e.g., creative tasks such as ideation). cally bounded by the types of practices Selecting the right practices from a portfo-
However, not every kind of project in any we collected data on (pair program- lio of methodologies remains a challenge
situation or domain aims at team respon- ming, stand-up meetings, and collec- for most organizations trying to become
siveness (e.g., initiatives in the military tive code ownership). Interpretations of more agile. With this study we sought to
sector in other kinds of mission-critical our results thus need to consider these extend our understanding of agile prac-
projects). Therefore, the effects of adopt- boundary conditions. Ideally, future tices use and their effects on successful
ing practices from information systems studies will replicate our work and con- software development. We showed that
development, such as stand-up meetings, sider and measure other types of prac- different practices impact agile teams in
to other kinds of projects with other goals tices indicative of the kinds of practices terms of extensive or efficient customer
need to be evaluated carefully. This chal- we theorized about. For instance, other responses in different ways and, ultimately
lenge, in turn, may open up directions popular management practices include contribute to successful software develop-
for future research on the use of agile retrospectives or small releases. Popular ment in different ways. While this finding is
practices in the management of projects development practices include refac- interesting in its own right, it also generates
in general (e.g., studies investigating the toring or continuous code integration. a new question about the relation between
diffusion and adoption of agile practices Finally, there are other agile norms such the technical and the social in agile devel-
in more general project settings). as coding standards. Williams (2012) opment: Is the team (the structure) more
provides an overview of different prac- important or the methodological choice of
Limitations tices and their discussion in the lit- practices (the tasks and technology)? The
Our research has several limitations. First, erature. We tried to alleviate a potential question is not conclusively answered by
we were not able to conduct our study lack of external validity by examining our research but it serves well as impetus
on the team level; instead, we collected popular practices across a wide range to stimulate further inquiry.
data by individuals about the teams and of methodologies rather than just
projects they are involved in. While this focusing on one specific methodology Acknowledgments
approach is common (Keil et al., 2000; (e.g., Maruping, Venkatesh, & Agarwal, We would like to thank the case orga-
Nidumolu, 1995; Wallace et al., 2004), we 2009; Moe, Dingsøyr, & Dybå, 2010) or nization for providing access to their
cannot use it to evaluate the relation- just one practice (e.g., Balijepally et al., development teams. Dr. Recker’s con-
ships between respondents and projects, 2009; Cockburn & Williams, 2001). tributions were partially supported by
or respondents and teams. Therefore, our Third, we were only able to collect a grant from the Australian Research
findings about information systems devel- perceptual measures, Which notably Council (DP160103407). Dr. Rosen-
opment success should not be interpreted impacted our conceptualization of infor- kranz’s contributions were supported
as the emergent properties of information mation systems development success, by a grant from the German Research
systems development projects or software and as discussed, deviated somewhat Foundation (DFG) under record no. RO
teams, rather as the reported experiences from that of Lee and Xia (2010). This also 3650/8-1. Aside from the first author,
of agile practitioners involved in informa- allowed us, however, to corroborate the author names are ordered alphabeti-
tion systems development projects and existing theory by showing it remains cally irrespective of contribution.

References Bhattacherjee, A. (2001). Understanding development, and extreme programming:
Abrahamsson, P., Conboy, K., & information systems continuance: An The state of research. Journal of Database
Xiaofeng, W. (2009). ’Lots done, more expectation-confirmation model. MIS Management, 16(4), 88–100.
to do:’ The current state of agile systems Quarterly, 25(3), 351–370. Fitzgerald, B. (1997). The use of systems
development research. European Journal Boehm, B. W. (2002). Software development methodologies in practice:
of Information Systems, 281–284. engineering economics. In M. Broy & A field study. Information Systems
Abrahamsson, P., Salo, O., Ronkainen, E. Denert (Eds.), Software pioneers: Journal, 7(3), 201–212.
J., & Warsta, J. (2002). Agile software Contributions to software engineering Fitzgerald, B., Hartnett, G., & Conboy,
development methods: Review and (pp. 641 686). New York, NY: Springer. K. (2006). Customising agile methods
analysis. Oulu, Finland: VTT Electronics. Bostrom, R. P., Gupta, S., & Thomas, D. M. to software practices at Intel Shannon.
Ågerfalk, P. J., Fitzgerald, B., & Slaughter, (2009). A meta-theory for understanding European Journal of Information Systems,
S. A. (2009). Flexible and distributed information systems within sociotechnical 15(2), 200–213.
information systems development: State of systems. Journal of Management Fornell, C., & Larcker, D. F. (1981).
the art and research challenges. Information Information Systems, 26(1), 17–47. Evaluating structural equations
Systems Research, 20(3), 317–328. Bourque, P., & Fairley, R. E. (2014). with unobservable variables and
Balijepally, V., Mahapatra, R., Nerur, S., & Guide to the software engineering body measurement error. Journal of Marketing
Price, K. H. (2009). Are two heads better of knowledge (SWEBOK): Version 3.0. Research, 18(1), 39–50.
than one for software development? The Piscataway, NJ: IEEE Computer Society Fowler, F. J. (2001). Survey research methods
productivity paradox of pair programming. Press. (3rd ed.). Thousand Oaks, CA: Sage.
MIS Quarterly, 33(1), 91–118. Cockburn, A. (2001). Crystal clear: A Fowler, M., & Highsmith, J. (2001). The
Barki, H., & Hartwick, J. (2001). human-powered software development agile manifesto. Software Development,
Interpersonal conflict and its management methodology for small teams. Reading, 9(8), 28–32.
in information system development. MIS MA: Addison-Wesley.
Gefen, D., Rigdon, E. E., & Straub, D. W.
Quarterly, 25(2), 195–228. Cockburn, A., & Williams, L. (2001). The (2011). An update and extension to SEM
Baron, R. M., & Kenny, D. A. (1986). The costs and benefits of pair programming. guidelines for administrative and social
moderator–mediator variable distinction In G. Succi & M. Marchesi (Eds.), Extreme science research. MIS Quarterly, 35(2),
in social psychological research: programming examined (pp. 223–243). iii–xiv.
Conceptual, strategic, and statistical Boston, MA: Addison-Wesley.
Goodhue, D. L., Lewis, W., & Thompson,
considerations. Journal of Personality Cohen, S. G., & Bailey, D. E. (1997). R. L. (2012). Comparing PLS to
and Social Psychology, 51(6), 1173. What makes teams work: Group regression and LISREL: A response to
Baskerville, R., Pries-Heje, J., & Madsen, effectiveness research from the shop Marcoulides, Chin, and Saunders. MIS
S. (2011). Post-agility: What follows a floor to the executive suite. Journal of Quarterly, 36(3), 703–716.
decade of agility? Information & Software Management, 23(3), 239–290.
Guinan, P. J., & Cooprider, J. G. (1998).
Technology, 53(5), 543–555. Conboy, K. (2009). Agility from first Enabling software development team
Beck, K. (1999). Extreme programming principles: Reconstructing the concept performance during requirements
explained: Embrace change. Boston, MA: of agility in information systems definition: A behavioral versus technical
Addison-Wesley. development. Information Systems approach. Information Systems Research,
Research, 20(3), 329–354. 9(2), 101–125.
Berente, N., Hansen, S. W., &
Rosenkranz, C. (2015). Rule formation Conforto, E. C., Salum, F., Amaral, D. Hair, J. F., Hult, G. T. M., Ringle, C.
and change in information systems C., da Silva, S. L., & de Almeida, L. F. M. M., & Sarstedt, M. (2014). A primer on
development: How institutional logics (2014). Can agile project management partial least squares structural equation
shape ISD practices and processes. be adopted by industries other modeling (PLS-SEM). Thousand Oaks,
Paper presented at the 48th Hawaii than software development? Project CA: SAGE Publications.
International Conference on System Management Journal, 45(3), 21–34.
Hazzan, O., & Dubinsky, Y. (2003).
Sciences (HICSS 2015), Kauai, Hawaii. Dingsøyr, T., Nerur, S., Balijepally, V., Bridging cognitive and social chasms
Berthon, P., Pitt, L., Ewing, M., & Carr, & Moe, N. B. (2012). A decade of agile in software development using extreme
C. L. (2002). Potential research space methodologies: Towards explaining agile programming. In M. Marchesi & G. Succi
in MIS: A framework for envisioning software development. Journal of Systems (Eds.), Extreme programming and agile
and evaluating research replication, and Software, 85(6), 1213–1221. processes in software engineering–XP2002
extension and generation. Information Erickson, J., Lyytinen, K., & Siau, K. (Vol. 2675, pp. 47–53). Genova, Italy:
Systems Research, 13(4), 416–427. (2005). Agile modeling, agile software Springer.

PAPERS
Hsu, J. S.-C., Lin, T.-C., Cheng, K.-T., and%20PDFs/State%20of%20Scrum/2013- Moe, N. B., Dingsøyr, T., & Dybå,
& Linden, L. P. (2012). Reducing State-of-Scrum-Report_062713_final.pdf T. (2010). A teamwork model for
requirement incorrectness and coping Kirsch, L. J. (1996). The management understanding an agile team: A case
with its negative impact in information of complex tasks in organizations: study of a scrum project. Information
system development projects. Decision Controlling the systems development and Software Technology, 52(5), 480–491.
Sciences, 43(5), 929–955. process. Organization Science, 7(1), 1–21. Nidumolu, S. R. (1995). The effect of
Hummel, M., Rosenkranz, C., & Holten, Kozlowski, S. W. J., & Ilgen, D. R. (2006). coordination and uncertainty on software
R. (2013). The role of communication in Enhancing the effectiveness of work project performance: Residual performance
agile systems development: An analysis of groups and teams. Psychological Science risk as an intervening variable. Information
the state of the art. Business & Information in the Public Interest, 7(3), 77–124. doi: Systems Research, 6(3), 191–219.
Systems Engineering, 5(5), 343–355. 10.1111/j.1529-1006.2006.00030.x Pikkarainen, M., Haikara, J., Salo, O.,
Iivari, J., & Iivari, N. (2011). The Lee, G., & Xia, W. (2010). Toward agile: Abrahamsson, P., & Still, J. (2008). The
relationship between organizational An integrated analysis of quantitative impact of agile practices on communication
culture and the deployment of agile and qualitative field data on software in software development. Empirical
methods. Information and Software development agility. MIS Quarterly, Software Engineering, 13(3), 303–337.
Technology, 53(5), 509–520. 34(1), 87–114. Podsakoff, P. M., MacKenzie, S. B., Lee,
Ilgen, D. R., Hollenbeck, J. R., Johnson, M., Lugtig, P. (2014). Panel attrition: J.-Y., & Podsakoff, N. P. (2003). Common
& Jundt, D. (2005). Teams in organizations: Separating stayers, fast attriters, gradual method bias in behavioral research:
From input-process-output models to attriters, and lurkers. Sociological A critical review of the literature and
IMOI models. Annual Review of Psychology, Methods and Research, 43(4), 699–723. recommended remedies. Journal of
56(1), 517–543. doi: doi:10.1146/annurev MacCormack, A., Verganti, R., & Applied Psychology, 88(5), 879–903.
.psych.56.091103.070250 Iansiti, M. (2001). Developing products Qumer, A., & Henderson-Sellers, B.
Jacobson, I., Ng, P.-W., McMahon, P., on “Internet Time:” The anatomy (2008). An evaluation of the degree
Spence, I., & Lidman, S. (2012). The of a flexible development process. of agility in six agile methods and its
essence of software engineering: The Management Science, 47(1), 133–150. applicability for method engineering.
SEMAT kernel. Queue, 10(10), 40. MacKenzie, S. B., Podsakoff, P. M., Information and Software Technology,
Kaplan, A. (1998/1964). The conduct of & Podsakoff, N. P. (2011). Construct 50(4), 280–295.
inquiry: Methodology for behavioral science. measurement and validation procedures Ringle, C. M., Sarstedt, M., & Straub,
Piscataway, NJ: Transaction Publishers. in MIS and behavioral research: D. W. (2012). Editor’s comments: A
Karhatsu, H., Ikonen, M., Kettunen, P., Integrating new and existing techniques. critical look at the use of PLS-SEM in MIS
Fagerholm, F., & Abrahamsson, P. (2010, MIS Quarterly, 35(2), 293–334. Quarterly. MIS Quarterly, 36(1), iii–xiv.
3–5 Oct. 2010). Building blocks for self- Malhotra, N. K., Kim, S. S., & Patil, A. Ringle, C. M., Wende, S., & Will, A.
organizing software development teams (2006). Common method variance in IS (2005). SmartPLS 2.0. Retrieved from
a framework model and empirical pilot research: A comparison of alternative http://www.smartpls.de
study. Paper presented at the International approaches and a reanalysis of past Sabherwal, R., & Chan, Y. E. (2001).
Conference on Software Technology and research. Management Science, 52(12), Alignment between business and IS
Engineering, San Juan, Puerto Rico. 1865–1883. strategies: A study of prospectors,
Keil, M., Mann, J., & Rai, A. (2000). Why Maruping, L. M., Venkatesh, V., & analyzers, and defenders. Information
software projects escalate: An empirical Agarwal, R. (2009). A control theory Systems Research, 12(1), 11–33.
analysis and test of four theoretical perspective on agile methodology use and Sarker, S., Munson, C. L., Sarker, S., &
models. MIS Quarterly, 24(4), 631–664. changing user requirements. Information Chakraborty, S. (2009). Assessing the
Keil, M., Rai, A., & Liu, S. (2012). How Systems Research, 20(3), 377–399. relative contribution of the facets of agility
user risk and requirements risk moderate Maruping, L. M., Zhang, X., & Venkatesh, to distributed systems development
the effects of formal and informal control V. (2009). Role of collective ownership and success: An analytic hierarchy process
on the process performance of it projects. coding standards in coordinating expertise approach. European Journal of
European Journal of Information Systems, in software project teams. European Journal Information Systems, 18(4), 285–299.
22(6), 650–672. of Information Systems, 18(4), 355–371. Sarker, S., & Sarker, S. (2009). Exploring
Kim, D. (2013). The state of Scrum: McHugh, O., Conboy, K., & Lang, M. agility in distributed information systems
Benchmarks and guidelines. Retrieved from (2014). Agile practices: The impact on development teams: An interpretive study
https://www.scrumalliance.org/scrum/ trust in software project teams. IEEE in an offshoring context. Information
media/ScrumAllianceMedia/Files%20 Software, 29(3), 71–76. Systems Research, 20(3), 440–461.

Schwaber, K., & Beedle, M. (2002). Agile Vidgen, R., & Wang, X. (2009). Coevolving equation modeling: Recommendations
software development with Scrum. Upper systems and the organization of agile for IS research. Communications of the
Saddle River, NJ: Prentice Hall. software development. Information Association for Information Systems,
Serrador, P., & Pinto, J. K. (2015). Does Systems Research, 20(3), 355–376. 30(23), 367–412.
agile work? A quantitative analysis of Wallace, L., & Keil, M. (2004). Software Xiaohu, Y., Xu, B., He, Z., & Maddineni,
agile project success. International projects risks and their effect on outcomes. S. R. (2004). Extreme programming
Journal of Project Management, 33(5), Communications of the ACM, 47(4), 68–73. in global software development. Paper
1040–1051. Wallace, L., Keil, M., & Rai, A. (2004). presented at the Canadian Conference
Siau, K., Long, Y., & Ling, M. (2010). Understanding software project risk: on Electrical and Computer Engineering,
Toward a unified model of information A cluster analysis. Information & Niagara Falls, Canada.
systems development success. Journal of Management, 42(1), 115–125.
Database Management, 21(1), 80–101. Wang, X., Conboy, K., & Cawley, O.
Jan Recker, PhD, is Professor in the QUT Business
So, C., & Scholl, W. (2009). Perceptive (2012). “Leagile" software development:
School at Queensland University of Technology,
agile measurement: New instruments An experience report analysis of the
Brisbane, Australia. His research focuses on process
for quantitative studies in the pursuit application of lean approaches in agile
analysis and design, digital innovation, and environ-
of the social-psychological effect of software development. Journal of Systems
mental sustainability. He has published in the MIS
agile practices. In P. Abrahamsson, and Software, 85(6), 1287–1299.
Quarterly, Journal of the Association for Information
M. Marchesi & F. Maurer (Eds.), Agile Weitzel, J. R., & Graen, G. B. (1989). Systems, Information Systems Journal, Academy of
processes in software engineering and System development project Management Discoveries, and elsewhere. He can be
extreme programming-XP2009 (Vol. 31, effectiveness: Problem-solving contacted at j.recker@qut.edu.au
pp. 83–93). Pula, Italy: Springer. competence as a moderator variable.
Straub, D. W., Boudreau, M.-C., Decision Sciences, 20(3), 507–531. Roland Holten, PhD, is Professor in the Faculty of
& Gefen, D. (2004). Validation Wells, H. (2012). How effective are Economics and Business Administration, Institute for
guidelines for IS positivist research. project management methodologies? An Business Informatics at Goethe University, Frankfurt,
Communications of the Association for explorative evaluation of their benefits Germany. His research focuses on communication
Information Systems, 13(24), 380–427. in practice. Project Management Journal, structures of groups and information systems engi-
Sutherland, J., & Altman, I. (2009, 24–28 43(6), 43–58. neering. He has published in the European Journal of
August. 2009). Take no prisoners: How a Wetzels, M., Odekerken-Schröder, G., Information Systems, Information Systems Journal,
venture capital group does Scrum. Paper & Van Oppen, C. (2009). Using PLS Journal of Information Technology, Journal of the
presented at the Agile Conference, 2009. path modeling for assessing hierarchical Association for Information Systems, and elsewhere.
AGILE ’09, Chicago, Illinois. construct models: Guidelines and empirical He can be contacted at holten@wiwi.uni-frankfurt.de
Sutherland, J., & Altman, I. (2010). illustration. MIS Quarterly, 33(1), 177–195.
Organizational transformation with Markus Hummel, PhD, is senior business IT con-
Whitworth, E., & Biddle, R. (2007).
Scrum: How a venture capital group gets sultant with Senacor Technologies AG. He received
Motivation and cohesion in agile teams.
twice as much done with half the work. a doctoral degree from Goethe University, Frankfurt,
Paper presented at the 8th International
Paper presented at the 43rd Hawaii Germany. His research focuses on agile information
Conference on Agile Processes in
International Conference on System systems development. He has published articles
Software Engineering and Extreme
Sciences, Honolulu, Hawaii. in such publications as Communications of the
Programming, Como, Italy.
Association for Information Systems and Business
Takeuch, H., & Nonaka, I. (1986). Williams, L. (2012). What agile
& Information Systems Engineering. He can be
The new new product development teams think of agile principles.
contacted at Markus.Hummel@senacor.com
game. Harvard Business Review, 64(1), Communications of the ACM, 55(4),
137–146. 71–76. doi: 10.1145/2133806.2133823
Christoph Rosenkranz, PhD, is Professor in the Faculty
Varela, F. J. (1984). Two principles of Winter, S., Berente, N., Howison, of Economics, Management and Social Sciences at the
self-organization. In H. Ulrich & G. J., & Butler, B. S. (2014). Beyond University of Cologne, Cologne, Germany. His research
J. B. Probst (Eds.), Self-organization the organizational ‘container:’ focuses on business process management, information
and management of social systems Conceptualizing 21st century systems development, and IT project management. He
(pp. 25–32). New York, NY: Springer. sociotechnical work. Information and has published articles in publications, including European
VersionOne. (2015). The 9th Annual Organization, 24(4), 250–269. Journal of Information Systems, Information Systems
State of Agile™ Survey. Retrieved from Wright, R. T., Campbell, D. E., Thatcher, J. Journal, Journal of Information Technology, and Journal
http://info.versionone.com/state-of- B., & Roberts, N. (2012). Operationalizing of the Association for Information Systems. He can be
agile-development-survey-ninth.html multidimensional constructs in structural contacted at rosenkranz@wiso.uni-koeln.de

PAPERS
Appendix A: Construct measurement.
Construct Code Item Source

Stand-up meeting STM1 Stand-up meetings are extremely short (maximum 15 minutes). So and Scholl (2009)
STM2 Stand-up meetings are to the point, focusing only on what has been done and what
needs to be done on that day.
STM3 All relevant technical issues and organizational impediments come up in the stand-up
meetings.
STM4 When people report problems in the stand-up meetings, team members offer
assistance instantly.
Collective code CCO1 Anyone on the team can change existing code at any time. Maruping, Zhang,
ownership CCO2 If anyone wanted to change a piece of code, he or she needed the permission of the and Venkatesh (2009)
individual(s) who coded it.
CCO3 In our team, we feel comfortable changing any part of the existing code at any time.
CCO4 A unit of code can only be changed by the individual who developed it.
CCO5 In our team, we all feel a sense of responsibility for the system code.
Pair programming PP1 We do our software development using pairs of developers. Maruping, Venkatesh,
PP2 How often is pair programming used in the team? and Agarwal (2009)
PP3 To what extent is programming carried out by pairs of developers on the team?
Software To what extent did the software team actually incorporate requirement changes in Lee and Xia (2010)
team response each of the following categories? (For example, if the project actually incorporated
extensiveness four out of ten different changes in a specific category, your answer would be 40%.)
EXT1 System scope
EXT2 System input data
EXT3 System output data
EXT4 Business rules/processes
EXT5 Data structure
EXT6 User interface
Software team How much additional effort was required by the software team to incorporate the Lee and Xia (2010)
response efficiency following changes? (Effort includes time, cost, personnel, and resources.)
EFF1 System scope
EFF2 System input data
EFF3 System output data
EFF4 Business rules/processes
EFF5 Data structure
EFF6 User interface
Customer satisfaction How do the customers feel about the software that the team has developed? Bhattacherjee (2001)
(information systems CSF1 Very dissatisfied . . . Very satisfied.
development success)
CSF2 Very displeased . . . Very pleased.
CSF3 Very frustrated . . . Very contented.
CSF4 Absolutely terrible . . . Absolutely delighted.
Process performance PPF1 The project was or will be completed within budget. Lee and Xia (2010);
(information systems PPF2 The project was or will be completed within schedule. Wallace et al. (2004)
development success)
(continued)

Construct Code Item Source
Software SF1 The software delivered by the project achieves or will achieve its functional goals. Lee and Xia (2010)
dunctionality SF2 The software delivered by the project meets or will meet end-user requirements.
(information systems
development success) SF3 The capabilities of the software fit or will fit end-user needs.
SF4 The software meets or will meet technical requirements.
Software team AUTO1 The project team was allowed to freely choose tools and technologies. Lee and Xia (2010)
autonomy* AUTO2 The project team had control over what they were supposed to accomplish.
AUTO3 The project team was granted autonomy on how to handle user requirement changes.
AUTO4 The project team was free to assign personnel to the project.
Software team DIV1 The members of the project team were from different areas of expertise. Lee and Xia (2010)
diversity* DIV2 The members of the project team had skills that complemented each other.
DIV3 The members of the project team had a variety of different experiences.
DIV4 The members of the project team varied in functional backgrounds.
* Measures used for control check purposes only.

PAPERS
Appendix B: First-order structural model analysis.
We evaluated a first-order model with the three dimensions of information systems development success, customer satisfac-
tion, process performance, and software functionality, as distinct constructs. The resulting structural model is presented in
Appendix B, Figure 1. For the sake of clarity, we only include significant paths in Appendix B, Figure 1. Effect sizes are reported
in Appendix B, Table 1. The results show that there is no direct significant effect of stand-up meetings and pair programming
on any of the success dimensions. Collective code ownership is positively correlated with customer satisfaction and software
functionality. Both the agility constructs, namely software team response extensiveness and efficiency, are significantly cor-
related with each of the success dimensions, but extensiveness does not significantly impact process performance. The effect
sizes from collective code ownership to customer satisfaction and from software team responsive extensiveness to customer
satisfaction and software team responsive efficiency are medium, and all other effects are small (see Appendix B, Table 1).
Agile management Agility Information systems development

practices R2 = 0.11 success
–0.28* Software team 0.44*** Customer

Stand-up meeting response
satisfaction (CSF)
(STM) extensiveness (EXT)
R2 = 0.30
0.33***
Agile standards and R2 = 0.14
norms 0.24**
–0.44***
Process
Collective code performance (PPF)
ownership 0.27***
(CCO) 0.30**
0.30*** 0.29**
R2 = 0.20
Agile development
Software team
practices Software
response efficiency
0.30*** functionality (SF)
(EFF)
Pair programming
(PP) R2 = 0.19
Note: ***p<0.01, **p<0.05, *p<0.1
Appendix B, Figure 1: First-order model results.
Variable EXT EFF CSF PPF SF

CCO 0.11 0.083
PP 0.092
STM 0.061
EXT 0.209 0.205 0.021 0.055
EFF 0.085 0.076 0.090
Appendix B, Table 1: Effect sizes for exogenous constructs in first-order model.

Appendix C: Model comparison.
Appendix C, Table 1 compares our model with Lee and Xia's (2010) model as well as with a third model that combines our
model with the model of Lee and Xia (2010) (integrated model). For this analysis, we included the control measures software
team autonomy and software team diversity (see Appendix A). Both measures proved to be reliable and valid.
The results shows that our model explains substantially more variance (R2 change 5 0.109) in information systems devel-
opment success compared with Lee and Xia’s (2010) model given the data collected. Also, our model explains more of the
variance of software team response efficiency and a little less of the variance of the software team response extensiveness
compared to Lee and Xia (2010). By adding the two constructs of software team autonomy and diversity to our model (the
integrated model), the explained variance of information systems development success increases only marginally (from 0.305
to 0.308), and only the explained variance in software team response extensiveness is doubled. We interpret these results as
suggesting our model is more parsimonious than the integrated model. In sum, the model comparison in Appendix C, Table 1
provides support for our theoretical argument that agility and information systems development success is more dependent
on the used agile practices than on team characteristics such as autonomy or diversity.
Our Model Lee and Xia’s (2010) Model Integrated Model

Constructs and Constructs and Constructs and
relations Loadings R2 relations Loadings R2 relations Loadings R2
EXT 0.111 EXT 0.121 EXT 0.231
STM→EXT 20.287** AUTO→EXT 0.279ns STM→EXT 20.333**
CCO→EXT 0.135ns DIV→EXT 0.147ns CCO→EXT 0.338ns
PP→EXT 0.302*** PP→EXT 0.279**
AUTO→EXT 0.338ns
DIV→EXT 0.058ns
EFF 0.190 EFF 0.157 EFF 0.194
STM→EFF 20.189ns AUTO→EFF 20.003ns STM→EFF 20.200ns
CCO→EFF 0.209ns DIV→EFF 20.059ns CCO→EFF 0.210ns
PP→EFF 0.095ns EXT→EFF 20.378*** PP→EFF 0.115ns
EXT→EFF 20.438*** EXT→EFF 20.430***
AUTO→EFF 0.018ns
DIV→EFF 0.082ns
ISDS 0.305 ISDS 0.196 ISDS 0.308
EXT→ISDS 0.376*** EXT→ISDS 0.413*** EXT→ISDS 0.380***
EFF→ISDS 0.337*** EFF→ISDS 0.389*** EFF→ISDS 0.338***
STM→ISDS 0.032ns STM→ISDS 0.032ns
CCO→ISDS 0.326** CCO→ISDS 0.326**
PP→ISDS 0.026ns PP→ISDS 0.026ns
Appendix C, Table 1: Model comparison.

This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI.
View publication stats

How Agile Practices Impact Customer Responsiveness and Development Success - A Field Study

Uploaded by

Copyright:

Available Formats

How Agile Practices Impact Customer Responsiveness and Development Success - A Field Study

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How Agile Practices Impact Customer Responsiveness and Development Success - A Field Study

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

How Agile Practices Impact Customer Responsiveness and Development

Article in Project Management Journal · April 2017

Jan Recker Christoph Rosenkranz

SEE PROFILE SEE PROFILE

Generating Innovations in IT Outsourcing Engagements View project

Circular Economy in the Digital Age View project

The user has requested enhancement of the downloaded file.

April/May 2017 ■ Project Management Journal 99

100 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 101

Type of Agile Practice Definition Examples of Agile Practices

102 April/May 2017 ■ Project Management Journal

P1: Agility positively affects information

April/May 2017 ■ Project Management Journal 103

104 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 105

106 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 107

for items CCO1 and CCO3, which were

108 April/May 2017 ■ Project Management Journal

and norms (collective code own- 3.

April/May 2017 ■ Project Management Journal 109

Agile management Agility Information systems development success

Stand-up meeting –0.29** Software team

0.03ns 0.91*** Software

Note: ***p<0.01, **p<0.05, *p<0.1, dashed lines denote insignificant paths

Figure 2: Structural model results.

110 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 111

practices. Software teams enact specific

112 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 113

114 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 115

116 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 117

Appendix A: Construct measurement.

Construct Code Item Source

118 April/May 2017 ■ Project Management Journal

April/May 2017 ■ Project Management Journal 119

Appendix B: First-order structural model analysis.

Agile management Agility Information systems development

–0.28* Software team 0.44*** Customer

Note: ***p<0.01, **p<0.05, *p<0.1

Appendix B, Figure 1: First-order model results.

Variable EXT EFF CSF PPF SF

120 April/May 2017 ■ Project Management Journal

Our Model Lee and Xia’s (2010) Model Integrated Model

April/May 2017 ■ Project Management Journal 121

View publication stats

You might also like

Note: p<0.01, p<0.05, p<0.1, dashed lines denote insignificant paths

Note: p<0.01, p<0.05, p<0.1