84

Int. J. Business Innovation and Research, Vol. 7, No. 1, 2013

Application of agile methods in the innovation

process
Lea Hannola*, Joel Friman and
Jyri Niemimuukko
Department of Industrial Management,
Lappeenranta University of Technology,
P.O. Box 20, FI-53851 Lappeenranta, Finland
E-mail: lea.hannola@lut.fi
E-mail: joel.friman@lut.fi
E-mail: jyri.niemimuukko@lut.fi
*Corresponding author
Abstract: The main objective of this study was to analyse the applicability of
agile methods for improving the efficiency of the innovation process. The study
was conducted by analysing both innovation and software development
processes, their similarities and differences, and as well as comparing the
criticism against them. As a result of the study, it was found that agile methods
provide several improvements regarding to organisational practices, transfer of
knowledge and know-how, and understanding of customer needs that could be
applied to the innovation process. In addition, this study provides several agile
guidelines to managers and project team members for improving the innovation
process. These are, e.g., the usage of light user stories as a solution for the
heavy documentation, giving up fixed implementations plans for enhancing an
incremental product development process, the usage of, e.g., war rooms to
facilitate the transfer of knowledge and know-how, and the integration of the
fuzzy front end to the whole innovation process as continuous loops by means
of customer involvement, short iterations and readiness for change.
Keywords: innovation process; new product development; NPD; agile
methods; software development; SD; waterfall model.
Reference to this paper should be made as follows: Hannola, L., Friman, J. and
Niemimuukko, J. (2013) Application of agile methods in the innovation
process, Int. J. Business Innovation and Research, Vol. 7, No. 1, pp.8498.
Biographical notes: Lea Hannola is a Postdoctoral Researcher in the
Department of Industrial Management at Lappeenranta University of
Technology. Her research focuses on innovation and technology management,
and especially on the front end of innovation processes and tools in software
development.
Joel Friman is a student at Lappeenranta University of Technology. He studies
industrial management and is majoring in innovation and technology
management. He is currently working as a trainee in Vaisala Oyj.
Jyri Niemimuukko is a student in the Department of Industrial Management at
Lappeenranta University of Technology. He has a strong background as a
Software Developer and Project Manager and he is currently working as a CIO
at Oy Matkahuolto Ab.

Copyright 2013 Inderscience Enterprises Ltd.

Application of agile methods in the innovation process

85

Introduction

The traditional software development (SD) process is known as the software lifecycle
model or the waterfall model, because of a cascade from one phase to another
(Sommerville, 2001). However, the practical application of the waterfall model has
turned out to be problematic due to its formal structure and inflexibility. Therefore, the
waterfall model has been modified in various different ways, and the latest development
step has been in the creation of methodologies that share the common goal of providing
quick customer value with incremental and iterative development. These methodologies
are called agile software development methods. However, there is no universal definition
of agile software development, but in general their basic premise is that a small,
co-located team works closely together with customers, and the team creates a high-value
product cost-effectively with continuous short iterations (Kettunen, 2009). Agile SD
constitutes a set of principles initially advocated by a group of software practitioners, and
now practiced by many software professionals (Misra et al., 2009). According to
Vijayasarathy and Turk (2012), agile SD has emerged as an important alternative to
traditional plan-based approaches. The main success factors in agile SD projects are
effective communication, collaboration, and coordination (Mishra and Mishra, 2009).
The innovation process has rather similar phases as the traditional waterfall model of
SD. However, the innovation process covers a broader entity than the traditional SD
process. In addition to the SD process, the innovation process includes a front end of
innovation (FEI) phase and commercialisation activities. Koen et al. (2002) divide the
innovation process into three areas: FEI, new product development (NPD), and
commercialisation phases. Over the years, innovation processes have been developed
from simple linear models into complicated and interactive network models (Rothwell,
1994; Tidd et al., 2005). According to Dershin (2010), fundamentally linear views of the
innovation process have been abandoned in favour of more systemic or non-linear views
over the last decades.
Wallin et al. (2002) have studied the possibilities to integrate business decision
models and SD lifecycle models. They have compared Coopers state-gate process model
as an example with three SD lifecycle models. Wallin et al. have come to the conclusion
that SD lifecycle models do not ensure that resources are used in the right projects, that
the market is available, or that the organisation is ready for release. Similarly, business
models do not support SD, so the development might struggle with uncontrolled changes
and inadequate time for validation. Further, Nambisan and Wilemon (2000) have studied
the potentials for cross-domain knowledge sharing between SD and NPD. According to
their study, NPD and SD share several similarities and face many common challenges.
The study of Nambisan and Wilemon also reveals that much of the SD research has
focused on development methodologies, techniques, and use of technology to support the
development process. On the other hand, the NPD literature frequently emphasises the
organisational issues associated with the development process, and the focus of the NPD
research has largely been on the interaction of people and the processes involved in the
different phases. In addition, Gassmann et al. (2006) have analysed the applicability of
successful practices from extreme programming (XP) to traditional NPD, and especially
whether analogies from the XP approach can be drawn for managing the FEI to enable
successful integration of the customer. Gassman et al. demonstrate that the iterative

86

L. Hannola et al.

probing-and-learning XP process is a part of modern successful development practices

for traditional industrial and consumer goods.
The main objective of this study was to analyse the applicability of agile SD methods
for improving the efficiency of the innovation process. Another objective was to find out
problems and targets for improvement in the innovation process, where efficiency could
be improved by utilising agile SD processes or tools. The objectives of this study can be
summarised as the following research question: How can the agile methods used in
software development be utilised in the innovation process? The study was conducted
by analysing innovation and SD processes, their similarities and differences, and as well
as comparing the criticism against them. The assumption was that if the criticism and
problems between the innovation process and the waterfall model of SD are convergent,
it can be assumed that the solutions of the agile methods are also applicable in the
innovation process. As a result of the study, it was found that agile methods provide
several improvements regarding to organisational practices, transfer of knowledge and
know-how, and understanding of customer needs that can be applied in the innovation
process.
The rest of this paper is structured as follows. Section 2 reviews the evolution and
problems of the innovation and SD processes. The aspects of agile SD methods are
covered in Section 3, and a synthesis of innovation and SD processes follows in
Section 4. Finally, Section 5 provides guidelines for improving the innovation process
and concludes the study.

Innovation processes

Tidd et al. (2005) define innovation as a process of turning opportunity into new ideas
and of putting these into widely used practice. According to Trott (2005), the term
innovation is a very broad concept that can be understood in a variety of ways, and he
introduces the notion that innovation is a process with a number of distinctive features
that have to be managed. Thus, Trott defines innovation as the management of all the
activities involved in the process of idea generation, technology development,
manufacturing and marketing of a new (or improved) product, manufacturing process or
equipment. Innovation can also be considered as an organisational or management
process that requires tailor-made tools and management systems (Anand and Pandya,
2008).

2.1 Evolution of innovation process models

Innovation processes have been evolving from simple linear models (first and second
generations) to increasingly complex interactive models (third-fifth generations) (Tidd
et al., 2005). The first innovation process presented in the 1950s was generally perceived
as a linear progression from scientific discovery, through technological development in
companies, to the markets (Rothwell, 1994). The latest development in the 2000s is the
systems integration and networking innovation process theory, which is based on the
fourth-generation process, but highlights the need for continuous change (Galanakis,
2006). According to Dershin (2010), there has been a gradual shift from conceptualising
innovation as a linear process to understanding it as systemic or non-linear. Table 1

Application of agile methods in the innovation process

87

indicates the chronological development of the innovation process models, according to

Rothwells (1994) categorisation.
Table 1

Evolution of innovation process models

Generation

Model

Features

Technology push

Simple linear sequential model; emphasis on

R&D

Market pull

Simple linear sequential model; emphasis on

marketing

Third (1980s)

Coupling model

Integration of R&D and marketing

Fourth (1980/1990s)

Interactive model

Combinations of push and pull

Network model

Systems integration and extensive networking,

continuous innovation

First (1950/1960s)
Second (1970s)

Fifth (2000s)

Source: Modified from Rothwell (1994), Tidd et al. (2005) and Trott (2005)

The literature features numerous innovation process models and business decision models
that describe how companies develop or should develop new products or services. Koen
et al. (2002) suggest that the innovation process can be divided into three areas: the fuzzy
front end (FFE), the NPD process, and commercialisation. Herstatt et al. (2006) describe
a simplified process of product development, which demonstrates the stage at which the
FEI plays a role in the innovation process. In general, modern innovation processes
involve activities that are essentially common to all companies [Tidd et al., (2005), p.67]:
1

Searching scanning the internal and external environment for, and processing
relevant signals about, threats and opportunities for change.

Selecting deciding, on the basis of a strategic view of how the enterprise can best
develop, which of these signals to respond to.

Implementing translating the potential in the trigger idea into something new and
launching it in an internal or external market.

Learning companies have the opportunity to learn from progressing through this
cycle so that they can build their knowledge base and improve the ways in which the
process is managed.

2.2 Problems of innovation process models

Most innovations are fuzzy, involving false starts, recycling between stages, dead ends
and jumps out of sequence (Tidd et al., 2005). According to Apilo et al. (2007), the
number of documents and reviews during the NPD phase is usually too high. Innovation
processes are often designed according to the most challenging ones, although a
significant part of the development project could be managed with lighter bureaucracy. In
addition, a realistic estimation about the scope and schedule of a NPD project causes
problems. Other problems related to the innovation process are, e.g., fixed specifications
in the beginning of the project, the modification of customer needs into product features,
the transfer of knowledge and know-how between different stakeholders, communication
problems, and the inflexibility of traditional state-gate models (Apilo et al., 2007).

88

L. Hannola et al.

According to Koivuniemi (2008), especially the management of the FEI in companies

is experienced as a major challenge. Kim and Wilemon (2002) define the front end as the
period between when an opportunity is first considered and when it is judged ready for
development. The FEI is regarded as one of the most important steps in building new
products or services, offering the greatest opportunities for overall innovation process
improvements (Koen et al., 2002; Kim and Wilemon, 2002). However, the activities in
the FEI are often chaotic, unpredictable and unstructured (Koen et al., 2002). Piirainen
et al. (2010) found out that the effect of uncertainty in the front end is a well-recognised
problem, and its effects range from NPD projects not meeting their goals to complete
failures of new products. In addition, Khurana and Rosenthal (1998) have conducted a
rather extensive literature review of the common problems related to the front end. They
are:

unclear product strategy

inadequate product definition

unresolved technical uncertainties

inadequate market/customer need assessment

unclear project objectives

shortage of key resources

lack of contingency planning

roles not clarified early on

executive reviewers not playing a leadership role.

2.3 Evolution of SD process models

Within the software industry, the NPD process is called SD in the case of developing
software products, applications or services. As well as in the case of innovation process
models, there exist several process models to explain the different approaches to SD. The
first processes of SD were extremely simple: at first coding, then testing and fixing. The
fulfilment of requirements, architecture, and maintenance were considered only after the
actual programming. The first published model of a SD process, derived from other
engineering processes, is presented in Figure 1. This model is known as the waterfall
model because of the cascade from one phase to another, or as the software lifecycle
model (Sommerville, 2001).
The traditional waterfall model has been modified in various ways towards
change-driven models. In addition to the waterfall model, other models of the SD process
include, e.g., the evolutionary model, formal systems development, reuse-based
development, incremental development, and the spiral model (Sommerville, 2001).
Figure 2 illustrates the evolution of the SD process models, and the development of the
agile software methodologies are described after that. Although there are many different
software processes, there are four fundamental activities common to all software
processes [Sommerville, (2001), p.43]:

Application of agile methods in the innovation process

89

Software specification. The functionality of the software and the constraints on its
operation must be defined.

Software design and implementation. The software to meet the specification must be
produced.

Software validation. The software must be validated to ensure that it does what the
customer wants.

Software evolution. The software must evolve to meet changing customer needs.

Figure 1

Software lifecycle model

Source: Sommerville (2001, p.45)

Figure 2

Evolution of the SD process models

Source: Salo (2006, p.18)

90

L. Hannola et al.

2.4 Problems of the waterfall model

The practical application of the waterfall model has turned out to be problematic due to
its formal structure and inflexibility. According to Kess and Haapasalo (2002), there has
been some justified criticism of the waterfall model. Kess and Haapasalo point out that in
practice it is hard to manage a software project in a linear manner, as it is extremely
difficult to make detailed specifications without any iterations and feedback to the
process later, and the time to market is too long, i.e., it takes too long before any
significant results from the project can be presented to the (potential) customer.
Furthermore, Boehm (1988) argues that the biggest problem in the waterfall model is the
heavy documentation in requirements definition and design phases. Schwaber (1995)
points out that the incapability of the waterfall model to react to surprising results in the
middle of the linear process causes considerable problems. In addition, the traditional
waterfall model does not cover all the phases included in the fuzzy FEI, i.e., opportunity
identification and analysis, or idea generation. Hannola and Ovaska (2011) have studied
the challenges related especially to the front end phase of SD, such as inadequate
processes, shortage of resources, poor communication, and changing understanding of
requirements. Hannola and Ovaska suggest that SD organisations should focus more on
the agile and innovation approaches instead of the traditional ones.

Agile SD

Agile SD evolved in the mid-1990s as a part of a reaction against bureaucratic and slow
methods such as ISO 9000, the rational unified process (RUP), and the capability
maturity model (CMM) (Gassmann et al., 2006). The latest development in the
21st century has been the creation of new methods and models that share the common
goal for high-value product cost-effectiveness with short iterations. The agile SD
paradigm has become increasingly popular during the last few years, and many
organisations are adopting agile practices in their SD projects (Misra et al., 2009).
According to Rubin and Rubin (2011), one of the main contributors to the success of
agile methods is probably the dissatisfaction with the bureaucracy of traditional
development methodologies. According to Thummadi et al. (2011), the enactments of the
agile and waterfall methodologies are substantially different. Dyb and Dingsoyr (2008)
argue that agile SD represents a major departure from traditional and plan-based
approaches to SD.
According to Kettunen (2009), the basic premise in agile SD methods is that a small,
co-located team working closely together with customer(s) can create a high-value
product cost-effectively with frequent short iterations. Agile methods do not encourage
the formal, document-centric activities needed to satisfy robust process requirements,
such as documented design and requirements management (Gary et al., 2011).
Abrahamsson et al. (2002) define a SD method as an agile one, when it is:

incremental (small releases with rapid cycles)

cooperative (customers and developers working constantly together with close

communication)

Application of agile methods in the innovation process

straightforward (the method itself is easy to learn and modify, well-documented)

adaptive (able to make last moment changes).

91

Nowadays, the variety of agile methods includes a number of specific techniques and
practices of SD (Salo and Abrahamsson, 2008). Agile methods in general and XP have
gained supporters among system development practitioners (Ovaska, 2009), and
according to Gassmann et al. (2006), XP has eventually become one of the most popular
methods of agile SD. The main characteristics of XP are short iterations with small
releases and rapid feedback, customer participation, communication and coordination,
continuous integration and testing, collective ownership of the code, limited
documentation and pair programming (Abrahamsson et al., 2002). Figure 3 illustrates the
differences in the traditional SD process vs. XP development cycles.
Figure 3

The traditional SD process vs. XP development cycles (see online version for colours)

Source: Modified from Gassmann et al. (2006)

The ideology of the scrum method is generally considered to having been born in the
article of Takeuchi and Nonaka (1986) concerning rugby players way of moving a ball
between players in a tight formation with teamwork. Since then, the scrum approach has
been developed for managing the system development process, and the main idea is that
system development involves several environmental and technical variables (e.g.,
requirements, time frame, resources, and technology) that are likely to change during the
process (Abrahamsson et al., 2002). According to Schwaber (1995), the scrum process

92

L. Hannola et al.

includes three phases: pre-game, game (also called development phase) and post-game,
and the phases are moved on in a linear fashion. The pre-game phase includes the
definition of the system being developed, and a product backlog list is created containing
all the requirements that are currently known (Abrahamsson et al., 2002). In addition,
according to Abrahamsson et al. (2002), the high level design of the system including the
architecture is planned on the basis of the current items in the product backlog. In the
game phase, the system is developed in Sprints, which are iterative cycles where
functionality is developed or enhanced to produce new increments. Each Sprint includes
the traditional phases of SD, i.e., requirements, analysis, design, evolution and delivery
phases. In the post-game phase, the system is ready for release, and the preparation for
this is done by including such tasks as integration, system testing and documentation
(Abrahamsson et al., 2002).
The application and adaption of different practices of XP and scrum, as well as the
extent of use, are also bound to differ from project to project and from organisation to
organisation (Salo and Abrahamsson, 2008). In addition to XP and scrum, other agile SD
methods include such methods as Mobile-D (Abrahamsson et al., 2002), LEAN
(Poppendieck and Poppendieck, 2003) and feature driven development (Palmer and
Felsing, 2002). Abrahamsson et al. (2002), and Dyb and Dingsoyr (2008) have
conducted rather comprehensive literature reviews and analyses of several agile SD
methodologies.

Synthesis of the innovation and SD processes

When the five generations of innovation processes (Rothwell, 1994) are added into the
evolutionary model of Salo (2006) (Figure 2), it can be noticed that the models have been
developed at the very same time, and they share a similar trajectory. However, there
seems to be a difference between agile SD and the 5th generation model of innovation
due to the higher readiness for change in the agile methods. Thus, it could be assumed
that the software product is easier to change at the end of SD than the fixed products
(goods) at the end of product development. The evolution of innovation process models
and SD process models are depicted in Figure 4.
When reviewing the problems related to the innovation process and the traditional
waterfall model of SD, several similar problems can be found, such as:

heavy documentation

change management during the process

knowledge transfer between stakeholders and within a development team

communication

pressure to fixed specifications to manage changes in scope, schedule and/or costs of

a new development project

FFE.

Possible solutions and tools of agile SD methodologies, related to the challenges

observed in the traditional waterfall model of SD and in the innovation process are
presented in Table 2.

Application of agile methods in the innovation process

Figure 4

93

Evolution of the innovation process and SD process

Source: Integrated from Rothwell (1994) and Salo (2006)

According to Apilo et al. (2007), many companies have started to model their product
development with process descriptions, but the heavy documentation in the specification
and design phases has become a major problem. In addition, the amount of
documentation and reviews has become too extensive. The agile SD methods have solved
the problem with light user stories. The customers write out a user story that they wish to
be included in the first release, and each story card describes a feature to be added into
the programme (Abrahamsson et al., 2002). The customer(s) and programmers negotiate
what will be done in the next iteration, the programmers estimate the time to complete
each card, and the customers prioritise, alter, and de-scope as needed, so that the most
valuable stories are implemented in the allotted time period (Cockburn, 2002).
Furthermore, keeping the customer closely involved during the whole innovation process
will probably lessen the situation where the documentation becomes an end in itself. The
purpose of the documentation should be to make the agreed features understandable to all
stakeholders.
Insecurity about customer needs and product requirements, resource allocation, and
setting up schedules are considerable problems between the FEI and the product
development phase. Especially fixed product features tend to be agreed on at a very early
phase of the innovation process, even though the customer does not necessarily know
how to specify the final product features. As the product development process proceeds,
the possibilities to influence on the final product usually become more difficult and
expensive. In agile methods extensive up-front design is not required (Abrahamsson
et al., 2002), and there is no fixed implementation plan for the final software. Change
management is treated as one of the values of agile methods: responding to change over

94

L. Hannola et al.

following a plan (Cockburn, 2002). The customers and the development team are in
continuous interdependence, where jointly prioritised requirements are implemented as
an incremental development process. The iterative process provides an opportunity to
verify the outcomes of the process with short iterations, and the attendance of the
customers gives them the opportunity to validate their needs regularly. According to
Lindstrm and Jeffries (2004), the most important aspect is that the software is visible,
and given to the customer at the end of each iteration, which keeps everything open and
tangible.
Table 2

Potential solutions for the problems in the waterfall model and the innovation process

Waterfall model
problem

Innovation process
problem

Heavy
documentation

Heavy documentation

Fixed
specifications

Goal for fixed

specifications to
control FFE and NPD

Change
management

Change management
becomes more
difficult towards the
end of the process

Priorisation of features with

customers

Agile methods solution

Agile methods tool

Illustrating requirements as
customer stories,

Info radiator,

Low-tech documentation

Planning game

Iterative and flexible process,

Big front end

specifications are
not required

Short increments

White board,

Planning game,
Backlog

Iterations,
Collective ownership

Transfer of
know-how

Transfer of knowhow

Shared workplace

Communication

Continuous communication
by effective channels,

War room,
Scrum,
Pair programming,

Communication

Interaction within
individuals over
tools,
Daily meetings

Continuous customer
involvement
Absence of FFE

Fuzziness of FFE

Several FFE loops during a

project

Backlog,
Unpredictability is
expected

One of the challenges in the innovation and SD processes is the transfer of knowledge
and know-how between cross-functional teams. The importance of this kind of
knowledge transfer is often neglected. In many organisations, there exist huge amounts of
additional and overlapping work, misunderstandings, and incorrect versions of design
documents due to problems in communication. Agile software methodologies have
provided several solutions to this problem. For instance, Mobile-D recommends a war
room and XP a caves and common room, where the whole SD is centralised into the
same space. The phrase caves and common refers to the creation of two zones in the
room, where common area is organised for communication and information transfer, and
the caves portion of the room is organised to give people a private place to deal with
e-mail, make phone calls, and take care of their need for separation (Cockburn, 2002).

Application of agile methods in the innovation process

95

Furthermore, all materials produced and needed during a development project are found
in the same room. In addition, several agile methods utilise information radiators on the
wall. The information radiator displays information about the development project, e.g.,
incomplete assignments, completed features, and identified tasks to be completed. Thus,
all the relevant information is in the same room to facilitate communication, and for the
transfer of knowledge and know-how.
Pair programming in XP, where two programmers sit side by side at the same
computer, provides a better code and tests, as well as serves for communicating
knowledge throughout the team (Lindstrm and Jeffries, 2004). Daily and weekly
meetings in scrum are organised to keep track of the progress of the team continuously,
they serve as planning meetings, and also problems and other variable matters are
discussed and controlled in them (Abrahamsson et al., 2002). Working in pairs prevents
overlapping work, enables also the transfer of tacit knowledge, and continual short
meetings help the participants to focus on current tasks and problems to be solved.
The term FFE is not commonly used in SD. Opportunity identification and ideas for
new software products are typically regarded as inputs to SD, and they are generated
before the requirements specification phase of the waterfall model. This may lead to a
problem, where new ideas, needs and requirements never reach SD, especially if they
come after the final set of requirements have been accepted for implementation.
Koen et al. (2002) divide the innovation process into FFE, the NPD process, and
commercialisation, and the activities in the FFE are often chaotic, unpredictable and
unstructured. Regardless of the differences in the front end phase, both the innovation
process and SD have recognised that the most significant benefits can be achieved
through improvements in the front end activities. The iterative process of agile methods
provides several FFE loops during the development project by means of customer
involvement, short iterations and readiness for change.

Discussion and conclusions

The phases of the traditional SD process (or the waterfall model) and the innovation
process are rather similar. However, the implementation of the waterfall model in
practice has been found to be challenging due to its formal structure and inflexibility.
Therefore, the waterfall model has been developed further, and the latest development
step is the emergence of methodologies, which are referred to as agile SD methods. The
objective of different agile methods is to offer quick customer value, and to produce
feasible software versions with iterative SD.
The objective of this study was to investigate whether the practices and solutions of
agile methods could be utilised for improving the performance of the innovation process.
The study was conducted by comparing the evolution of the process models, and
discovering the most significant problems in software and innovation processes. As a
result, the following main challenges were identified: heavy documentation, change
management during the development project, transfer of knowledge and know-how
between cross-functional teams, and pressures to fixed specifications related to the size,
schedule and costs of the project. As a practical contribution of the study, agile SD
methods could provide the following agile guidelines for improving the innovation
process:

96

L. Hannola et al.

The light user stories utilised in agile methods could provide a solution for the heavy
documentation of the innovation process. Customers needs are translated into user
stories in a way that both the customers and the development team understand and
interpret the problem and needs in the same way.

Understanding the customers needs and translating the needs into product features
has been recognised to be challenging, and so has the inconsistency with the
demands for a quick start of a product development project. There have also been
problems in scheduling and resource allocation of product development. Agile
software methodologies provide solutions by giving up fixed implementation plans.
Replacing the extensive pre-planning with continuous interdependence between the
customers and the development team enables an incremental product development
process.

One of the biggest challenges in the innovation process is the transfer of knowledge
and know-how between cross-functional teams. Misunderstandings and problems in
communication cause additional work. Agile methods emphasise practices that
improve the transfer of knowledge and know-how, e.g., a war room or a common
space, where the development team, all materials and other data related to the project
can be found. In addition, the concepts of pair-programming and information radiator
contribute to successful transfer of knowledge.

Agile methodologies strengthen and update the tacit knowledge of an organisation

more than explicit knowledge. Thus, the adoption of the abovementioned practices of
agile methodologies into the innovation process could strengthen its performance by
increasing the transfer of tacit knowledge within the organisation.

The traditional state-gate model for directing a product development project could be
changed to change- and customer-driven reviews, where instead of only making the
go/no-go decisions of the development project, the meetings could be utilised as
reviews of the implemented features and prioritisation of new needs of the customer.

The iterative process of agile methods integrates the FFE to the product development
as continuous loops during the development project by means of customer
involvement, short iterations and readiness for change.

As a conclusion, this study provides several agile guidelines to managers and project
team members for improving the innovation process. The agile SD methods and practices
could provide several improvements into the modern innovation process regarding
organisational practices, transfer of know-how and knowledge (tacit and explicit),
understanding customers needs, integrating the FFE into the entire innovation process,
and improving the communication, collaboration, and coordination of the innovation
process. For further validation of the proposed agile guidelines, we consider that an
important area for future research is to validate the proposed agile guidelines in product
development organisations.

Acknowledgements
The authors would like to express their gratitude to the anonymous reviewers whose
constructive comments helped us to improve our manuscript.

Application of agile methods in the innovation process

97

References
Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J. (2002) Agile software development
methods review and analysis, VTT Publications 478, Otamedia Oy, Espoo, Finland.
Anand, H. and Pandya, K.V. (2008) Role of innovation in IT in achieving its business objectives: a
case study, Int. J. Business Innovation and Research, Vol. 2, No. 3, pp.289313.
Apilo, T., Taskinen, T. and Salkari, I. (2007) Johda Innovaatioita (Manage Innovations), in
Finnish, Talentum Media Oy, Helsinki, Finland.
Boehm, B. (1988) A spiral model of software development and enhancement, Computer, Vol. 21,
No. 5, pp.6172.
Cockburn, A. (2002) Agile Software Development, Pearson Education Inc., Boston.
Dershin, H. (2010) A framework for managing innovation, Int. J. Business Innovation and
Research, Vol. 4, No. 6, pp.598613.
Dyb, T. and Dingsoyr, T. (2008) Empirical studies of agile software development: a systematic
review, Information and Software Technology, Vol. 50, Nos. 910, pp.833859.
Galanakis, K. (2006) Innovation process, make sense using systems thinking, Technovation,
Vol. 26, No. 11, pp.12221232.
Gary, K., Enquobahrie, A., Ibanez, L., Cheng, P., Yaniv, Z., Cleary, K., Kokoori, S., Muffih, B.
and Heidenreich, J. (2011) Agile methods for open source safety-critical software, Software:
Practice and Experience, Vol. 41, No. 9, pp.945962.
Gassmann, O., Sandmeier, P. and Wecht, C. (2006) Extreme customer innovation in the front-end:
learning from a new software paradigm, International Journal of Technology Management,
Vol. 33, No. 1, pp.4666.
Hannola, L. and Ovaska, P. (2011) Challenging front-end-of-innovation in information systems,
Journal of Computer Information Systems, Fall, Vol. 52, No. 1, pp.6675.
Herstatt, C., Verworn, B., Stockstrom, C., Nagahira, A. and Takahashi, O. (2006) Fuzzy front
end practices in innovating Japanese companies, Management of Technology and Innovation
in Japan, pp.167183, Springer, Berlin, Heidelberg.
Kess, P. and Haapasalo, H. (2002) Knowledge creation through a project review process in
software production, International Journal of Production Economics, Vol. 80, No. 1,
pp.4955.
Kettunen, P. (2009) Adopting key lessons from agile manufacturing to agile software product
development a comparative study, Technovation, Vol. 29, Nos. 67, pp.408422.
Khurana, A. and Rosenthal, S.R. (1998) Towards holistic front ends in new product
development, Journal of Product Innovation Management, Vol. 15, No. 1, pp.5774.
Kim, J. and Wilemon, D. (2002) Strategic issues in managing innovations fuzzy front-end,
European Journal of Innovation Management, Vol. 5, No. 1, pp. 27-39.
Koen, P., Ajamian, G., Boyce, S., Clamen, A., Fisher, E., Fountoulakis, S., Johnson, A., Puri, P.
and Seibert, R. (2002) Fuzzy front end: effective methods, tools, and techniques, in
Belliveau, P., Griffin, A. and Somermeyer, S. (Eds.): The PDMA ToolBook for New Product
Development, John Wiley & Sons, Inc., New York, USA.
Koivuniemi, J. (2008) Managing the front end of innovation in a networked company environment
combining strategy, processes and systems of innovation, PhD dissertation, Acta
Universitatis Lappeenrantaensis 334, Lappeenranta University of Technology.
Lindstrm, L. and Jeffries, R. (2004) Extreme programming and agile software development
methodologies, Information Systems Management, Vol. 21, No. 3, pp.4152.
Mishra, D. and Mishra, A. (2009) Effective communication, collaboration, and coordination in
extreme programming: human-centric perspective in a small organization, Human Factors
and Ergonomics in Manufacturing, Vol. 19, No. 5, pp.438456.

98

L. Hannola et al.

Misra, S.C., Kumar, V. and Kumar, U. (2009) Identifying some important success factors in
adopting agile software development practices, The Journal of Systems and Software,
Vol. 82, No. 11, pp.18691890.
Nambisan, S. and Wilemon, D. (2000) Software development and new product development:
potentials for cross-domain knowledge sharing, IEEE Transactions on Engineering
Management, Vol. 47, No. 2, pp.211220.
Ovaska, P. (2009) Information Systems Development in Theory and Practice: Coordination,
Methods and Processes, VDM Verlag Dr. Mller Aktiengesellschaft & Co., Germany.
Palmer, S.R. and Felsing, J.M. (2002) A Practical Guide to Feature-Driven Development, Upper
Saddle River, Prentice-Hall.
Piirainen, K., Kortelainen, S., Elfvengren, K. and Tuominen, M. (2010) A scenario approach
for assessing new business concepts, Management Research Review, Vol. 33, No. 6,
pp.20408269.
Poppendieck, M. and Poppendieck, T. (2003) Lean Software Development: An Agile Toolkit,
Addison-Wesley, Upper Saddle River.
Rothwell, R. (1994) Towards the fifth-generation innovation process, International Marketing
Review, Vol. 11, No. 1, pp.731.
Rubin, E. and Rubin, H. (2011) Supporting agile software development through active
documentation, Requirements Engineering, Vol. 16, No. 2, pp.117132.
Salo, O. (2006) Enabling software process improvements in agile software development teams and
organisations, VTT Publications 618, Otamedia Oy, Espoo, Finland.
Salo, O. and Abrahamsson, P. (2008) Agile methods in European embedded software development
organizations: a survey on the actual use and usefulness of extreme programming and scrum,
IET Software, Vol. 2, No, 1, pp.5864.
Schwaber, K. (1995) Scrum development process, OOPSLA95 Workshop on Business Object
Design and Implementation, Springer-Verlag.
Sommerville, I. (2001) Software Engineering, Addison-Wesley, Harlow, England.
Takeuchi, H. and Nonaka, I. (1986) New product development game, Harvard Business Review,
JanuaryFebruary, pp.137146.
Thummadi, B.V., Shiv, O., Berente, N. and Lyytinen, K. (2011) Enacted software development
routines based on waterfall and agile software methods: socio-technical event sequence study,
Lecture Notes in Computer Science, Vol. 6629, pp.207222.
Tidd, J., Bessant, J. and Pavitt, K. (2005) Managing Innovation: Integrating Technological, Market
and Organizational Change, 3rd ed., John Wiley & Sons Ltd., Chichester, England.
Trott, P. (2005) Innovation Management and New Product Development, Pearson Education
Limited, Essex, England.
Vijayasarathy, L. and Turk, D. (2012) Drivers of agile software development use: dialectic
interplay between benefits and hindrances, Information and Software Technology, Vol. 54,
No. 2, pp.137148.
Wallin, C., Ekdahl, F. and Larsson, S. (2002) Integrating business and software development
models, IEEE Software: Focus the Business of Software Engineering, November/December,
Vol. 19, No. 6, pp.2833.