Chapter 1 Introduction

(1)

(2)

(3)

Chapter 1 Introduction

In 1994, the bomb exploded. It was a rather short bomb, only eight pages in length, and the worst of all, not even scientific. However, the detonation drew craters into the software industry eradicating broad belief in established methodology, unfolding to increasing levels of shock, anger, ridicule and – acknowledgment. It was acknowledgment of a painful truth unspoken before the bomb detonated. What kind of bomb was it?

The bomb was the so-called CHAOS Report launched by a commercial research institute (Standish Group International, 1994) specializing in IT performance. The detonation was triggered by the statement that the majority of IT projects was a failure. Despite the devastating number that there was a 83.8%

failure rate of all IT projects in terms of meeting both budget and time goals, and despite the heavily criticized methodology applied, the most surprising out- come was the enormous and undeniable impact on the discussion of prevalent software development methodology, i.e. the waterfall model and V-model. The latter are referred to as plan-driven methods in the sense that requirements analysis fleshes out into scope definition determining the project plan, which is not to be changed over the course of the project. Although this methodology is seen appropriate for contexts where scope does not change over time, the intensi- fied discussion which was triggered after the first CHAOS report indicated that times had changed, and that a majority of projects in the field had encountered severe problems with the inflexibility of plan-driven methods. Their concept of fixing requirements specification upfront was long believed to be a major suc- cess factor, but suddenly revealed incapable of dealing with major problems of changing requirements, incomplete requirements and lack of user involvement. Since these plan-driven methods were the only ones taught and practiced in software development at that time, a simple but nagging question soon emerged and spread across the software industry: Is there an answer to this dilemma?

The answer was that there was no answer – until then. It took the industry a whole five years to come up with a methodological response to plan-driven 1

(4)

methods – it was as late as 1999 when James Highsmith, a software consultant, explained new principles of team management in his approach of Adaptive Soft- ware Development (1999), and Kent Beck introduced Extreme Programming (1999) as the proclaimed antithesis to the waterfall model. In the course of the following years, these two methods merged with a handful of other, similar methods under the label agile methods (Beck et al., 2001). Their purpose was to effectively integrate changing customer requirements and to emphasize team collaboration. Through numerous newsgroups, websites, blogs, software conferences, the word about agile methodology spread day by day among thousands of software engineers world-wide to an extent that today, it is acknowledged as an alternative to the waterfall and V-model in uncertain environments. Moreover, even the academic world has increasingly been teaching agile methodology and thereby acknowledged the conceptual difference to seemingly similar methods like rapid prototyping (Connell & Shafer, 1989) – the difference lies in the specification of their practical implementation, the software development practices.

Such practices as specified by agile methods are called agile practices in this study.

Although the increasing adoption of agile practices in software development and academics is a sign of popularity, it does not necessarily imply that they could effectively overcome the waterfall-related problems. To this end, the non- scientific consultant and practitioner literature on the emerging agile methods has always been abundant with claims about positive effects of agile practices on team and customer collaboration. Yet these claims consisted mainly of analo- gies, metaphors or heuristics, but not of concrete evidence, let alone scientific evidence. Emerging research on agile methods later confirmed many of these claims – yet these findings were exclusively obtained with qualitative research methods. Therefore, the question is open whether these claims made by both practitioners and qualitative researchers can be substantiated by quantitative research methods. After all, this research need has never been more in demand than now: In a recent workshop by Wang, Conboy, Pikkarainen, and Lane (2009) summarizing the past 10 years’ research on agile methods at one of the major agile software development conferences, the first item on the top priority list of open research questions in the agile context were studies with solid statistical foundation.

Framing such a research question necessitates a solid theoretical basis ca- pable of taking both task- and context-specific factors of agile software development into account. For providing appropriate theoretical and methodological frameworks, organizational psychology appears to be the most proper academic field. The main reason is that the key positive effects of agile practices are claimed on group interaction, which represents a major focus of organizational psychology. Extensive study of teams in organizational psychology over

(5)

the past few decades has identified important team performance factors such as goal setting, goal commitment, and social support (e.g., Kozlowski & Ilgen, 2006; Rasmussen & Jeppesen, 2006; Stock, 2004). Investigating such team performance factors as mediators¹between agile practices and team effectiveness may unveil important social-psychological mechanisms relevant in the agile context.

Such findings could help to understand if and how agile practices lead to team effectiveness, and to what extent. Furthermore, research on agile practices will benefit from a comparison of a representative selection of agile practices. Only by such a comparison can these agile practices be put into perspective, because their relative value against each other can be detected. Previous studies have vastly neglected this differential perspective on agile practices by focusing on mostly a single practice, or at best on a small subset of practices, yet never tested against the same effect variables so to enable a comparison.

Research Question

Fleshing out the preceding reflections into a testable theoretical model leads to constructing several separable mechanisms between agile practices and team effectiveness in order to allow a differentiation in the nature of teamwork effects. This model conceptualization implies several causal hypotheses ordered in subsequent levels. The resulting complexity of several mechanisms cannot be analyzed by classic mediator analysis (Baron & Kenny, 1986) because it assumes the test of a single mechanism. Therefore, the guiding research question,

Do agile practices lead to team effectiveness through teamwork mechanisms?

must be split into the following two research questions which can be an- swered separately:

Research Question 1 : Which teamwork mechanisms towards team effective- ness are relevant in the agile context?

Research Question 2 : Which agile practices influence these teamwork mecha- nisms positively?

1 The term “mediator” in this study is not utilized in the strict sense of Baron and Kenny (1986), but in a wider sense of “intermediary process variable”. The inherent reason is that a strict mediator test according to Baron and Kenny (1986) cannot be realized by this study’s statistical analysis method, structural equation modeling (cf. James, Mulaik, & Brett, 2006).

3

(6)

Decomposing “good teamwork” into such separable mechanisms could pro- vide a much more differentiated understanding than currently exists of how teamwork can be positively influenced by behavioral group practices. Since these mechanisms are followed to their effect on team performance, any positive finding can be also insightful, if not indispensable, for the embedding or- ganization. For example, the relevance of “soft factors” for team effectiveness, if found, can be an incentive for rigid organizations to change, i.e. adopt agile practices into their software development methodology, or calibrate the focus among these agile practices.

Theoretical Foundation

The theoretical underpinnings for developing this study’s teamwork model consisted of three major theories:

First, from the vast existing pool of conceptual frameworks and theories, this study elaborates on one specific teamwork model derived from innovation research: Scholl’s (2005) model of teamwork effectiveness composed of the major constructs coordination capability and knowledge growth. The validity of this teamwork model is explored in a specific and distinctly different work context, i.e. agile software development teams.

Second, goal setting theory (Locke & Latham, 1990) as one of the major theories to explain how individuals and groups reach high performance. From related research, the constructs goal commitment and social support were derived as potentially meaningful mediators between agile practices and coordination capability.

Third, control theory (Carver & Scheier, 1981) was selected as a useful theory for explaining group learning and adaptation of human behavior in feedback cycles. Hence, open communication and adaptation were modeled as mediators between agile practices and knowledge growth.

Method

The model was tested in a field study on a sample of 227 team members in 55 software development project and release teams who applied agile practices.

Of each project or release team, four team members including the project man- ager, as well as the customer, completed the web-based questionnaire of this field study. The method chosen for testing the hypotheses of the constructed model was structural equation modeling (SEM). This multivariate statistical methodology allows estimating parameters of multiple regressions in subsequent causal levels simultaneously, and additionally has the advantage of providing

(7)

metrics for evaluation of the estimated parameters’ stability (model fit indices, standard errors and significance levels).

To enable the analysis of this research endeavor, several methodological steps were undertaken:

Due to the lack of appropriate scales, this study developed entirely new mea- surement instruments for all agile practices and validated them in two pretests and the final study (So & Scholl, 2009). In addition, new scales for two teamwork constructs, open communication and adaptation, were developed and validated to optimize the fit of the postulated teamwork model to the agile context. Further- more, this study applied a conglomeration of statistical techniques to confront the major challenge of reaching good model fit in spite of a small sample size and a non-parsimonious model.

Structure of Chapters

This book unfolds the study’s content in the following order:

Chapter 2 contains the theoretical framework for this study. It subsequently unfolds the components of the research question from the core aspects of agile methodology and their realization in agile practices, to the basic teamwork model of this study and its extensions with goal setting theory and control theory. The chapter summarizes with an overview of the derived hypotheses.

Chapter 3 elaborates the methodology applied in this study. It starts with a delineation of the sample, the procedure, and the conceptualization of mea- sures. Then, the process of scale construction is described, which produced the input for the subsequent analysis of the hypotheses by the statistical approach of structural equation modeling (SEM). The theoretical underpinnings of this statistical methodology, as well as its fundamental assumptions, are explained as far as relevant in the context of this study.

Chapter 4 provides the results of all statistical analyses effected. These analyses include reliability analysis, explorative factor analyses, and various multi- normality analyses. Results of SEM analyses effected with two aggregation techniques, index scores and item parceling, are elaborated and compared.

Chapter 5 provides a discussion of this study’s limitations and its contribu- tions. To explain the results, methodological steps are revisited and resulting consequences for this study’s evaluation and recommendations for future studies are developed.

5