Investigating the Target Environment for Agile Methods

19th Australasian Conference on Information Systems 3-5 Dec 2008, Christchurch

The Target Environment for Agile Methods Strode, et al.

Investigating the Target Environment for Agile Methods Diane E. Strode Sid L. Huff School of Information Management Victoria University of Wellington Wellington, New Zealand Email: [email protected], [email protected] Alexei Tretiakov Department of Management Massey University Palmerston North, New Zealand Email: [email protected]

Abstract Agile methods are systems development methodologies that are commonly tailored to fit the contingencies of a project. We used this property to investigate the environmental factors which affect the use of agile methods. Initially we developed a theoretical model of the target environment for agile methods, then tested the model using data from a multi-case study of nine software development projects. We gathered data on agile method tailoring to calculate an agile method usage value. We then investigated the relationship between project environment factors and agile method usage using non-parametric data analysis. Our results indicate that specific environmental factors correlate with effective use of an agile method. These factors include the extent to which the project was undergoing constant change and the organisational culture factors of feedback and learning, teamwork, empowerment of people, collaboration, leadership, loyalty, and a results-oriented culture that values entrepreneurship, innovation and risk taking. Keywords Agile methods, information systems development methodology, software development.

INTRODUCTION Agile methods are newly established system development methodologies1 focusing on software development and characterised by short iterative and incremental development processes and high levels of collaboration. They are designed to be effective in high change environments using techniques that support feedback and learning and by producing early working software as development progresses (Beck et al. 2001). While some authors refer to agile methods as a “new paradigm” in software development (Rajlich 2006), others such as Abrahamsson et al. (2003) have described their evolution from existing development methodologies in information systems and software engineering, arguing that the techniques used within each agile method are not new, rather, it is the philosophy and the combination of techniques which is unique. Rigorous empirical studies of agile method use have been published (see for example Fruhling & De Vreede (2006) and Dyba and Dingsoyr (2008)) but a number of questions remain unanswered. One important question, which is relevant for any type of system development methodology, is when and how to use it (Glass 2004). Agile method authors state that agile methods are not suitable in all situations or project environments (Beck and Andres 2005; Cockburn 2002; Schwaber and Beedle 2002), and practitioners have also reported concerns about the decision of when to apply these approaches (Lindvall et al. 2004, p. 26). Researchers have also suggested that studies are needed into the “applicability and relevance of agile methods in different project contexts” (Cao and Ramesh 2007, p. 47). We have identified this as a problem and formulated the following research question to guide this study: “For what type of environment are agile methods most suitable?” To study this problem, we exploited a property of system development methodology use reported in empirical studies, namely, that methodologies are frequently tailored, or adapted, to fit the contingencies of the project in which they are used (Fitzgerald 2000). Agile methods are no exception (Aydin et al. 2005; Fruhling and de

1

For brevity we use the term ‘method’ and ‘methodology’ interchangeably. For discussions on the use of this terminology see Avison and Fitzgerald (2006), Wynekoop and Russo (1995) and Iivari, Hirschheim and Klein (2001). Our definition of methodology is that of Avison and Fitzgerald (2006).

938



Vreede 2006). We used this observation to investigate the environmental factors which affect the use of agile methods. Initially we developed a theoretical model of the target environment for agile methods based on the literature on agile methods and the results of empirical studies (see Table 4). The target environment therefore is an amalgamation of our findings on the factors reported to constitute an optimal environment where agile methods are most effective. We then tested the model using data from a multi-case study. We gathered data on the project environment factors and also on agile method tailoring. The tailoring data was used to calculate an agile method usage value which we then used to investigate the relationship between project environment factors and agile method usage using non-parametric data analysis. The remainder of this paper is organised as follows: first we give a brief introduction to the agile methods and discuss the lack of a common definition for agile methods. This is followed by a discussion of the environment for agile methods and how they are tailored for use. Then we describe our study including the research propositions and research design, including an explanation of the unit of analysis, and a description of our phased research process, how we developed the theoretical model of the target environment, the multi-case study design, along with our research model. Results and a discussion of each research proposition are provided, and the paper summarised in a conclusions section.

AGILE METHODS Agile methods are system development methodologies published since the late 1990s. They were designed by experienced software developers who found traditional software engineering practices inadequate for producing quality software in a timely manner in unstable environments. Baskerville and Pries-Heje (2004) discuss how unstable environments arose because of the move by organisations to a consumer and market focus characterised by new software product development for the internet, rapid advances in technologies and the need for frequent software releases. In addition they found a lack of stability impacts on system requirements which are initially vague as customers may not know what they want until they see it. Agile methods were designed to accommodate these issues in software development by providing explicit practices and techniques for improving quality (e.g. test-first development), for improving control of the delivery schedule (e.g. incremental delivery of prioritized functionality) and for adapting rapidly to change (e.g. frequent planning sessions with the customer) (Beck, 2000). However, a common definition of agile methods has not been substantially identified making studies of these methods problematic. The agile manifesto (Beck et al. 2001) provides a set of published values and principles but not all proposed agile methods meet all of the principles (Conboy and Fitzgerald 2004) and no other widely accepted definition of what constitutes an agile method exists. Reifer (2002, p. 18) stated that it is necessary to “clearly identify what ‘agile methods’ means,” because, after questioning software engineers, he found they had no common meaning for the term. Although it is generally accepted that both Extreme Programming (XP) and Scrum are instances of agile methods (Dyba and Dingsoyr 2008) identifying those software development methods which belong to the set of agile methods is not straightforward. A number of comparative studies have investigated which methods could belong to the set, but there is no consensus (Abrahamsson et al. 2002; Abrahamsson et al. 2003; Highsmith 2002). Development of an “agility framework” is currently underway in order to address this issue (Conboy and Fitzgerald 2007). In our study we have based decisions regarding what methods are agile methods on the most salient existing literature, recognising that other researchers might have made somewhat different choices. We define an agile method as follows: “An agile method is a software development methodology designed for the management and support of iterative and incremental development of business systems in environments where change is constant. Agile methods use software development techniques that enhance teamwork in small empowered teams and support active customer involvement. An agile method is designed to produce working software early using communication, feedback, learning and frequent meetings rather than modelling and documentation. Agile methods adapt existing software development techniques to achieve these goals.” (Strode, 2005, p.91).

AGILE METHOD ENVIRONMENTS AND TAILORING Method tailoring involves the removal, addition or substitution of techniques when using a published method on a development project. However, researchers tend to assume tailoring to be the removal (or non-adoption) of techniques, as we do here. Fitzgerald (2000) established that object-oriented as well as structured system development methodologies are invariably tailored and many empirical studies of agile methods also report such tailoring (Cao et al. 2004; Fitzgerald, Hartnett and Conboy 2006; Xu and Ramesh 2007). In addition the literature shows that agile methods are found to be more problematic to use and require more extensive tailoring when they do not meet the environmental conditions specified by their authors (one example is Lindvall (2004)). Research has shown that that the corporate culture, the interface of the team with the existing organization, its

939



processes and structure are frequently accommodated by tailoring the method (Maurer 2002; Reeves and Zhu 2004; Schummer and Schummer 2001). In studies of agile method usage, the extent of method tailoring must be taken into account, since tailoring of published agile method approaches affects the extent to which the method actually being used is in fact an agile method. In our study we have developed an approach for calculating a usage value for in-situ use of an agile method. This provided us with a means to explore the relationship between different project environment factors and agile method usage.

RESEARCH PROPOSITIONS In order to explore the research question “For what type of environment are agile methods most suitable?” we formulated three propositions: 1. The full agile method is not used in practice; the method is tailored-for-use. 2. An agile method is tailored less when it is used in its target environment compared to when it is used in an environment that significantly differs from its target environment. 3. There are specific environmental conditions that are suitable for agile methods that constitute a target environment2.

RESEARCH DESIGN The case study research method was selected because it is appropriate for situations involving contemporary events taking place in a real-life context where the researchers cannot control variables (Dube and Pare 2003; Yin 2003). We used a five phase research process: 1. A theoretical model of the target environment for agile methods was developed from the existing literature on agile methods. 2. A multi-case study was carried out to investigate software development projects. Data was gathered on each factor in the theoretical model and the extent of method tailoring on each project. 3. Using the method tailoring data we calculated two values for each project: The fraction of techniques used (a count of the techniques used). The extent of agile method usage. 4. We investigated the relationship between the fraction of techniques used and the extent of agile method usage. 5. We then carried out a cross case analysis using non-parametric statistics to explore any correlation between individual factors in the model and agile method usage. Theoretical Model Development Theory development is a critical aspect of information systems research (Gregor 2006). To explore the environment for agile methods, we first developed a theoretical model of the target environment for agile methods. First we selected five specific, published methods for study: Extreme Programming (XP) (Beck 2000), Scrum (Schwaber and Beedle 2002), Dynamic Systems Development Method (DSDM) (Stapleton 1997), Adaptive Software Development ASD (Highsmith 2000) and Crystal methods (Cockburn 2002). Each of the five methods is thoroughly discussed and documented in the previously cited books. We selected these methods because they were the earliest published agile methods and provided a manageable sample and enough data for a meaningful analysis of the common properties of the methods. We also assumed that these methods would contain most of the techniques used in subsequently published agile methods. The target environment model was based on two sources from the agile method literature. Our first source was the published books on each of five methods, which we analysed using a comparative framework adapted from that of Avison and Fitzgerald (2006). Our second source was based on a review of the literature on agile methods. We amalgamated the environmental factors we found and organised them into categories: organisation, application domain, people, project, and technology.

2

We did not focus on differentiating the conditions suitable for specific agile methods.

940



Case Study Design To investigate this theoretical situation we used a multi-case study of nine software development projects. The unit of analysis was defined as an individual system development project (Yin 2003). Each project had a welldefined purpose, was carried out using a set of activities that aimed to produce a software application, had both a beginning and an end date (estimated if the project was not complete at the time of the study), was underway in that at least 1/3 of the estimated project duration was complete, and had at least one assigned employee. In addition the project was carried out using either an agile method, a systems development methodology that was not an agile method (i.e. Rational Unified Process (RUP), another named methodology or a documented inhouse methodology), or no systems development methodology (i.e. ad hoc development). Yin (2003) advises selecting cases based on both analytical (cases providing similar results) and theoretical (dissimilar) replication logic. Following an analytical replication logic, five cases using agile methods were selected. One of these was found to be a mixed method project (agile and RUP). Theoretical replication was achieved by selecting four cases where agile methods were not used. Participants were selected because they met the criteria of working on a project that met the unit of analysis criteria, were experienced in systems development, could give a perceptive and accurate overview and history of the project, and had in-depth knowledge of the development methodology used. Data Collection Pre-testing of questionnaires, and the use of pilot case studies are recommended for case study research (Dube and Pare 2003; Yin 2003). We used cognitive pre-testing to ensure the questionnaire was easy to understand and did not contain any inappropriate language, and a pilot case study to ensure the questionnaire could be completed easily and would provide appropriate data. Three different data collection methods were used. The web site belonging to the organisation where the development occurred was used to determine organisation background, type, and size. A questionnaire was used to gather both quantitative and qualitative data from participants. Finally, interviews were used to gather additional qualitative data (only quantitative data analysis is reported in this paper). Constructs in the questionnaire were drawn from existing literature on information systems and organisational culture whenever possible (e.g. domain of application types, categories of technology). The questionnaire had three aims: to check that the project was a suitable case for this study, to enable the items in the theoretical model for the target environment of agile methods to be assessed and to determine the extent of tailoring of the agile method used.

RESULTS AND DISCUSSION The nine cases were from different organisations and covered a range of different types, sizes, and lines of business. The main detail of each case is provided in Table 1. Proposition 1: The Method is Tailored for Use Each of the agile methods is made up of a unique combination of development techniques. We define ‘technique’ as any practice (e.g. 40-hour week, customer on site) or technique (as defined by Iivari, Hirschheim and Klein, 2001) (e.g. test-first development, story cards) that belongs to any one of the five agile methods we analysed as part of this study. A full list of the techniques assessed is available, see Strode (2005). We were able to assess each of the agile projects to determine the extent of method tailoring. The extent of tailoring was calculated (1) by calculating the number of actual techniques used, and (2) by calculating the extent of agile method usage as below: (1) The fraction of techniques used: % fraction of techniques used = (Tc / Tmc) × 100 Where: Tc = count of techniques used on the project Tmc = count of all techniques present in the method

941



Table 1: Organisation details Project

Method

Organisation type

Organisation size

Business activity

Market

Alpha

XP

P

100-150

Control system

NZ and International

Beta

XP

SOE

150-200

Information presentation


Delta

XP/ Scrum

G

13000-14000

Web development

Internal

Zeta

DSDM

P

300

DSS/MIS

UK

Theta

RUP/XP

P

1400-1500

MIS

NZ and Australia

Iota

RUP

G

600

Transaction processing

Internal

Rho

Ad hoc

G

4500-5000

MIS

Internal

Tau

Ad hoc

P

5-10

Shrink wrapped software


Chi

Ad hoc

G

300-400

MIS


Key

G – Government department or fully government funded organisation SOE – State Owned Enterprise P – Privately owned company DSS – Decision Support System MIS – Management Information System

Only those techniques that belong to the selected method were included (i.e. if the respondent selected techniques that do not belong to their nominated method then this technique was not included in the count). (2) The extent of agile method usage: % agile method usage = (∑Tq / (3Tmc)) × 100 Where: Tq = extent of usage of a particular technique The extent of usage of each technique was categorised as: 0 - never used; 1 - seldom used; 2 - often used; 3 always used the technique as assessed by the project leader. Only those techniques that belong to the selected method were included (i.e. if the respondent selected techniques that did not belong to their nominated method then this technique was not included in the summation). Table 2 shows the fraction and the extent of agile method usage for each agile project surveyed. Project Delta was assessed twice, once for XP and also for Scrum, since a combination of techniques from the two methods was used on that project. These results show that each agile project tailored the method. For example the fraction of techniques used by Alpha, Theta and Zeta was 100% but the extent of usage was lower, 96%, 63% and 94% respectively. The other projects also tailored their method not only by reducing the fraction of techniques they chose to use but also the extent to which they used them. These results show that the method is Table 2: The extent of method tailoring on agile projects Project

Alpha

Beta

Delta

Delta

Theta

Zeta

Development method used

XP

XP

XP Scrum

XP Scrum

XP RUP

DSDM

Compared with

XP

XP

XP

Scrum

XP

DSDM

Total techniques in method

19

19

19

13

19

13

Number of techniques used on project

19

18

16

11

19

13

The fraction of techniques used (1)

100%

95%

84%

85%

100%

100%

Total quantity of techniques in method

57

57

57

39

57

48

Total quantity of techniques used on project

55

32

38

26

36

45

The extent of agile method usage (2)

96%

56%

67%

67%

63%

94%

tailored in each agile project and there is a range of tailoring reflected in the extent of agile method usage taking values from 96% to 56%. It is therefore clear that Proposition 1 is validated: that the method is tailored-for-use was true in all projects using agile methods.

942



Proposition 2: Tailoring and the Target Environment To compare all of the projects, both agile and non-agile, it was necessary to calculate a method usage value for each of the non-agile projects. We did this by calculating, for each non-agile project, its usage of each of the agile method techniques. This provided five sets of data, each set comparing a non-agile project with the extent of method usage of each of the five methods (the XP method, the DSDM method, the Scrum method, the Crystal method and the ASD method). Table 3 shows the extent to which each of the non-agile projects used the techniques of each method. The sum of the ranks shows that XP is the highest ranked method (i.e. more XP techniques were used on the non-agile projects overall than techniques from the other agile methods). So for the non-agile projects XP was nominated as the method for the project. This meant that a comparison of the method usage and individual target environment factors could be carried out for all projects, both agile and non-agile. The pattern of usage of agile techniques by non-agile projects was as expected: the non-agile projects used fewer agile method techniques than the agile projects (compare Table 2 and Table 3). This provides evidence that agile methods are distinct from ad hoc development and from RUP development. However there is overlap in technique usage. This can be observed, for example, in the use of XP. Beta, which nominated XP as their method (see Table 2), used XP at the 56% level, whereas Tau (see Table 3), which nominated no development method, used XP techniques at the 54% level. One explanation for this overlap is that there were five techniques used on the projects that are not unique to agile development, i.e., they are also used in non-agile projects. The techniques are customer-on-site, 40 hour week, requirements are prioritised, design is kept as simple as possible, and coded solution is kept as simple as possible. This was not an unexpected result because these techniques are simple actions and do not requiring training (such as test-first development or user stories). Table 3: The extent of agile method usage on non-agile projects Σ ranks

Project

Iota

Tau

Chi

Rho

Method used

RUP

Ad hoc

Ad hoc

Ad hoc

XP

40% (3)

54% (1)

30% (2)

18% (2)

8

DSDM

38% (4)

54% (1)

29% (3)

19% (1)

9

Scrum

36% (5)

38% (5)

21% (5)

3% (3)

18

Crystal

50% (1)

43% (4)

23% (4)

0% (4)

13

ASD

42% (2)

50% (3)

31% (1)

0% (4)

10

Proposition 2 argued that an agile method is tailored less when it is used in its target environment compared with when it is used in an environment that significantly differs from its target environment. To test this proposition, we analysed each factor in the target environment model individually. Spearman’s correlation coefficient (for ordinal data in the questionnaire, such as "involvement in making decisions," ranked from 0 to 5) or Pearson’s product moment correlation coefficient (for ratio data in the questionnaire, such as "number of full-time developers," expressed by a number) were calculated to investigate the correlation between the usage of agile method techniques (as calculated for proposition 1) and the environmental factor in the target model. We found statistically significant correlations for some factors. We also found evidence to reject some factors and for others we found no conclusive evidence. There were also factors that were common to both agile and non-agile projects. These factors may be necessary but not sufficient in the target environment. Results of the data analysis are shown in Table 4. Some criteria were assessed using more than one question in the questionnaire (maximum of two questions). Results were reported as ‘supported’ when all questions used to assess the factor gave a statistically significant correlation (Spearman’s or Pearson’s rho, 2 tailed test, significant at 0.05 or 0.01 level). The ‘weakly supported’ results indicate that one of two questions assessing the factor showed a statistically significant result or, in the case of factor 20, a student t-test was used and was significant at the 90% level, but not at the 95% level. For factor 3 no projects reported a ‘mainly informal’ communication style indicating that the agile projects have a balanced or informal style, but this was not unique to the agile projects. The questionnaire contained a section on organisational culture that included additional questions about factors not present in the target environment model. These questions were included because they come from a set of related questions which provide a comprehensive assessment of organisational culture (Cameron and Quinn 1999). We found three factors that were not present in the theoretical model, which showed statistically significant correlation (Spearman’s rho, 2-tailed test, significant at 0.05 or 0.01 level) with the extent of agility on the projects and they were added to the target environment model as follows (see Table 5); item A ‘the

943



organisation is results oriented’, item B ‘leadership in the organisation is entrepreneurial, innovative, and risk taking’, and item C ‘the organisation is based on loyalty and mutual trust and commitment’. Proposition 3: Agile Methods Target Environment Proposition 3 states that there are specific environmental conditions suitable for agile methods which constitute a ‘target’ environment. To test this, we applied the results shown in Table 4 to produce a refined model. This model (see Table 5) includes only the supported results from Table 4 with factors amalgamated when they were assessed with the same questions from the questionnaire, with the new organisational culture factors added, and with factors excluded that were determined to be agile method techniques rather than environment factors. Limitations The authors recognize a number of limitations in this study. First of all, our theoretical model of the target environment for agile methods is based on an analysis of five agile methods. By selecting different methods, later versions, or a greater number of methods the study may have provided different answers. In research using the case study method it is not possible to generalise the conclusions derived from a small number of cases to the wider population. Therefore we can only say that the conclusions are valid for this given set of project data. In addition, we used a qualitative design to assess a proposed target environment model with quantitative statistical analysis carried out where possible to assess factors within the model. This meant using weak non-parametric statistics due to the small sample size. Furthermore we used a single data source (respondent) in each project. A broader sample of respondents, especially team members would have provided stronger evidence particularly regarding individual perceptions of organisational culture factors. This study did not analyse the effect of combinations of target environment factors or possible interactions between factors. For example, complexity may consist of combinations of factors such as size, technologies used, and domains of application. Such combinations were not addressed in this study. Finally, we note that there may be complex interactions and feedback effects in real organizations that have not been taken into account here. For example it is possible that the very fact that an organization decides to use agile methods may alter the target environment (a kind of ‘Heisenberg uncertainty principle’ of software development!).

CONCLUSIONS This study supported our three research propositions. Proposition 1 is supported because in all cases the agile methods were tailored for use. We also report that in one case the agile method was tailored almost to the extent of ad hoc development. This means that studies of agile methods should consider quantifying agile method use to be sure that conclusions drawn about the use and effects of agile methods are for the affect of agile method use rather than ad hoc development. Proposition 2 and 3 are supported because we found a significant correlation between the extent of usage of an agile method and certain environmental factors. From this we conclude that in order to improve the use of agile method techniques on a project it is likely to require the following environmental conditions to be present. The organisation, its management and the development teams must value feedback and learning; social interaction must be trustful, collaborative, and competent. The organisation must be results oriented and based on loyalty, mutual trust, and commitment. Teamwork must be valued, and a flexible, participative, and encouraging approach to social interaction is necessary. The management style must be that of leadership and collaboration, and the project manager must act in a facilitating role with the staff empowered to make decisions. The leadership in the organisation must be entrepreneurial, innovative, and risk taking. In addition we found evidence for ‘projects undergoing constant change’ as a factor in successful agile method use.

944



Table 4: Model of the target environment for agile methods and results Category

Item

Organisation

1 2 3 4 5 6

Technology

7 8 9 10

Domain

11 12 13

14 15 16 Project

17 18 19 20 21 22 23 24 25 26 27 28

People

29 30 31

Target environment factor The organisation values feedback and learning. The organisation values teamwork. The organisation values face-to-face communication. The organisation enables empowerment of people. The organisation is flexible and participative and encourages social interaction [Amalgamate with 2]. Social interaction in the organisation is trustful, collaborative, and competent [Amalgamate with 1]. Communication in the organisation is informal [Amalgamate with 3]. The management style is that of leadership and collaboration. The size of the organisation is large/ small. Any of: Internet application domains, shrink wrapped software, webbased systems, component delivery, component development, component assembly, client/server systems, networked systems, webdeployed applications. Automated testing is used. [EXCLUDE] Object-oriented technology. Any of: application frameworks for external use, e-commerce and ebusiness, data warehouse, and products for the Internet software market. The domain is interface intensive systems The domain is business problems, business systems and applications The domain is non-critical projects/ Critical new business initiative. Projects that are complex. Projects with vague requirements Projects with constant changes in requirements/ Projects with stable requirements. Projects undergoing constant change. Projects with intense time pressure. Projects with teams of 2 to 10 developers. [EXCLUDE] Projects where documentation is minimised. Projects involving new development/ Precedented systems/ Projects that are not constrained by an existing computing environment. Projects involving any of fix-price contract software development, inhouse development, outsourced software Projects using incremental development. [EXCLUDE] Projects using iterative development. [EXCLUDE] Projects where the project manager acts as a facilitator. [Amalgamate with 5] Projects teams are collocated. [EXCLUDE] Users are actively involved in the project Developers are experienced

Model supported 99 9 9 99 99

N

99 9 99 ×

N

× ×

× 99 ×

N

× × × 9 99 -

N

99

N

× ×

Key Items in bold are unclear in the literature on agile methods because method authors have made statements that are contradicted in empirical studies. 99 Supported 9 Weakly supported × Evidence to show this is not true Evidence is inconclusive N Not unique to agile methods projects [EXCLUDE] this factor is excluded in the revised model because it is a technique that forms part of one or more specific agile methods.

945



Table 5: Refined model of the target environment for agile methods Factors from table 6 1 2 4 8 Item A [new] Item B [new] Item C [new] 20 3 15 23 25

Key

The organisation values feedback and learning. Social interaction in the organisation is trustful, collaborative, and competent. The organisation values teamwork is flexible and participative and encourages social interaction. The project manager acts as a facilitator The organisation enables empowerment of people. The management style is that of leadership and collaboration. The organisation is results oriented. The leadership in the organisation is entrepreneurial, innovative, and risk taking. The organisation is based on loyalty and mutual trust and commitment. Projects undergoing constant change. The organisation values face-to-face communication and communication in the organisation is informal. The domain is business problems, business systems and applications Documentation is minimised. Projects involve any of fix-price contract software development, in-house development, outsourced software

++ + A N

++

A

+

A

++ ++ ++ ++ ++ + ++

A A A A A A N

++ ++ ++

N N N

Supported Weakly supported More common in agile method projects Not unique to agile method projects

All projects reported using informal, face-to-face communication, and that the domain was business problems, business systems, and business applications, and all projects involved either fixed price contract software development, in house development or outsourced software. We found these factors are not unique to projects using agile methods. These factors may be necessary for successful use of an agile method but they are not sufficient for successful adoption. ‘Documentation is minimised’ was also a factor common to all agile projects but this was not assessed on non-agile projects. We have provided an initial model of the theoretical target environment for agile methods and increased understanding of the most appropriate project environment for agile methods. However, the factors in this theoretical framework need further exploration. Additional studies of these individual environmental factors and the relationship, if any, between individual factors would improve knowledge about effective agile method use and the effect of the environment in which they are adopted.

REFERENCES Abrahamsson, P., Salo, O., Ronkainen, J., and Warsta, J. 2002. "Agile Software Development Methods: Review and Analysis." VTT Publications 478. Retrieved 1 January, 2004, from http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf Abrahamsson, P., Warsta, J., Siponen, M.K., and Ronkainen, J. 2003. "New Directions on Agile Methods: A Comparative Analysis," in: Proceedings of the 25th International Conference on Software Engineering, Icse'03. Washington, DC, USA: IEEE Computer Society, pp. 244-254. Avison, D., and Fitzgerald, G. 2006. Information Systems Development: Methodologies, Techniques and Tools. London: McGraw-Hill Education. Aydin, M.N., Harmsen, F., van Slooten, K., and Stegwee, R.A. 2005. "On the Adaptation of an Agile Information Systems Development Method," Journal of Database Management (16:4), pp 24-40. Baskerville, R.L., and Pries-Heje, J. 2004. "Short Cycle Time Systems Development," Information Systems Journal (14:3), pp 237-264. Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley. Beck, K., and Andres, C. 2005. Extreme Progamming Explained: Embrace Change, (2 ed.). Boston: AddisonWesley.

946



Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. 2001. "Manifesto for Agile Software Development." Retrieved 17 February, 2003, from http://www.agilemanifesto.org Cameron, K.S., and Quinn, R.E. 1999. Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework. Reading MA: Addison-Wesley. Cao, L., Mohan, K., Xu, P., and Ramesh, B. 2004. "How Extreme Does Extreme Programming Have to Be? Adapting XP Practices to Large-Scale Projects," 37th Hawaii International Conference on System Sciences, Hawaii: IEEE. Cao, L., and Ramesh, B. 2007. "Agile Software Development: Ad Hoc Practices or Sound Principles?," in: IT Pro. pp. 41-47. Chow, T., and Cao, L. 2008. "A Survey of Critical Success Factors in Agile Software Projects," The Journal of Systems and Software (81:6), pp 961-971. Cockburn, A. 2002. Agile Software Development. Boston: Addison-Wesley. Conboy, K., and Fitzgerald, B. 2004. "Toward a Conceptual Framework of Agile Methods: A Study of Agility in Different Disciplines," in: Proceedings of the 2004 ACM workshop on Interdisciplinary Software Engineering Research. New York: ACM Press, pp. 37-44. Conboy, K., and Fitzgerald, B. 2007. "Agile Drivers, Capabilities, and Value: An over-Arching Assessment Framework for Systems Development," in: Agile Information Systems: Conceptualization, Construction, and Management, K. Desouza, C (ed.). Amsterdam: Elsevier, pp. 207-221. Dube, L., and Pare, G. 2003. "Rigor in Information Systems Positivist Case Research: Current Practice, Trends, and Recommendations," MIS Quarterly (27:4), December, pp 597-635. Dyba, T., and Dingsoyr, T. 2008. "Empirical Studies of Agile Software Development: A Systematic Review," Information and Software Technology (50), pp 833-859. Fitzgerald, B. 2000. "Systems Development Methodologies: The Problem of Tenses," Information Technology and People (13:3), pp 174-185. Fitzgerald, B., Hartnett, G., and Conboy, K. 2006. "Customising Agile Methods to Software Practices at Intel Shannon," European Journal of Information Systems (15), pp 200-213. Fruhling, A., and de Vreede, G.-J. 2006. "Field Experiences with Extreme Programming: Developing an Emergency Response System," Journal of Management Information Systems (22:4), pp 39-68. Glass, R.L. 2004. "Practical Programmer: Matching Methodology to Problem Domain," Communications of the ACM (47:5), pp 19-21. Gregor, S. 2006. "The Nature of Theory in Information Systems," MIS Quarterly (30:3), pp 611-642. Highsmith, J. 2002. Agile Software Development Ecosystems. Boston: Addison-Wesley. Highsmith, J.A. 2000. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York, NY: Dorset House Publishing. Iivari, J., Hirschheim, R., and Klein, H.K. 2001. "A Dynamic Framework for Classifying Information Systems Development Methodologies and Approaches," Journal of Management Information Systems (17:3), pp 179218. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J., and Kahkonen, T. 2004. "Agile Software Development in Large Organizations," Computer (37:12), December, pp 26-33. Maurer, F. 2002. "Supporting Distributed Extreme Programming," in: Extreme Programming and Agile Methods, XP/Agile Universe 2002: Second XP Universe and First Agile Universe Conference, August 4-7. Berlin: Springer-Verlag, pp. 13-22. Rajlich, V. 2006. "Changing the Paradigm of Software Engineering," Communications of the ACM (49:8), pp 67-70. Reeves, M., and Zhu, J. 2004. "Moomba - a Collaborative Environment for Supporting Distributed Extreme Programming in Global Software Development," in: Extreme Programming and Agile Processes in Software Engineering, XP 2004, J. Eckstein and H. Baumeister (eds.). Berlin: Springer-Verlag, pp. 38-50.

947



Reifer, D.J. 2002. "How Good Are Agile Methods?," IEEE Software (19:4), July/August, pp 16-18. Schummer, T., and Schummer, J. 2001. "Support for Distributed Teams in Extreme Programming," in: Extreme Programming Examined, G. Succi and M. Marchesi (eds.). Boston: Addison-Wesley Longman, pp. 355-377. Schwaber, K., and Beedle, M. 2002. Agile Software Development with Scrum. Upper Saddle River, New Jersey: Prentice Hall. Stapleton, J. 1997. DSDM Dynamic Systems Development Method. Harlow, England: Addison-Wesley. Strode, D.E. 2005. "The Agile Methods : An Analytical Comparison of Five Agile Methods and an Investigation of Their Target Environment : A Thesis Presented in Partial Fulfilment of the Requirements for the Degree of Master of Information Sciences in Information Systems " in: Department of Information Systems. Palmerston North, New Zealand: Massey University [http://hdl.handle.net/10179/515]. Wynekoop, J.L., and Russo, N.L. 1995. "Systems Development Methodologies: Unanswered Questions," Journal of Information Technology (10:2), pp 65-73. Xu, P., and Ramesh, B. 2007. "Software Process Tailoring: An Empirical Investigation," Journal of Management Information Systems (24:2), pp 293-328. Yin, R.K. 2003. Case Study Research, (3 ed.). Thousand Oaks: Sage Publications.

COPYRIGHT Diane E. Strode, Sid L. Huff and Alexei Tretiakov © 2008. The authors assign to ACIS and educational and nonprofit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a nonexclusive licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the authors.

948