Software development team flexibility antecedents

The Journal of Systems and Software 83 (2010) 1726–1734

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

Software development team flexibility antecedents Yuzhu Li a , Kuo-Chung Chang b,∗ , Houn-Gee Chen c , James J. Jiang d a

Decision & Information Sciences Department, University of Massachusetts at Dartmouth, USA Department of Information Management, Yuan Ze University, 135 Yuan-Tung Road, Chung-Li, Taiwan c Department of Business Administration, College of Management, National Taiwan University, Taiwan d School of Accounting and Business Information Systems, ANU College of Business and Economics, The Australian National University, Canberra, ACT 0200, Australia b

a r t i c l e

i n f o

Article history: Received 26 January 2010 Received in revised form 29 March 2010 Accepted 11 April 2010 Available online 15 June 2010 Keywords: Team flexibility Software quality Software development Dynamic capability Software project management Process Software skills

a b s t r a c t The ability to respond to changes in the environment during the development of software is crucial in achieving a quality product. Putting the project team together to achieve the ability to react effectively requires an understanding of the nature of flexibility and capabilities that might promote the ability to respond to changing requirements and conditions. Based on dynamic capability theory, we build a model of software quality that is dependent on the flexibility of the team, with the flexibility of the team dependent on reactive and anticipatory capabilities of the team members. A questionnaire administered to 119 software development team members indicates strong linkages from reactive capabilities and mixed results for anticipatory capabilities to team flexibility. Both flexibility components of a comprehensive response and efficient response to changes are critical in achieving quality software. The items comprising the capabilities can serve to guide management in building flexible development teams. © 2010 Elsevier Inc. All rights reserved.

1. Introduction Software development teams face a growing challenge to be adaptive to the continuously changing business needs and technical issues to deliver the desired systems on time and under budget (Lee and Xia, 2005; Mathieu et al., 2008; Olsson, 2006). Previous works on software development largely focused on the project managers’ responsibility for development process activities (e.g. planning, execution, and result appraisal) in an attempt to facilitate the control of the project (Buckle, 1984). In a static environment, the application of these practices is effective in helping manage the project as inherently stable requirements clearly define project outputs that remain set for the project’s duration. However, this traditional control approach becomes less effective as software projects now face growing disruptions in increasingly volatile socio-technical environments. In such settings, project planning and tracking are difficult as the outputs tend to evolve throughout the development process (Applegate et al., 2007). Therefore, subsequent research recognized the importance of software development team flexibility in responding to these uncertainties as a more critical factor in successful software development (Curtis et al., 1988; Gefen and Ridings, 2002; Lee and Xia, 2005; McComb et al., 2007).

∗ Corresponding author. E-mail address: [email protected] (K.-C. Chang). 0164-1212/$ – see front matter © 2010 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2010.04.077

For a decade, examinations of software development pay more attention to the adoption or development of a set of agile tools and methods, such as extreme programming, scrum, prototyping, JAD, and RAD (Fowler and Highsmith, 2001; Highsmith et al., 2001). Unfortunately, the effectiveness of these widely adopted agile tools and development methods remains elusive in the literature. For example, some studies indicate agile methods are effective at increasing development speed and customer satisfaction (Williams and Cockburn, 2003), while other studies assert that their effectiveness remains uncertain (Maruping and Venkatesh, 2009; Rumpe and Schröder, 2002; Turk et al., 2005). Despite the fact that attention and resources have been devoted to system development tools and methodologies, little is known about what capabilities a software development team should develop that lead to essential flexibility—effective and efficient responses to capricious environments. Current research lacks a theoretical explanation of how team flexibility explains the relationship between these proposed tools and methods in practice and a software development team’s flexibility. This research intends to fill this gap by employing the theory of dynamic capability as theoretical lens to elucidate what capabilities lead to team flexibility. Dynamic capability theory postulates a competence building and development scheme, describing the mechanisms from which flexibility is derived to hedge against high-velocity environments (Cepeda and Vera, 2007; Helfat and Peteraf, 2003; Kylaheido et al., 2000; Wang and Ahmed, 2007). By constantly transforming resources within an organization, dynamic capabilities result in the

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

development of a new configuration of resources and operational routines to deal with the volatile environments. Organizational flexibility is considered an outcome of dynamic capabilities over time. In spite of the dynamic capability concept being largely discussed at the organizational level, Eisenhardt and Martin (2000) suggested the dynamic capability perspective can be applied at multiple levels including the individual, team, department, firm, and network level. In other words, based upon dynamic capability theory, flexibility is an outcome of a software development team’s dynamic capability. This assertion has been overlooked in the in software development literature. The purpose of this study is, therefore, to examine the relationship between a team’s dynamic capability and flexibility. More specifically, based on dynamic capability theory, this study argues that dynamic capabilities lead to software development team flexibility, which in turn contributes to the enhancement of the quality of software being developed. Understanding of derived benefits can provide important guidelines in team building to improve software quality. 2. Background and theory 2.1. Software development team flexibility Flexibility refers to adaptation in response to environmental changes. It has been widely used in the context of strategic flexibility and manufacturing management as an ability to take up different maneuvers to response a range of changes (Sanchez, 1995; Wright and Snell, 1998). The strategic flexibility literature focused largely on the development of capabilities and options used to respond to a wide variety of changes in the competitive environment (Volberda, 1996). Manufacturing management research, on the other hand, defines flexibility as the ability of the organization to change with little effort in time and cost to respond to the changes due to a turbulent environment (Upton, 1995). Based on the conceptual frameworks defining what constitutes flexibility, Golden and Powell (2000) describe flexibility along four dimensions: efficiency, responsiveness, versatility and robustness. The first two dimensions represent the efforts and the time taken to respond to changes, while the latter two describe flexibility in terms of scope that an organization can respond to changes. In the information system literature, research on flexibility focused on the impact of IT on organizational flexibility. One stream of research postulates that the design of interconnected information technology architectures can provide the foundation for rapid response to changing market conditions within the organization and across organizations (Byrd and Turner, 2000; Richardson, 1996). Another stream of research suggests that creation of newer software development tools is a source of flexibility (Beck, 1999; Poppendeick, 2001). The extant literature on software development has acknowledged the significance of team flexibility; however, it seldom fleshes out what it is (Bernstein and Yuhas, 2005; McConnell, 1998; van Vliet, 1993). Though the concept of flexibility is extensive in organizational research, work focusing on developing flexibility at the group level is still in the early development stage. McComb et al. (2007) drew on research in strategic flexibility to develop a two-dimensional team flexibility scheme to include proactive and reactive classifications. While proactive flexibility refers to the effort that the team invests in the preparation for future changes, the reactive dimension considers the adjustments required for the team to respond to a triggering episode. When teams are proactively and reactively dealing with frequent environmental changes, they should be more capable of progressing toward a common goal. However, the concept of team flexibility in McComb et al.’s study was measured indirectly under a social-technical context, making it too general for team level specifics.

1727

Lee and Xia (2005), using a Delphi approach, identify the structure of software development team flexibility. Their findings suggested that software development team flexibility has two dimensions: response extensiveness and response efficiency. Response extensiveness is related to the range and variety of socio-technical changes to which a software development team is capable of responding. The efficiency of a software development team response refers to the additional efforts required by the software development team to manage the business and technology changes in terms of cost, time, and difficulty. In this study, we adopt Lee and Xia’s software development team flexibility representation and define software development team flexibility as the extent to which a software development team can effectively and efficiently respond to socio-technical changes in the course of a software development project. 2.2. Dynamic capability perspective Originally developed for the strategic management context, dynamic capabilities involve processes or mechanisms by which firms achieve new resource configurations as markets emerge, collide, split, evolve, and die (Eisenhardt and Martin, 2000). The concept of dynamic capability is an extension of the resource-based view (RBV). The essence of traditional RBV lies in the emphasis on bundles of heterogeneously-distributed resources and capabilities as the genesis of competitive advantage. However, the validity of the RBV as a theoretical framework of reference has been questioned for being static and for its failure to define mechanisms that explain how resources are transformed to competitive advantage (Priem and Butler, 2001; Williamson, 1999). In the RBV, the development and deployment of resources and abilities are historically dependent, being relevant to a certain time period but becoming more rigid and less germane when the environment changes. The holding of any particular resource or capability implies a singular and permanent adjustment to a newly transformed environment. In capricious environments, there is only temporary relief in developing a permanent response to environmental changes because subsequent environmental states are just as likely to reverse or to reshape the previous state as they are likely to reinforce it. Thus, resources and capabilities developed at a particular time period may eventually create a competency trap and be less capable of responding to unforeseen changes in the course of software development. In contrast to conventional RBV, the dynamic capability perspective considers competitive advantage of resources and capabilities that are continually expanded, upgraded, and improved through underlying processes or mechanisms that integrate, reconfigure, or even renew the component resources and competencies. In line with the strategic management literature, the dynamic capabilities in this study are defined as routines or mechanisms by which software development teams continuously integrate, reconfigure, and renew resources and competencies in response to the changing socio-technical environments. Two team dynamic capabilities are identified: reaction capabilities and anticipation capabilities (Verganti, 1999). Reaction capabilities refer to abilities to cope with unexpected constraints and changes late in the software development process at low cost and time (Verganti, 1999). Reaction capabilities are embedded in a variety of managerial mechanisms and routines. For example, software development teams can recruit team members who have similar project experiences and positive attitudes towards teamwork to help anticipate changes (Faraj and Sproull, 2000; Tesch et al., 2003). Other practices include the application of different techniques such as rapid prototyping, integrated design tools, and product data management systems to reduce the impact of unexpected changes from socio-technical environments. To develop reaction capabilities,

1728

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

organizations can also allocate substantial resources for experimentation purposes. While reaction capabilities provide a degree of freedom, options, or repertoires in an attempt to manage the unexpected changes in the later parts of the software development project, anticipation capabilities refer to the ability to proactively manage the potential requirement changes at the early phases of a software development project (Verganti, 1999). Team anticipation capabilities are rooted in a variety of planning mechanisms (i.e. systemic learning, team collaboration, and proactive thinking) that enable the software development team to forecast some of the future changes that will arise during the software development process. Anticipation capabilities are reflected in the team’s ability to capitalize on experiences derived from the development process of past projects, to involve stakeholders in the early phases of the software development process, and to effectively manage potential risks by utilizing user experience and team members’ domain knowledge. 2.3. Product quality Product quality can be defined as the totality of features and characteristics of software delivered to satisfy user needs (van Vliet, 1993). The quality of software is estimated by many of its attributes. Among them, reliability in terms of fault density or number of defects is a criterion commonly used for the evaluation of software quality (Briand et al., 2000; Li et al., 2010; Takahashi, 1997; Thwin and Quah, 2005). Other software attributes are also used for the estimation of software quality such as usability, integrity, portability, flexibility, reusability, interoperability, and efficiency (Gonzalez, 1995; Plant, 1995; Rai et al., 1998; Rawashdeh and Matalkah, 2006; van Veenendaal et al., 2007). These quality factors can be broadly categorized into three classes: operational efficiency, responsiveness, and flexibility (Subramanian et al., 2007; Nidumolu, 1995). Operational efficiency refers to the technical performance of the developed systems and contains those factors that pertain to the efficiency of the software after it has become operational. Highly efficient systems reflect quality in their reliability, integrity, and cost efficiency when operating. Responsiveness describes how well the deliverables respond to user needs. The quality of responsiveness is present when delivered systems are easy to use and can provide customized outputs. The quality of flexibility reflects the system’s ability to adapt to changing business needs, indicating that the delivered systems can quickly adapted to changes in business requirements with cost efficiency. It contains factors such as portability, reusability, and interoperability that reflect the ease with which a transition to a new environment can be made. To be consistent with the literature and to cover a broad scope of software quality measurement, we examined software quality from three different perspectives commonly employed in many studies: operational efficiency, responsiveness, and flexibility. 3. Hypotheses development Fig. 1 depicts the research model for this study. The model asserts that anticipation and reaction capabilities held by a software development team impact how well the team responds to changes arising from socio-technical environments in the course of the software development. This model also contends that a software development team’s capability to be flexible is related to the final quality of the product.

Fig. 1. Research model.

opment process are determinants of team flexibility. Anticipation capabilities provide preparedness for identifying possible problems and to incorporate the uncertainties as changes (Verganti, 1997, 1999). The literature provided evidence that the successful management of requirement uncertainty in the early design phase is significantly related to project success (Jiang and Klein, 2000). A software development team can learn to anticipate the possible technological changes by watching recent technological innovations and by managing the technology risks. The team can work with the users to support proactive thinking, consider possible business changes, and generate more choices as solutions in case the changes really happen. Effective techniques of anticipating the technological and business changes include prototyping, user involvement, and effective communication with various stakeholders (Barki and Jon, 1989). When the technological and business changes occur and new requirements must be incorporated into the system, the software development team can find a solution more quickly because of the proactive thinking—and available choices enable the software development team to respond in a comprehensive fashion when the new features or changes must be added to the system. Therefore, we hypothesize: H1. Anticipation capability will have a positive relationship with the software development team’s flexibility H1a. Anticipation capability will have a positive relationship with the software development team’s response extensiveness H1b. Anticipation capability will have a positive relationship with the software development team’s response efficiency In addition, we argue that the software development team’s reaction capabilities have significant impacts on its flexibility. The software development team that reacts quickly to changes usually has substantial software development resources and strong communication and coordination capability (Jiang and Klein, 2000; Nidumolu, 1995). The resources involved in the software development process include highly skilled team members and integrated technology tools. Highly skilled users and developers have rich experiences in business and technology in order to make right decisions in new situations. Therefore, response extensiveness can be achieved. Intensive team communication and coordination accelerate integrated problem solving. New changes can be implemented in an efficient way. The above argument supports the following hypotheses. H2. Reaction capability will have a positive relationship with the software development team flexibility.

3.1. Dynamic capabilities and team flexibility

H2a. Reaction capability will have a positive relationship with the software development team’s response extensiveness.

In this study, we argue that a software development team’s abilities to anticipate problems emerging in the software devel-

H2b. Reaction capability will have a positive relationship with the software development team’s response efficiency.

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

1729

Table 1 Demographic analysis. Variables

Categories

Gender

Male Female No reply Project member System/business analyst Project leader IT manager Program manager Client Product director Product manager IT director Other Missing

Position

# 85 31 3 62 3 14 12 10 1 1 6 3 2 5

%

Variables

Categories

71.4 26.1 2.5 52.1 2.5 11.8 10.1 8.4 0.8 0.8 5.0 2.5 1.7 4.2

Average project duration

<1 year 1–2 years 2–3 years 3–5 years ≥6 years No reply IT industry Non-IT industry No reply ≤50 50–500 500–1000 >1000 Missing

– Industry

Company size

# 47 40 15 7 1 9 66 44 9 38 58 5 11 7

% 39.5 33.6 12.6 5.9 0.8 7.6 55.5 36.9 7.6 31.9 48.7 4.2 9.2 5.9

3.2. Software development team flexibility and product quality

4.2. Operationalization

Response extensiveness refers to the range and variety of sociotechnical changes to which a software development team is capable of responding. Teams with high responsive flexibility have a broad knowledge base, which allows the software development teams to quickly provide solutions and make a good estimation of the change’s scope. Consequently, the teams are better equipped to meet adjusted user expectations. The correct estimation of change scope reduces the possibility of software defects and bugs and leads to a high level of software quality. Based on the aforementioned statements, we hypothesize:

All research variables were measured using validated measurements. A 5-point Likert scale was used for all measures with anchors ranging from 1 (strongly disagree) to 5 (strongly agree). The scales for anticipation capability and reaction capability were adapted from Verganti (1997, 1999). The items measuring the two dimensions of software development team flexibility were adopted from Lee and Xia (2005). Items measuring software quality were adopted from Nidumolu (1995). Requirement uncertainty and technology uncertainty were included as control variables in the model for flexibility is only needed when there is uncertainty in the application development process. Scales for requirement uncertainty and technology are assessed using the existing scale from Nidumolu (1995). Table 2 presents the items employed in this study. Because all target respondents were located in China, the survey was first translated to Chinese. The translation work was done by a researcher and validated by second researcher not involved with this study and fluent with both English and Chinese. The validated Chinese survey was then corroborated by a two experienced software project managers. Some minor revisions were required before the survey was delivered. The survey instrument was pilot tested and modified based upon initial feedback and questions on the items.

H3. The software development team’s response extensiveness will have a positive relationship with software quality. Software development teams with flexibility have the capability to respond to changes in an efficient way because of the team design and resource allocation. The rich experiences and effective communication enable the highly skilled team members to know the key barriers of the change process, develop the solutions with few mistakes and utilize the available resources to a maximum extent. In this way, the software development project team is competent in accomplishing the changes in the economic sense and achieving the high level of software quality at the same time. Based on the aforementioned statements, we hypothesized the following: H4. The software development team’s response efficiency will have a positive relationship with software quality.

4. Research method 4.1. Sample A survey design was selected to collect data and test the proposed model. The sample of this study is from an Alumni list of a prestigious Chinese University. This university in China has a high reputation for its IT/MIS undergraduate education and its graduates are highly recruited by diversified industries. Target respondents of this study are members of software development teams. A survey package, including a cover letter and a questionnaire, was sent to the alumni who work in IT-related fields. The purpose of this study and the instruction in filling out the survey were provided as part of the package. Each respondent completed the survey and returned the instrument directly to the researcher. Personal contacts and phone calls were made to encourage participation. Follow-up calls and reminder emails were sent out 2 weeks after the initial contacts. Table 1 shows the demographics of the final sample.

4.3. Data collection A total of 179 teams from the sampling pool showed willingness to participate in this study, from which 129 teams returned the survey. Out of the received responses, questionnaires from 10 teams were incomplete and thus were discarded from the sample. This results in a final data set of 119 observations. A non-response bias analysis was performed by comparing the demographic data in this study with prior studies (Jiang et al., 2003; Li et al., 2003). The result shows that respondent characteristics among these studies are similar. Because independent and dependent variables are from the same rater, common method variance might jeopardize the analysis (Podsakoff et al., 2003). Harman’s single factor test was used to test for common method variance. The result indicated that no one factor can represent all indicators, and so common method variance is not evident in this study. 4.4. Measurement model Item reliability, convergent validity, and discriminant validity tests were employed to examine the measurement model. Individual item reliability was examined by observing the factor loading of each item. High loadings imply that the shared variance between constructs and its measurement is higher than error variance

1730

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

Table 2 Construct items and reliability measures. Items

Loading

Reaction capabilities (CR = 0.82; ˛ = 0.74) 1. This project team tries to recruit highly skilled members who have done similar projects previously 2. Rapid prototyping is used to foresee possible problems and changes 3. Integrated design tools are used to develop the product 4. Product data management systems are used to manage the development process 5. Resources are overallocated for experimentation purpose

0.75 0.64 0.68 0.79 0.59

Anticipation capabilities (CR = 0.87; ˛ = 0.82) 1. This project team has been focusing on capitalization of experience in the development process of past projects 2. A variety of stakeholders such as users, project managers and senior management participate in the early phase of the product development process 3. This project team tries its best to proactively manage the possible risks in project size (including number of stakeholders, number of users) 4. This project team tries its best to proactively manage the possible risks by utilizing user experience on software development (including past experiences with software development, data processing tools and this particular type of application) 5. This project team tries its best to proactively manage the possible risks by utilizing team members’ domain knowledge (in-depth understanding of the user department, organizational operation and this particular application) Response extensiveness (2nd order construct) Response extensiveness to business changes (CR = 0.86; ˛ = 0.82) 1. System scope 2. Delivery time 3. System input data 4. Business rules/processes 5. Data Structure 6. User Interface

0.72 0.73 0.87 0.80

0.64

0.77 0.65 0.67 0.73 0.73 0.69

Response extensiveness to technology changes (CR = 0.94; ˛ = 0.86) 7. Programming tools/languages 8. IT architecture 9. Network/telecom environment 10. Other interface systems 11. IT infrastructure

0.88 0.88 0.88 0.78 0.89

Response efficiency (2nd order construct) Response efficiency to business changes (CR = 0.88; ˛ = 0.84) 1. System scope 2. Delivery time 3. System input data 4. Business rules/processes 5. Data structure 6. User interface

0.74 0.69 0.70 0.78 0.79 0.70

Response efficiency to technology changes (CR = 0.90; ˛ = 0.91) 7. Programming tools/languages 8. IT architecture 9. Network/telecom environment 10. Other interface systems 11. IT infrastructure Product quality (2nd order construct)

0.69 0.74 0.83 0.86 0.87

Operational efficiency (CR = 0.90; ˛ = 0.86) 1. The software is reliable 2. The cost of software operations is efficient 3. There was a quick response time in the project 4. The client is satisfied with the overall operational efficiency of the software

0.83 0.84 0.82 0.82

Flexibility (CR = 0.85; ˛ = 0.75) 5. The projects adapted software to changes in business with cost efficiency 6. The projects rapidly adapted software to changes in business requirements 7. The projects achieved overall long-term flexibility of software

0.77 0.83 0.83

Responsiveness (CR = 0.89; ˛ = 0.82) 8. The software is easy to use 9. The projects were able to customize outputs to various client needs 10. The software is responsive overall to client needs

0.87 0.81 0.87

Requirement uncertainty (control variable) (CR = 0.85; ˛ = 0.75) 1. Requirements fluctuated quite a bit in later phase of the development process 2. Requirements identified at beginning of this project were quite different from those existing at end 3. Requirements will fluctuate quite a bit in the future

0.86 0.82 0.74

Technology uncertainty (control variable) (CR = 0.90; ˛ = 0.85) 1. There is a clearly known way to develop IT product that would meet these requirements specifications 2. Available knowledge is of great help in developing IT product that will meet these requirements specifications 3. Established procedures and practices can be relied upon to develop IT product that will meet these requirements specifications 4. An untreatable sequence of steps can be followed for developing IT product to meet these requirements specification

0.80 0.87 0.89 0.76

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

1731

Table 3 Descriptive statistics. Variables

Mean

SD

M3

M4

Product quality (PQ) Extensiveness (EX) Efficiency (EF) Reaction capabilities (RC) Anticipation capabilities (AC) Requirement uncertainty (RU) Technology uncertainty (TU)

3.66 3.65 3.32 3.29 3.37 3.43 3.75

0.72 0.67 0.85 0.82 0.82 0.82 0.68

−0.32 −0.37 −0.22 −0.35 −0.56 0.08 −1.33

−0.27 −0.06 −0.69 0.03 −0.32 −0.61 3.75

(Hulland, 1999). Consistently high factor loadings can be viewed as indicators of high reliability. Convergent validity should be assured when multiple indicators are used to measure a single construct. It can be examined by the construct reliability of the questions, composite reliability of constructs, and variance extracted by constructs (AVE) (Fornell and Larcker, 1981). Construct reliability is shown by Cronbach’s alpha. Composite reliability (CR) of constructs is calculated by squaring the sum of loadings then dividing it by the sum of squared loadings plus the sum of the error terms (Werts et al., 1974). AVE, proposed by Fornell and Larcker (1981), reflects the variance captured by indicators. If the AVE is less than 0.5, the variance captured by the construct is less than the measurement error and the validity of single indicator and construct is questionable (Fornell and Larcker, 1981). Discriminant validity focuses on testing whether the measures of constructs are different from each other (Messick, 1980). It can be assessed by testing whether the square root of AVE is larger than correlation coefficients (Chin, 1998; Fornell and Larcker, 1981). Table 2 shows that. As shown in Table 2, all indicators in this study have loadings higher than the level recommended for dropping items from a scale (<0.5; Hulland, 1999). All composite reliability alpha values exceed the recommended minimums of 0.7 (Fornell and Larcker, 1981). As indicated in Table 3, the square root of the AVEs in the diagonal of the correlation matrix exceed the threshold of 0.707 and the AVEs are greater than the inter-construct correlations (off diagonal elements). The results exhibit strong construct reliability and validity. Table 3 also shows the descriptive statistics.

Correlation matrix PQ

EX

EF

RC

AC

RU

TU

0.90 0.43 0.34 0.47 0.66 −0.12 0.55

0.89 0.73 0.46 0.37 0.26 0.20

0.93 0.45 0.36 0.22 0.24

0.69 0.53 −0.03 0.16

0.75 0.04 0.40

0.81 0.05

0.70

Table 4 Hypotheses test coefficients. Coefficient

Extensiveness

Efficiency

Software quality

Reaction capabilities (RC) Anticipation capabilities (AC) Extensiveness (EX) Efficiency (EF)

0.39* 0.16 – –

0.36* 0.21* – –

– – 0.23* 0.19*

*

Significant at p < 0.05.

construct and then using the computed first-order factor scores as indicators of the second-order constructs to estimate the path coefficients (Agarwal and Karahanna, 2000; Yi and David, 2003). Given the relatively small sample size, a test of statistical power for the proposed links was conducted, the results indicated that the power of each proposed hypothesis were all above the recommended value of 0.80. The results of path analysis, Table 4, show the hypothesized relationship between anticipation capability and response effectiveness, though positive, is not significant, falsifying H1a. Support was found for the hypothesized influence of anticipation on response efficiency, validating H1b. As hypothesized, reaction capability is positively associated with team flexibility, supporting H2. Consistent with H3 and H4, team flexibility has positive and significant effect on software quality. Therefore, all the proposed hypotheses were supported except H1a. 58.8% of the variance in software quality was explained by the research model. 5. Discussion and implications

4.5. Structural model analysis Since we have a relatively small sample size (119 observations), the partial least square (PLS) method of structural equation modeling (PLS Graph 3.0) was chosen for data analysis (Chin, 1998). PLS assumes a component-based method and involves multiple steps in estimating the model parameters in question (Chin et al., 2003). Each step of the procedure minimizes a residual variance with respect to a subset of the parameters being estimated given proxies of fixed estimates for the other parameters. This components-based analytical strategy does not depend on having multivariate normal distributions or a large sample size. In order to determine the precision of estimation in our PLS estimation, minimum sample size checks and a reactive Monte Carlo analysis were performed (Chin, 1998). First, our sample size of 119 exceeded the recommended minimum of 50 deemed adequate for model testing. Second, a bootstrapping procedure with resampling of 200 subsamples was used to determine the statistical significance of the parameter estimates (Chin, 1998). Since the research model is comprised of higher order latent constructs and PLS Graph 3.0 cannot directly represent secondorder latent constructs, a two-step procedure was performed to test the structural model. The path model was indirectly evaluated by testing the first-order constructs comprising a second-order

Based on a dynamic capability view, this study considers that two forms of dynamic capabilities (anticipation capability and reaction capability) contribute to software development team flexibility, which in turn impacts the quality of the system developed. Based upon a survey of 119 software development teams, results show that team flexibility is observed to have positive impacts on software quality. Reaction capability is positively associated with both response extensiveness and response efficiency components of flexibility. However, anticipation capability positively relates to response efficiency but does not have significant effect with response extensiveness. The results of this study have several implications for software development researchers. First, extant research consistently shows the importance of a software development team’s flexibility to software development performance in an increasingly turbulent business environment and pays substantial attention to technology or methodology-related factors that lead to the rise of team flexibility, particularly restricting their attention to the application of agile tools and methodologies. More recently, however, software development researchers have increasingly acknowledged that effective team response to growingly volatile changes in the course of development hinges not solely on the use of agile software development tools but on the interaction between these tools

1732

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

and other factors. These studies have discovered a wide range of team processes, practices, or routines pertinent to the emergence of team flexibility such as skilled human resources (Iansiti, 1995), systemic learning (Verganti, 1997), team work and communication (Verganti, 1999), design architecture investment (MacCormack et al., 2001), control modes (Maruping et al., 2009a), and expertise coordination (Maruping et al., 2009b). Moreover, the majority of the extant research is qualitative, based on single or multiple case studies. Additionally, no theory had been imparted to explain how these resources are brought to bear on team flexibility. By applying a dynamic capability perspective, this study advances our understanding on the development of team flexibility in that dynamic capabilities serve as underlying antecedents and team flexibility is an outcome of dynamic capabilities over time. This perspective is different from that of the traditional RBV in that the presence of resources is insufficient to enhance a software development team’s response ability. It is the constant integration, reconfiguration, renewal, and recreation of myriad resources existing within and outside the team boundary that increase a team’s ability to effectively respond to discrete and unexpected events amid the development process. Secondly, results show that anticipation capabilities and reaction capabilities are critical to the development of team flexibility. This result implies that software development teams should properly combine them as a whole to manage the mutable environments for the entire software development process. Essentially, reaction capability is most effective in the management of the emergent variation in the latter parts of the software project cycle. Reaction capability is critical because it involves a variety of mechanisms (i.e. multi-disciplinary teams), routines (i.e. modular architecture), and tools (i.e. integrated design tools) to provide a degree of freedom, option, or repertoire that renders the team able to rapidly introduce corrective actions at a lower cost to cope with a variety of unexpected changes taking place. While reaction capability is focused on the latter part of the development process, anticipation capability is expected to contribute to team flexibility through proactive measures performed in the early phases. Unlike reaction capability, anticipation capability is a project-specific capability. The planned mechanisms and routines (i.e. critical area identification, early involvement of major shareholders, systemic learning, and alternative solutions) characterizing anticipation capabilities focus on the idiosyncrasy of each software development project in terms of projects goals, stakeholders involved, and client needs. These anticipation-oriented practices and routines enable the software development team to analyze and identify the critical areas that are uncertain or likely to change. With anticipation plans, software development teams have greater ability to effectively and proactively allocate resources and to undertake late corrective actions in response to unexpected events at lower cost and time expenditures. Consequently, anticipation capability allows the software development teams to cope with the emergent uncertainty efficiently. However, the result of this study also shows that anticipation capability is less effective in developing a team with an all-encompassing ability to swiftly respond to potential changes in the course of software development. One plausible explanation would be that the aim of anticipation capability is not to forecast all potential changes that will arise during the software development process, but to identify critical areas of a given software development project so that vital decisions such as detailed system specification or system architecture can be conducted in later implementation phases. These proactive-oriented measures render a high degree of freedom in taking late decisions to manage those critical areas. Consequently, the effect of anticipation capability on response effectiveness is reflected through triggering corrective actions taken in later phases of the development process. Therefore,

the result does not necessarily mean that anticipation capability is unimportant to response effectiveness. On the contrary, it could be that anticipation capability and reaction capability are interdependent and mutually reinforce each other. There are also several implications to software development managers. First, the role of project leader becomes dynamic. In the initial phase of the development process, the role of project managers, as traditionally defined, is more like a rational planner proactively managing social and technical processes. They need to plan for the team structure, making sure that key stakeholders are included on the team. They also need to define the time line and milestones of the project, identify system requirements and specification, and secure necessary resources so as to implement the project. However, as uncertainty emerges when the project proceeds into the later phases of the development process, project managers serve more as surfers on waves of change that focus on solving problems and meeting challenges as they emerge. Learning and adaptation are crucial to identifying and taking advantage of unforeseen situations. The project manager maintains liaison among stakeholders, negotiates new meanings and visions. The flexibility in project management at these stages includes making compromises about short-term goals and strategies, and being a steward of a long-term vision. Secondly, software development teams need to pay more attention to relationship management and build up dynamic capability. A software development team should develop robust relationships with potential knowledge and contact sources so that when recourses are needed, it can access and integrate them. This is particularly true when the resources and abilities required to solve the problems reside outside the team. For example, software development teams may need support from higher-ups to provide additional financial and technical aids to deal with unexpected changes in the future. With strong vertical relationships, the software development team should more easily find necessary human resources (i.e. recruit new members from the market, reassign members of other software development teams, or send group members to attend relevant trainings) to bring requisite skills and knowledge in support of the sociotechnical changes. Good lateral relationships with other units (i.e. departments or software development teams) in the organization may also allow the team to access tacit knowledge and skills associated with business and technical changes. The software development team may even develop good relationships with extra-organizational entities (e.g. professional associations, industry associations, vendors, consultants, and research institutes) as the focal organization may not have the resources or capabilities required to achieve flexibility. Having good market relationships provides an important conduit through which the software development teams are exposed to innovative software development technologies unavailable from within the organization. There are a number of limitations to this study. First, the sample frame used in this study is certainly not random because the companies included in the study come from the alumni database of a single university in China. Potential data bias may exist that restrain generalizability of the findings due to culture influence and localized business practices. Second, although the power test conducted in this study indicated there was a enough power to test the proposed hypotheses, the relatively small sample size is a limitation. Third, cross-sectional surveys as used by this study have limitations in attributing and substantiating affirmative causality. Finally, although the results of this study were encouraging, the perception-based software quality measurement might be different from an objective measure. Future studies are encouraged to adopt objective measures to validate and generalize the findings of this study.

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

Acknowledgement This research is partly funded by National Science Council at Taiwan under the project NSC-98-2410-H-002-072-MY2. References Agarwal, R., Karahanna, E., 2000. Time flies when you’re having fun: cognitive absorption and beliefs about information technology usage. MIS Quarterly 24 (4), 665–694. Applegate, L.M., Austin, R.D., McFarlan, F.W., 2007. Corporate Information Strategy and Management: Text and Cases, 7th ed. McGraw-Hill, New York. Barki, H., Jon, H., 1989. Rethinking the concept of user involvement. MIS Quarterly 13 (1), 53–63. Beck, K., 1999. Embracing change with extreme programming. IEEE Computer 32 (10), 70–77. Bernstein, L., Yuhas, C.M., 2005. Trustworthy Systems Through Quantitative Software Engineering. John Wiley & Sons, Hoboken, NJ. Briand, L.C., Wüst, J., Daly, J.W., Porter, D.V., 2000. Exploring the relationships between design measures and software quality in object-oriented systems. The Journal of Systems and Software 51, 245–273. Buckle, J.K., 1984. Managing Software Projects. Robert E. Krieger Publishing Company, Malabar Florida. Byrd, T.A., Turner, D.E., 2000. Measuring the flexibility of information technology infrastructure: exploratory analysis of a construct. Journal of Management Information Systems 17 (1), 167–208. Cepeda, G., Vera, D., 2007. Dynamic capabilities and operational capabilities: a knowledge management perspective. Journal of Business Research 60, 426–437. Chin, W.W., 1998. The Partial Least Squares Approach to Structural Equation Modeling. Lawrence Erlbaum, Mahwah, NJ. Chin, W.W., Marcolin, B.L., Newsted, P.R., 2003. A partial least squares latent variable modeling approach for measuring interaction effects: results from a Monte Carlo simulation study and an electronic mail emotion/adoption study. Information Systems Research 14 (2), 189–217. Curtis, B., Krasner, H., Iscoe, N., 1988. A field study of the software design process for large systems. Communications of the ACM 31 (11), 1268–1287. Eisenhardt, K.M., Martin, J.A., 2000. Dynamic capabilities: What are they? Strategic Management Journal 21 (10/11), 1105–1121. Faraj, S., Sproull, L., 2000. Coordinating expertise in software development teams. Management Science 46 (12), 1554–1568. Fornell, C., Larcker, D.F., 1981. Evaluating structural equation models with unobservable variables and measurement error. Journal of Marketing Research 18 (1), 39–50. Fowler, M., Highsmith, J., 2001. Agile methodologists agree on something. Software Development (9), 28–32. Gefen, D., Ridings, C.M., 2002. Implementation team responsiveness and user evaluation of customer relationship management: a quasi-experimental design study of social exchange theory. Journal of Management Information Systems 19 (1), 47–69. Golden, W., Powell, P., 2000. Towards a definition of flexibility: In search of the holy grail? Omega 28, 373–384. Gonzalez, R.R., 1995. A unified metric of software complexity: measuring productivity, quality, and value. Journal of Systems and Software 29, 17–37. Helfat, C.E., Peteraf, M.A., 2003. The dynamic resource-based view: capability lifecycles. Strategic Management Journal 24, 997–1010. Highsmith, J., Cockburn, A., Boehm, B., 2001. Agile software development: the business of innovation (cover story). Computer 34 (9), 120. Hulland, J., 1999. Use of partial least squares (PLS) in strategic management research: a review of four recent studies. Strategic Management Journal 20 (2), 195–204. Iansiti, M., 1995. Shooting the rapids: managing product development in turbulent environments. California Management Review 38 (1), 37–58. Jiang, J., Klein, G., 2000. Software development risks to project effectiveness. Journal of Systems and Software 52 (1), 3–10. Jiang, J.J., Klein, G., Pick, R.A., 2003. The impact of IS department organizational environments upon project team performances. Information and Management 40 (3), 213–220. Kylaheido, K., Sandstom, J., Virkkunen, V., 2000. Dynamic capability view in terms of real options. International Journal of Production Economics 80, 65–83. Lee, G., Xia, W., 2005. The ability of information systems development project teams to respond to business and technology changes: a study of flexibility measures. European Journal of Information Systems 14 (1), 75–92. Li, Z., Alaeddine, N., Tian, J., 2010. Multi-faceted quality and defect measurement for web software and source contents. Journal of Systems and Software 83, 18–28. Li, E.Y., Jiang, J., Klein, G., 2003. The impact of organizational coordination and climate on marketing executives’ satisfaction with information systems services. Journal of the Association for Information Systems 4, 99–117. MacCormack, A., Verganti, R., Iansiti, M., 2001. Developing products on Internet time: the anatomy of a flexible development process. Management Science 47 (1), 133–150. Maruping, L.M., Venkatesh, V., 2009. A control theory perspective on agile methodology use and changing user requirements. Information Systems Research 20 (3), 1–23. Maruping, L.M., Venkatesh, V., Agarwal, R., 2009a. A control theory perspective on agile methodology use and changing user requirements. Information Systems Research 20 (3), 377–402.

1733

Maruping, L.M., Zhang, X., Venkatesh, V., 2009b. Role of collective ownership and coding standards in coordinating expertise in software project teams. European Journal of Information Systems 18, 335–371. Mathieu, J., Maynard, M.T., Rapp, T., Gilson, L., 2008. Team effectiveness 1997–2007: a review of recent advancements and a glimpse into the future. Journal of Management 34 (3), 410–476. McComb, A.S., Green, S.G., Compton, W.D., 2007. Team flexibility’s relationship to staffing and performance in complex projects: an empirical analysis. Journal of Engineering and Technology Management, 293–313. McConnell, S., 1998. Software Project Survival Guide. Microsoft Press, Washington. Messick, S., 1980. Test validity and the ethics of assessment. American Psychologist 35 (11), 1012–1027. Nidumolu, S., 1995. The effect of coordination and uncertainty on software project performance: residual performance risk as an intervening variable. Information Systems Research 6 (3), 191–219. Olsson, N.O.E., 2006. Management of flexibility in projects. International Journal of Project Management 24 (1), 66–74. Plant, R., 1995. Guest Editor’s corner: special issue on software quality in knowledgebased systems. Journal of Systems and Software 29, 197–198. Podsakoff, P.M., MacKenzie, S.B., Lee, J.-Y., Podsakoff, N.P., 2003. Common method biases in behavioral research: a critical review of the literature and recommended remedies. Journal of Applied Psychology 88 (5), 879–903. Poppendeick, M., 2001. Lean programming. Software Development 9, 71–75. Priem, R.L., Butler, J.E., 2001. Is the resource-based ‘View’ a useful perspective for strategic management research? Academy of Management Review 26 (1), 22–40. Rai, A., Song, H., Troutt, M., 1998. Software quality assurance: an analytical survey and research prioritization. Journal of Systems and Software 40, 67–83. Rawashdeh, A., Matalkah, B., 2006. A new software quality model for evaluating COTS components. Journal of Computer Science 2 (4), 373–381. Richardson, J., 1996. Vertical integration and rapid response in fashion apparel. Organization Science 7 (4), 400–412. Rumpe, B., Schröder, A., 2002. Quantitative survey on extreme programming projects. In: Proceedings of Third International Conference on Extreme Programming and Flexible Processes in Software Engineering, Alghero, Italy, pp. 95–100. Sanchez, R., 1995. Strategic flexibility in product competition. Strategic Management Journal 16, 135–159. Subramanian, G.H., Jiang, J.J., Klein, G., 2007. Software quality and IS project performance improvements from software development process maturity and IS implementation strategies. Journal of Systems and Software 80, 616–627. Takahashi, R., 1997. Software quality classification model based on McCabe’s complexity measure. Journal of Systems and Software 38, 61–69. Tesch, D., Jiang, J., Klein, G., 2003. The impact of information system personnel skill discrepancies on stakeholder satisfaction. Decision Sciences 34 (1), 107–129. Thwin, M.M.T., Quah, T., 2005. Application of neural networks for software quality prediction using object-oriented metrics. The Journal of Systems and Software 76, 147–156. Turk, D., France, R., Rumpe, B., 2005. Assumptions underlying agile softwaredevelopment processes. Journal of Database Management 16 (4), 62. Upton, D.M., 1995. Flexibility as process mobility: the management of plant capabilities for quick response manufacturing. Journal of Operations and Management 12, 205–224. van Veenendaal, E., Hendriks, R., van Vonderen, R., 2007. Measuring software product quality. In: Carroll, S., Daughtrey, T. (Eds.), Fundamental Concepts for the Software Quality Engineer, vol. 2. ASQ Quality Press, Milwaukee, pp. 199–210. van Vliet, H., 1993. Software Engineering: Principle and Practice. John Wiley & Sons, New York. Verganti, R., 1997. Leveraging on systemic learning to manage the early phases of product innovation projects. R&D Management 27 (4), 377. Verganti, R., 1999. Planned flexibility: linking anticipation and reaction in product development projects. Journal of Product Innovation Management 16 (4), 363–376. Volberda, H.W., 1996. Toward the flexible form: how to remain vital in hypercompetitive environments. Organization Science 7 (4), 359–374. Wang, C.L., Ahmed, P.K., 2007. Dynamic capabilities: a review and research agenda. The International Journal of Management Reviews 9 (1), 31–51. Werts, C.E., Linn, R.L., Joreskog, K.G., 1974. Intraclass reliability estimates: testing structural assumptions. Educational and Psychological Measurement 34 (1), 25–33. Williams, L., Cockburn, A., 2003. Agile software development: it’s about feedback and change. Computer 36 (6), 39. Williamson, O.E., 1999. Strategy research: governance and competence perspectives. Strategic Management 20 (12), 1087–1108. Wright, R.M., Snell, S.A., 1998. Toward a unifying framework for exploring fit and flexibility in strategic human resource management. Academy of Management Review 23 (4), 756–772. Yi, M.Y., David, F.D., 2003. Developing and validating an observational learning model of computer software training and skill acquisition. Information Systems Research 14 (2), 146–169. Yuzhu Li is an assistant professor of Department of Decision and Information Sciences at University of Massachusetts at Dartmouth. She received her Ph.D. in management information systems (MIS) at University of Central Florida, Orlando, FL and master of technology management at Washington State University, Pullman, WA. Her research area includes project management, particularly project team work

1734

Y. Li et al. / The Journal of Systems and Software 83 (2010) 1726–1734

processes, technology-mediated learning, and the use of IT in organizations. Her work has been published in journals such as Information and Management, Informing Science Journal and The International Journal of Networking and Virtual Organization. Kuo-Chung Chang is an assistant professor of the Department of Information Management at Yuan Ze University, Taiwan, ROC. He received his Ph.D. from the University of South Carolina, USA. His current research focuses on IS project management, information systems outsourcing, and knowledge management. His work has been published in journals such as Information and Management and Industrial Management and Data Systems. Houn-Gee Cheng is a professor of business administration at National Taiwan University, Taiwan. He received his Ph.D. from the University of Wisconsin. His research interests are information technology management, knowledge management, ser-

vice innovation, and supply chain management. He has published over 70 articles in academic journals such as Information & Management, International Journal of Project Management, IEEE Transactions on Systems Men & Cybernetics, IEEE Transactions on Engineering Management, Journal of Systems & Software, Decision Support Systems, Journal of Association of Information Systems, and Decision Sciences. James J. Jiang is a distinguish research professor of information systems at the Australian National University, Australia. He obtained his Ph.D. from the University of Cincinnati. His research interests include IS project management and IS service quality management. He has published over 140 academic journal articles in these areas. He has served on the editorial boards of Information & Management, International Journal of Information Technology Project Management, Journal of Computer Information Systems, Information Resources Management Journal, and MIS Quarterly.