Examining the Effects of Agile Methods and Process Maturity on Software Product Development Performance

Abstract

This paper examines the effects of agile methods and software process maturity on software product development performance.
Through a mail survey, we obtained data from 72 small and medium-sized software firms that predominantly were not CMMI-certified.
Findings from our partial least squares analysis suggest that the use of agile methods has a positive impact on product development
efficiency and effectiveness, but CMMI practices do not have this effect. Our results suggest that software process improvement
initiatives in software product firms create the highest benefits through first adopting agile methods and only then moving
on to implementing CMMI-like process improvement initiatives.

Full text

B. Regnell, I. van de Weerd, and O. De Troyer (Eds.): ICSOB 2011, LNBIP 80, pp. 85–97, 2011.
© Springer-Verlag Berlin Heidelberg 2011
Examining the Effects of Agile Methods and Process
Maturity on Software Product Development Performance
Mikko Rönkkö, Juhana Peltonen, and Christian Frühwirth
Software Business Lab, Aalto University
FI-00076 Aalto, Finland
{Mikko.Ronkko,Juhana.Peltonen,Christian.Fruehwirth}@Aalto.fi
Abstract. This paper examines the effects of agile methods and software
process maturity on software product development performance. Through a
mail survey, we obtained data from 72 small and medium-sized software firms
that predominantly were not CMMI-certified. Findings from our partial least
squares analysis suggest that the use of agile methods has a positive impact on
product development efficiency and effectiveness, but CMMI practices do not
have this effect. Our results suggest that software process improvement
initiatives in software product firms create the highest benefits through first
adopting agile methods and only then moving on to implementing CMMI-like
process improvement initiatives.
Keywords: Product development, agile methods, process improvement,
software.
1 Introduction
The performance of agile information systems development methods has received
considerable interest among information systems scholars [e.g., 1-3]. However, the
current level of empirical support for the arguments about performance of agile
methods can be considered to be inadequate [4]. In this paper, we compare the effects
of agile software development practices and process maturity on the firm software
product development performance.
Research has provided us with strong evidence of the positive effect of process
maturity on software development performance [5, 6]. These studies have pre-
dominantly focused on process maturity from a more traditional CMMI perspective.
However, recently the use of agile methods has gained popularity in the software
industry. These methods have been advocated as a solution to problems in software
development [7-10] in a dynamic environment such as the software product industry
[11, 12]. Regardless of the relative popularity of this alternative development
approach, only a limited amount of research compares agile methods with other
development approaches [13]. Clearly, more studies comparing the effectiveness of
different development approaches are needed. Moreover, a large share of the studies
testing the performance of CMMI uses data from CMMI appraisals that are used
predominantly by larger firms [14]. While the CMMI based approach on software

86 M. Rönkkö, J. Peltonen, and C. Frühwirth
process improvement is well suited for large project-based development organizations,
the effectiveness of different development approaches in small firm context is currently
under-studied.
In this paper we investigate the following research question: “What is the impact of
process maturity and use of agile practices on software product development
performance?” This paper addresses two important gaps in the present body of
knowledge: First, we conduct a statistical comparative test between the effects of
process maturity and agility on software product development performance. To our
knowledge, only a few comparative studies like this exist [e.g., 13]. Second, in
contrast to previous studies using projects in larger firms, our sample consist of small
and medium sized firms that develop software products hence extending the
generalizability of previous studies.
The rest of the paper is organized as follows. In the second section we briefly
review the key literature and formulate hypotheses for testing. The next sections
introduce our sample, constructs and measures that are followed by data collection
and analysis. Thereafter, the sixth section introduces the results of hypothesis testing
using structural equation modeling. The final section presents a discussion on our
results and on their broader implications.
2 Literature Review and Hypothesis Development
Compatibility of agile development and process maturity has been of interest for the
information systems community. Agile methods were initially seen as alternative,
contradicting ways to develop software that are based on profoundly different values
and principles [15]. While agile development and process maturity were initially often
considered to be incompatible targets, information systems and software engineering
communities have recently started to consider these as more compatible than
conflicting targets [15-18].
Process maturity, often measured through frameworks such as CMMI, refers to the
degree of use of well-established software engineering methods [19]. Development
organizations often strive for maturity to improve the quality of the systems developed,
to improve the manageability of the process, and to make the development projects
more predictable. During the recent more than a decade, the CMM family – including
the most recent CMMI model – has established itself as the leading software process
improvement framework, through which increased maturity is pursued.
When combined with traditional plan-driven development methods, increasing
process maturity generally emphasizes and accommodates issues such as planning of
the system and development organization, repeatability predictability, and relatively
rigid control procedures [20, 21]. Combining software engineering best practices into
development frameworks has been a big success in both terms of popularity and
results. Indeed, there is no lack of research supporting the existence of a link between
maturity and development process performance [5, 6, 22, 20]. However, software
process improvement with CMMI or any other leading framework does not come
without a cost. First, CMMI adoption and appraisals required for official certification
are costly and require significant effort thus making it more accessible for larger than
smaller firms [14]. Second, opponents of these development frameworks argue that

Examining the Effects of Agile Methods and Process Maturity 87
they can lead to too much overhead making the process less efficient and responsive
to changes [23] While these potential weaknesses can be justified especially in large
software development projects, the relative cost in terms of lost opportunities can be
high in more market driven software product development [24, 25].
Agile methods were initially presented as an alternative to the increased overhead
in the development process as well as to decrease the effort required for adopting a
new development framework. In contrast to several of the major SPI frameworks that
are commonly documented as books [26], agile methods commonly define only
minimum amount of processes required for a development team to function efficiently
and can be codified as a relative small number of principles [27]. Another distinctive
feature of agile methods is that they emphasize simplicity, speed, and flexibility to
accommodate changes in requirements. For achieving the pursued characteristics,
developers of the agile methods feel the planning – including documentation – and
control should be, to certain degree, discarded [28]. Agile methods emphasize self-
organization of the development team, quick and frequent delivery of working
software in an incremental manner, and intensive communication both within the
development team and with the customer. Not surprisingly, agile methods have been
recently advocated as a solution to problems in software product development [7-10]
as a response to dynamic environment where technologies change fast and often in an
unpredictable manner [11, 12].
The topic of the compatibility of agile methods and process maturity has been
recently under investigation in the information systems community [2]. Within the
field of software engineering, insights have been gained through case studies of
companies that have adopted agile methods into traditional development organization
[16], and of companies using agile development processes that have implemented
CMMI, even up to maturity level 5 [29]. In general, these efforts are usually not
without challenges, but most studies report positive outcomes. In general, recently
more evidence for than against the compatibility of agile development and process
discipline has been presented [15-18]. The current understanding is that agile process
can be disciplined and mature, and that the development process should be selected
base on situation characteristics [15, 30].
Since most studies focusing on the performance of different software development
approaches focus on software projects, this poses a limitation on how well these
approaches generalize to non-project oriented settings. Particularly, cases where
software is developed as products has received limited attention in the studies
investigating the performance of different development approaches. We start the
discussion on the product development effects of these frameworks by looking at how
product development performance is defined in the literature. While information
systems and software engineering research communities view the development
performance as a two dimensional construct composed of product quality and
development project performance [31], product development research has developed
several alternative conceptualizations, most notably one consisting of efficiency,
effectiveness and innovativeness [32], and an alternative separating product
development and product management as distinct dimensions [33]. The differences on
these conceptualizations can be best understood by examining them in the context:
Incremental product development - the improvement of existing products or product
lines - and radical product development - the development of completely new

88 M. Rönkkö, J. Peltonen, and C. Frühwirth
products or product lines – require different capabilities and hence it is natural that
performance of these processes are considered as separate constructs [34, 35]. In all,
the operationalization of incremental product development include the dimensions of
efficiency and effectiveness, while the goodness of radical product development
performance is often measured through an additional dimension of innovativeness.
Efficiency refers to the goodness of rate that the resources are transformed into
outputs [32], and is composed of two main factors, lead-time and cost-efficiency. This
dimension has a close fit to the process performance dimension of software
development performance [20, 36]. Effectiveness refers to the goodness of the
product not only in terms of product quality – a common measurement of software
development performance [20, 36] – but also how well it fits the needs of the markets.
Finally, innovativeness refers to the ability to conceive new ideas and develop these
into commercially successful products or product features.
Traditional plan-driven methods have been designed to for developing well-
defined software solutions in time and on budget. These objectives are normally
achieved through solid planning and by avoiding wasted programming work [19].
Considering the strong evidence of process maturity on development project
performance [5, 6, 20] and the close fit between the performance dimensions of
incremental product development and software project performance presented earlier,
we hypothesize:
Hypothesis 1: Process maturity increases product development efficiency.
Hypothesis 2: Process maturity increases product development effectiveness.
While agile methods are not about efficiency in the same sense as plan-driven
methods [7], they aim to reduce the amount of administrative work and control for
wasted programming work through frequent integration, testing and delivery of
program versions. In this way, agile methods provide an improvement in efficiency
compared to having less defined processes. Considering the suggested fit between
agile methods to software product development [7-10] we hypothesize:
Hypothesis 3: Process agility increases product development efficiency.
Product development effectiveness refers to how well the developed product matches
the markets. While software product industry is obviously one of the more turbulent
industries, it is likely that the market requirements change during the development
cycle of a new product. In traditional project and contracting oriented software
engineering requirements changes cause schedule and budget overruns. However, in
product oriented development these can result in product with bad market fit or delay,
significantly affecting how the product performs in the markets [37-39]. Hence it is
imperative for firms to maintain flexibility in product development. We hypothesize:
Hypothesis 4: Process agility increases product development effectiveness.
Regarding the last dimension of product development performance, innovativeness is
has received relatively little attention in the software process research. In management
research, one of the most enduring findings about innovativeness is that innovation

Examining the Effects of Agile Methods and Process Maturity 89
occurs at organizational interfaces [40]. Considering that several of the SPI processes
are organizational level tools that define interfaces also between engineering and other
units within the firm, process maturity should improve innovativeness. In addition,
several of the frameworks specify that organization should have processes for managing
innovations [7].
Hypothesis 5: Process maturity increases product development innovativeness.
It has been suggested that agile methods are associated with innovation [41-43].
Moreover, agile methods give significant responsibilities to individuals, and this
empowerment of individuals is a prerequisite for innovative behavior [28]. Moreover,
agile methods emphasize the importance of communications with the customer
interface and emphasize building the work motivation at an individual level. Hence
we hypothesize:
Hypothesis 6: Process agility increases product development innovativeness.
3 Empirical Study Design
We use a subset of a larger data collection that was collected as a part of a research
project surveying software companies in Finland [44]. We use the term “software
product firm” to refer to any firm that owns and markets a software product –
regardless of the official company classification. The sampling frame for the primary
survey, which is described in details elsewhere [44], contained 2616 firms mainly
under the NACE (rev 1.2) codes 72.21 and 72.22, but also a small number of other
firms that conduct software product business as a secondary area. For this sample, the
CEO or other high ranking employee of a firm was used as an informant. After filling
in the general information including questions about product development
performance the informant nominated another person that was intimately familiar
with the software development process of the firm, most commonly the manager of
the software development function. These nominates acted as the population for the
secondary survey where the software development related questions were asked.
Asking the independent and dependent variables from a different person helped us to
avoid common method bias, which is commonly present in survey research.
The dependent variable, product development performance, was measured with a
scale developed by Kusunoki et al. [32]. It contains three dimensions; product
development efficiency, product development effectiveness and innovativeness.
These were measured with 10 items using 7-point Likert scales. Principal factor
analysis revealed only one dominant factor and a weaker three-factor solution.
However due to the theoretical foundations of the scale, we decided to use the three
dimensional structure of efficiency, effectiveness, and innovativeness for which we
standardized and calculated the Cronbach’s alphas of .76, .75, and .85, respectively.
The constructs for development process maturity and agility were adapted directly
from a paper by Rönkkö, Järvi, and Mäkelä [45]. Although their scale was originally
developed as a Rasch scale [cf., 46], it consists of simple agree-disagree questions and
can hence be adapted to a study using more traditional measurement approaches. The

90 M. Rönkkö, J. Peltonen, and C. Frühwirth
scale for measuring the process maturity was based on a well-known Capability
Maturity Model Integration (CMMI) software process maturity framework: CMMI
for Development, Version 1.2 [26]. To improve the discriminant validity of the
construct, i.e. its ability to measure software process maturity as a distinct construct
from more general product development capability, we decided to exclude the so-
called integrated product and process development (IPPD) additions to the CMMI. In
total this scale consisted of 21 items. The adoption of agile methods was measured
using a scale derived from on the basis of the two most well known agile methods and
consisted of 16 items.
All scales that were adapted from previously published research were translated to
Finnish using the double blind translate and back-translate procedure [47]. The
translations were performed by the first authors of this paper, one researcher not
related to this paper, and two research assistants. The translating protocol included
translating also the context of the items, if the content validity of the original item was
considered poor by the translator. The clarity and general validity of the items were
checked by pre-testing all survey instruments with several experts and practitioners
that had roles closely matching the ones of the informants. Based on these reviews, a
number of items were reformulated.
The primary survey was implemented in two stages as follows. First, a pilot survey
with about 11 percent of the sampling frame of 2616 firms was launched in April
2007. The pilot survey, mailed to 291 firms, was used to test the primary survey
instrument. Minor modifications were made to the questionnaire. The main primary
survey was thereafter sent to 2550 firms (2616 firms, from which we have excluded
66 firms that had responded to the pilot survey).
Both stages were implemented following a modified version of the tailored survey
design method [48]. Mailings began with a pre-notice letter followed by the main
survey package using postal mail. Two email reminders and one round of telephone
calls were used to improve the response rate. A printed questionnaire and an online
form were offered as alternative options to the informants. This phase of our data
collection lasted from April through July 2007. Altogether, this phase produced 287
usable responses. After excluding firms with less than five employees as too small,
the secondary survey was sent to 123 managers of software development or person in
similar knowledgeable position with regards to software development in the firm.
After several reminders by email and telephone, 83 firms provided responses to both
surveys and were used in the main analyses. 9 cases were dropped due to the amount
of missing data resulting in final sample of 72 companies.
We screened and prepared the data with Stata version 10. The effect of non-
response was tested using two different methods. First, we compared the means of the
key study variables between early and late respondents, as suggested by Oppenheim
[49]. For the primary survey, we found that late respondents were larger (p < .001)
and older (p < .05) than the early respondents. No significant differences were found
for the secondary survey. Second, we compared the sampling frame with the
respondents. For the primary survey, we found that industry codes 72.21 and 72.22
were overrepresented, which was expected considering that the survey targeted the
software product industry and oversampling was used. We did not find any significant
differences between geographical distribution and age of the sampling frame and the
respondents. When comparing the respondents of the secondary survey to the

Examining the Effects of Agile Methods and Process Maturity 91
sampling frame, no differences were found. In all, the results of our non-response
analysis indicate that the results of this study are likely to be more valid for smaller
than larger software product firms.
We used Partial Least Squares Path Modeling (PLS) as our main data analysis
method. The reason for using this approach is the convenience it provides by testing
all hypotheses and the validity of the measures in a single set of analyses. Although
structural equation modeling would perform similar tests, we chose PLS because it
has less stringent sample size and indicator distribution requirements than traditional
SEM approaches [50]. Moreover, the method has increased popularity in IS recently
[51] and hence we considered it more appropriate.
4 Results
We start examining the results of PLS by examining the measurement model. Table 1
shows the summary statistics for the constructs and Table 3 shows the construct-
indicator cross loading matrix. Indicator loadings for the product development
performance constructs are all above the recommended .707 threshold except the first
two items. The first item is substantially below the limit for acceptable, but we
decided to keep it nevertheless. The reason for this is that PLS model works better
when the number of indicators is larger, all reliability indicators in Table 2 were good
for this construct, and this poor item is weighted less than others so it should not
cause bias in the results. All indicators in these scales load higher on their respective
constructs than other constructs indicating discriminant validity of the three-
dimensional product development performance scale.
The process agility and process maturity scales are more problematic since they have
so many items. We considered parceling of the items, but this was not done due to the
fact that to get unbiased results in PLS, the number of indicators needs to be large [52].
However, when the ratio of number of indicators to the number of cases is large, the
indicator loadings tend to be unstable. Nevertheless, the reliability indices for these two
constructs were high (Process Maturity) and acceptable (Process Agility) and hence we
concluded that the overall degree of quality of measurement is sufficient.
Figure 1 shows the results of PLS estimation in the form of a path diagram and
Table 2 shows the results of bootstrapping. All path coefficients are positive except
for the path from Process Maturity to Efficiency. None of the paths between Process
Table 1. Construct reliability and validity
AVE Composite
Reliability R
Square Cronbachs
Alpha Commun-
ality Redund-
ancy
Agility 0,1932 0,7772 0,0000 0,7531 0,1932 0,0000
Effectiveness 0,4225 0,7356 0,1649 0,5329 0,4225 0,0665
Efficiency 0,6093 0,8236 0,1929 0,6850 0,6093 0,0997
Inno-
vativeness
0,7640 0,9066 0,0856 0,8454 0,7640 0,0521
Maturity 0,3742 0,9237 0,0000 0,9147 0,3742 0,0000

92 M. Rönkkö, J. Peltonen, and C. Frühwirth
Fig. 1. Results of PLS estimation
Table 2. Bootstrapping results
Original
Sample Sample
Mean Standard
Error T
Statistics p
Agility -> Effectiveness 0,3614 0,4046 0,1401 2,5787 0,05981
Agility -> Efficiency 0,5037 0,4787 0,1527 3,2974 0, 0007589
Agility -> Innovativeness 0,1981 0,2532 0,1535 1,2908 0,1005
Maturity -> Effectiveness 0,0726 0,1223 0,1272 0,5706 0,2850
Maturity -> Efficiency -0,1485 -0,0693 0,1773 0,8378 0,2025
Maturity ->
Innovativeness 0,1320 0,1590 0,1295 1,0189 0,1556

Examining the Effects of Agile Methods and Process Maturity 93
Table 3. Construct-indicator cross-loading matrix
Agility Effectiveness Efficiency Inno-
vativeness
Maturity
Agile1 0,5515 0,3127 0,1299 0,2173 0,5430
Agile10 0,3789 0,1255 0,2487 -0,0273 0,0404
Agile11 0,5548 0,1869 0,2705 0,1668 0,4009
Agile12 0,3367 0,0768 0,2214 -0,0083 0,0376
Agile13 0,3031 -0,0318 -0,0773 -0,0028 0,5196
Agile14 0,2710 -0,0128 0,0527 -0,0955 0,3336
Agile15 0,2448 -0,0225 -0,0154 0,0362 0,3367
Agile16 0,5672 0,1005 0,3635 0,0891 0,3932
Agile2 0,4581 0,1095 0,0276 0,0608 0,3085
Agile3 0,4256 0,0781 0,0076 0,0688 0,3247
Agile4 0,2935 -0,0001 0,0229 0,1066 0,5750
Agile5 0,5457 0,2462 0,1487 0,1581 0,3604
Agile6 0,7113 0,3264 0,3295 0,2493 0,2257
Agile7 0,4541 0,1525 0,0068 -0,0359 0,4008
Agile8 0,3141 0,2139 0,0911 0,1171 -0,0456
Agile9 0,2999 0,1206 0,1487 0,1379 0,2503
CMMI1 0,2075 0,0245 0,0326 0,0685 0,3686
CMMI10 0,5046 0,2144 0,2208 0,0453 0,6608
CMMI11 0,4052 -0,0227 -0,1179 -0,0375 0,6358
CMMI12 0,4344 0,1157 0,1575 0,0425 0,6293
CMMI13 0,3204 0,1073 0,0087 0,1387 0,7229
CMMI14 0,3130 0,1407 0,0694 0,2226 0,7038
CMMI15 0,1868 0,1349 -0,1231 0,0695 0,6136
CMMI16 0,2867 0,0802 -0,1057 0,0536 0,6906
CMMI17 0,1609 0,2231 -0,1458 0,1694 0,6626
CMMI18 0,1469 0,1367 0,0535 0,0439 0,2506
CMMI19 0,6020 0,2361 0,2840 0,0237 0,5287
CMMI2 0,1281 0,1380 -0,0326 0,2104 0,4804
CMMI20 0,4241 0,1507 0,1119 0,0457 0,5156
CMMI21 0,2926 0,1742 -0,0233 0,0957 0,6183
CMMI3 0,3116 0,0983 0,0007 0,2018 0,6391
CMMI4 0,2585 0,2190 0,0707 0,2861 0,7086
CMMI5 0,5284 0,1554 0,2045 0,2393 0,7431
CMMI6 0,4737 0,2091 0,2277 0,1620 0,6023
CMMI7 0,3866 0,0686 -0,0611 0,0388 0,6062
CMMI8 0,1414 0,0767 -0,0478 0,1276 0,6392
CMMI9 0,2022 0,1720 -0,0713 0,1647 0,5934
PDEffectiveness1 0,0764 0,3985 0,1221 0,1919 0,1971
PDEffectiveness2 0,2938 0,6317 0,2349 0,2655 0,1857
PDEffectiveness3 0,3106 0,7509 0,4392 0,5817 0,0940
PDEffectiveness4 0,2969 0,7539 0,4742 0,6027 0,2428
PDEfficiency1 0,3087 0,2378 0,7466 0,2607 0,0174
PDEfficiency2 0,3045 0,4715 0,8316 0,4067 0,0402
PDEfficiency3 0,3594 0,4760 0,7609 0,4216 0,2093
PDInnovativeness1 0,2505 0,6057 0,4483 0,8841 0,1661
PDInnovativeness2 0,2519 0,6588 0,5216 0,9004 0,2425
PDInnovativeness3 0,2073 0,4617 0,2596 0,8365 0,2203

94 M. Rönkkö, J. Peltonen, and C. Frühwirth
Maturity to the product development constructs are significant and hence we can
conclude that hypotheses 1, 2, and 5 are not supported. When we look at the
significance tests for the paths from Process Agility to the product development
constructs, we can see that the path to Efficiency is significant, path to Effectiveness
is marginally significant and path to Innovativeness is close to marginally significant.
Hence we conclude that Hypothesis 3 is supported, Hypothesis 4 is weakly supported
and Hypothesis 6 does not receive support from our data. The lack of support for the
last hypothesis is probably due to lack of statistical power due to a small sample size.
5 Discussion and Conclusions
In this paper we studied the product development performance effects of agile
software development practices and mature software process. To our understanding,
this undertaking is one of the first studies investigating the relative merits of these
models using survey research. Our key findings are that agile methods have a positive
effect on product development performance, but process maturity does not seem to
have an effect. This finding is a bit surprising, but can be explained by the fact that
the companies in the sample are small firms and the process development frameworks
are designed for predominantly large organizations that do larger software projects.
The fact that software process and innovativeness seem unrelated can be
interpreted as meaning that there are other organizational factors that affect
innovativeness much more than what software development methods are in use.
Regarding the limitations of the study, non-response analysis and descriptive
statistics indicate that the results of the study are probably rather well generalizable
among small and the smaller medium-sized software product firms. However, it needs
to be pointed out that we have studied only Finnish firms. A number of issues of
national culture or the peculiarities of Finland as a small economy that may influence
business operations can quite possibly affect the results..
Also, as with any paper relating to self-administered surveys and related to
composite variables is that our paper relies on self-reports. Although we spent
considerable efforts to make the survey items as clear as possible [45] and tried to
make the items such that also persons not familiar with CMMI or the particular agile
methods used could reliably answer the questionnaire, it is possible that some of the
items were too difficult for the respondents. However, our more detailed analysis [45]
indicated that these problems should not be more serious than what is typical for a
paper based on survey data. Finally, there have recently been some concerns related to
the validity of the PLS approach [53-54], and should these concerns be validated in
follow-up studies, they can have implications for this paper.
This paper has two managerial implications: First, at least in small firm context,
using agile methods can substitute for process maturity. Although our sample includes
only firms from CMMI levels four and below, this is an important finding that can, if
supported by further research, help guide initial software process improvement efforts
in smaller firms. Second, our data indicated that agile methods are probably more
appropriate for product development than non-agile.

Examining the Effects of Agile Methods and Process Maturity 95
References
1. Kautz, K., Madsen, S., Norbjerg, J.: Persistent problems and practices in information
systems development. Information Systems Journal 17, 217–239 (2007)
2. Vinekar, V., Slinkman, C.W., Nerur, S.: Can Agile and Traditional Systems Development
Approaches Coexist? an Ambidextrous View. Information Systems Management 23, 31–
42 (2006)
3. Balijepally, V., Mahapatra, R., Nerur, S., Price, K.H.: Are Two Heads Better Than One for
Software Development? The Productivity Paradox of Pair Programming. MIS
Quarterly 33, 91–118 (2009)
4. Dybå, T., Dingsøyr, T.: Empirical studies of agile software development: A systematic
review. Information and Software Technology (2008)
5. Agrawal, M., Chari, K.: Software effort, quality, and cycle time: A study of CMM level 5
projects. IEEE Transactions on Software Engineering 33, 145–156 (2007)
6. Galin, D., Avrahami, M.: Are CMM program investments beneficial? Analyzing past
studies. IEEE Software 23, 81–87 (2006)
7. Highsmith, J., Cockburn, A.: Agile Software Development: The Business of Innovation.
IEEE Computer 34, 120–122 (2001)
8. Meso, P., Jain, R.: Agile Software Development: Adaptive Systems Principles and Best
Practices. Information Systems Management 23, 19–30 (2006)
9. Poppendieck, M.: Lean Software Development. In: Companion to the Proceedings of the
29th International Conference on Software Engineering, pp. 165–166. IEEE Computer
Society, Los Alamitos (2007)
10. Taylor, P.S., Greer, D., Sage, P., Coleman, G., McDaid, K., Lawthers, I., Corr, R.:
Applying an agility/discipline assessment for a small software organisation. In:
Proceedings of Product-Focused Software Process Improvement, pp. 290–304. Springer,
Berlin (2006)
11. Baskerville, R., Pries-Heje, J.: Short cycle time systems development. Information
Systems Journal 14, 237–264 (2004)
12. MacCormack, A., Verganti, R., Iansiti, M.: Developing products on “Internet time": The
anatomy of a flexible development process. Management Science 47, 133–150 (2001)
13. Germain, É., Robillard, P.N.: Engineering-based processes and agile methodologies for
software development: a comparative case study. The Journal of Systems & Software 75,
17–27 (2005)
14. Staples, M., Niazi, M., Jeffery, R., Abrahams, A., Byatt, P., Murphy, R.: An exploratory
study of why organizations do not adopt CMMI. Journal of Systems and Software 80,
883–895 (2007)
15. Boehm, B., Turner, R.: Using risk to balance agile and plan-driven methods. Computer 36,
57–66 (2003)
16. Baker, S.W.: Formalizing agility: an agile organization’s journey toward CMMI
accreditation. In: Proceedings of Agile Conference, pp. 185–192 (2005)
17. Merisalo-Rantanen, H., Tuunainen, T., Rossi, M.: Is extreme programming just old wine in
new bottles: A comparison of two cases. Journal of Database Management 16, 41–61
(2005)
18. Paulk, M.C.: Extreme programming from a CMM perspective. IEEE Software 18, 19–26
(2001)
19. Pressman, R.: Software Engineering: A Practitioner’s Approach. McGraw-Hill
Science/Engineering/Math. (2009)

96 M. Rönkkö, J. Peltonen, and C. Frühwirth
20. Jiang, J.J., Klein, G., Hwang, H.G., Huang, J., Hung, S.Y.: An exploration of the
relationship between software development process maturity and project performance.
Information & Management 41, 279–288 (2004)
21. Schach, S.R.: Object-oriented and classical software engineering. McGraw-Hill, Boston
(2002)
22. Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., Paulk, M.: Software quality and the
Capability Maturity Model. Communications of the ACM 40, 30–40 (1997)
23. Turner, R., Jain, A.: Agile meets CMMI: Culture clash or common cause? Extreme
Programming and Agile Methods—XP/Agile Universe 2002, 153–165 (2002)
24. Carlshamre, P.: Release Planning in Market-Driven Software Product Development:
Provoking an Understanding. Requirements Engineering 7, 139–151 (2002)
25. Jantunen, S., Smolander, K.: Towards global market-driven software development
processes: an industrial case study. In: Proceedings of the 2006 International Workshop on
Global Software Development for the Practitioner, pp. 94–100. ACM, Shanghai (2006)
26. SEI: CMMI for Development, version 1.2 (2006)
27. Beck, K., Andres, C.: Extreme programming explained: embrace change. Addison-Wesley
Professional, Reading (2004)
28. Turk, D., France, R., Rumpe, B.: Assumptions underlying agile software-development
processes. Journal of Database Management 16, 62–87 (2005)
29. Sutherland, J., Jakobsen, R., Johnson, K.: Scrum and cmmi level 5: The magic potion for
code warriors. In: Proceedings of the 41st Annual. Hawaii International Conference on
System Sciences, p. 466 (2008)
30. Cockburn, A.: Selecting a project’s methodology. IEEE Software 17, 64–71 (2000)
31. Subramanian, G.H., Jiang, J.J., Klein, G.: Software quality and IS project performance
improvements from software development process maturity and IS implementation
strategies. Journal of Systems and Software 80, 616–627 (2007)
32. Kusunoki, K., Nonaka, I., Nagata, A.: Organizational capabilities in product development
of Japanese firms: a conceptual framework and empirical findings. Organization Science 9,
699–718 (1998)
33. Kahn, K.B.: Market orientation, interdepartmental integration, and product development
performance. The Journal of Product Innovation Management 18, 314–323 (2001)
34. McDermott, C.M., O’Connor, G.C.: Managing radical innovation: an overview of
emergent strategy issues. Journal of Product Innovation Management 19, 424–438 (2002)
35. Veryzer, R.W.: Discontinuous Innovation and the New Product Development Process.
Journal of Product Innovation Management 15, 304–321 (1998)
36. Nidumolu, S.R.: Standardization, requirements uncertainty and software project
performance. Information and Management 31, 135–150 (1996)
37. Citrin, A.V., Lee, R.P., McCullough, J.: Information use and new product outcomes: The
contingent role of strategy type. Journal of Product Innovation Management 24, 259–273
(2007)
38. Karlsson, L., Dahlstedt, A.G., Regnell, B., Nattoch Dag, J., Persson, A.: Requirements
engineering challenges in market-driven software development - An interview study with
practitioners. Information and Software Technology 49, 588–604 (2007)
39. Slaughter, S.A., Levine, L., Ramesh, B., Pries-Heje, J., Baskerville, R.: Aligning software
processes with strategy. Mis Quarterly 30, 891–918 (2006)
40. Tushman, M.L.: Special boundary roles in the innovation process. Administrative Science
Quarterly 22, 587–605 (1977)
41. McDonough, E.F.: Investigation of factors contributing to the success of cross-functional
teams. Journal of Product Innovation Management 17, 221–235 (2000)

Examining the Effects of Agile Methods and Process Maturity 97
42. Spreitzer, G.M.: Psychological empowerment in the workplace: Dimensions,
measurement, and validation. Academy of Management Journal 38, 1442–1465 (1995)
43. Tierney, P., Farmer, S.M.: Creative self-efficacy: Its potential antecedents and relationship
to creative performance. Academy of Management Journal 45, 1137–1148 (2002)
44. Rönkkö, M., Eloranta, E., Mustaniemi, H., Mutanen, O., Kontio, J.: Mustaniemi, H.,
Mutanen, O., Kontio, J.: Finnish Software Product Business: Results of National Software
Industry Survey 2007. Helsinki University of Technology (2007)
45. Rönkkö, M., Järvi, A., Mäkelä, M.M.: Measuring and comparing the adoption of software
process practices in the software product industry. In: Proceedings of Internationl
Conference on Software Process, Leipzig, Germany, pp. 407–419 (2008)
46. Dekleva, S., Drehmer, D.: Measuring software engineering evolution: A rasch calibration.
Information Systems Research 8, 95–104 (1997)
47. Brislin, R.W.: Back-Translation for Cross-Cultural Research. Journal of Cross-Cultural
Psychology 1, 185–216 (1970)
48. Dillman, D.A.: Mail and Internet surveys: the tailored design method. Wiley, New York
(2007)
49. Oppenheim, A.N.: Questionnaire Design and Attitude Measurement Heinemann, London
(1966)
50. Chin, W.W.: The partial least squares approach to structural equation modeling. In:
Marcoulides, G.A. (ed.) Modern Methods for Business Research, pp. 295–336. Lawrence
Erlbaum Associates Publishers, Mahwah (1998)
51. Ahlemann, F., Urbach, N.: Structural Equation Modeling in Information Systems Research
Using Partial Least Squares. Journal of Information Technology Theory and Application
(JITTA) 11 (2010)
52. Dijkstra, T.: Some comments on maximum likelihood and partial least squares methods.
Journal of Econometrics 22, 67–90 (1983)
53. Evermann, J., Tate, M.: Testing Models or Fitting Models? Identifying Model
Misspecification in PLS. In: Proceedings of the ICIS 2010 (2010)
54. Rönkkö, M., Ylitalo, J.: Construct Validity in Partial Least Squares Path Modeling. In:
Proceedings of the ICIS 2010 (2010)