Description
Agile development methods such as extreme programming (XP), SCRUM, Lean Software Development (Lean SD) and others have gained much popularity during the last years.
SOFTWARE PROCESS IMPROVEMENT AND PRACTICE
Softw. Process Improve. Pract. (2009)
Published online in Wiley InterScience
(www.interscience.wiley.com) DOI: 10.1002/spip.420
The Impact of Agile
Principles on
Market-Driven Software
Product Development
Research Section
Nina Dzamashvili Fogelstr¨ om,
1
* Tony Gorschek,
1
Mikael Svahnberg,
1
and Peo Olsson
2
1
Department of Systems and Software Engineering, Blekinge Institute of
Technology, PO Box 520, S-372 25 Ronneby, Sweden
2
Ericsson AB, Business Unit Multimedia
¨
Olandsgatan 1, Box 518 S-371 23
Karlskrona, Sweden
Agile development methods such as extreme programming (XP), SCRUM, Lean Software
Development (Lean SD) and others have gained much popularity during the last years. Agile
methodologies promise faster time-to-market, satis?ed customers and high quality software.
While these prospects are appealing, the suitability of agile practices to different domains and
business contexts still remains unclear. In this article we investigate the applicability of agile
principles in the context of market-driven software product development (MDPD), focusing on
pre-project activities. This article presents results of a comparison between typical properties
of agile methods to the needs of MDPD, as well as ?ndings of a case study conducted at
Ericsson, an early adopter of agile product development. The results show misalignment
between the agile principles and needs of pre-project activities in market-driven development.
This misalignment threatens to subtract from the positive aspects of agile development, but
maybe more importantly, threaten the overall product development by disabling effective
product management. Copyright © 2009 John Wiley & Sons, Ltd.
KEY WORDS: market-driven software development; software product management; agile methods; case study
1. INTRODUCTION
Agile methods are attractive to software companies
since they promise shorter time-to-market, as well
as higher ?exibility to accommodate changes in the
requirements and thereby increased ability to react
?
Correspondence to: Nina Dzamashvili Fogelstr¨ om, Depart-
ment of Systems and Software Engineering, Blekinge Institute of
Technology, PO Box 520, S-372 25 Ronneby, Sweden
†
E-mail: [email protected]
Copyright © 2009 John Wiley & Sons, Ltd.
to changing customer (market) needs (Williams and
Cockburn 2003, 2005).
The major feature of agile methods is to use
iterations of small development projects developing
limited sets of the most important functionality at a
given point in time. The common property of agile
methods is reactive rather than proactive tactics,
encouraging quick adaptation to change rather
than planning for it. The goal of agile methods
is to eliminate long pre-study and analysis of
requirements and start feature production as soon
as possible. The positive aspect of this approach is
that it speeds up the production of functionality that
Research Section
N. Dzamashvili Fogelstr¨ om et al.
is considered important at present; the downside is
that it limits the possibility to control and plan the
content of a release (Boehm 2002, Williams and
Cockburn 2003).
The ?exibility and ability to quickly respond to
market ?uctuations makes agile/lean development
methods attractive for companies operating in a
market-drivencontext, despite the fact that the long-
term impact of adopting these principles and their
applicability in the market-driven context are to a
large extent unknown. Existing studies and experi-
ence reports from application of agile methods are
mostly isolated to evaluating the performance of
these methods on software development activities,
such as increasingdevelopers’ ef?ciency, producing
better quality code and so on (Dyb? a and Dingsøyr
2008). Isolated experience articles on increased cus-
tomer satisfaction exist, but then the studied project
was developed according to bespoke practices, i.e.
in a customer–developer relationship with a con-
tractually bound effort and not in a market-driven
context (Mannaro et al. 2004, Mann and Maurer
2005).
To the best of our knowledge, currently there
are no studies analyzing the impacts of agile/lean
development principles on either pre-project activ-
ities, such as product planning/management in
MDPD, or the long-term impact of optimising the
project perspective rather than that of products or
product portfolios.
The most important aspects of MDPDare require-
ments triage (initial selection), requirements pri-
oritisation and planning (release planning), i.e.
deciding which of the thousands of potential
requirements should be implemented, and when
(Carlshamre 2002, Karlsson et al. 2003, Regnell et al.
2005). The main task of product management is
to weigh all types of criteria ranging from market
demands, trends, key-customer demands, to tech-
nical and long-term product impact, and arrive at
decisions supported by the company and product
strategy. Selecting the best sub-set of requirements
for implementation has to take both the long-term
and short-term perspectives into account as well as
market-pull and technology-push.
In light of the effect of pre-project activities on the
success of any company practicing market-driven
development, it becomes important to know what
kind of impact agile principles have on product
management and critical pre-project activities such
as initial requirements triage, prioritisation, and
release planning. This is important in order to
determine to what extent agile principles can be
adopted in market-driven organisations, and what
product management and pre-project practices
should be in place to maximise the positive aspects
of lean development in projects (Carlshamre 2002,
Karlsson et al. 2003, Regnell et al. 2005).
This article investigates the impact of agile princi-
ples on pre-project activities in MDPD by studying
an industry case. The study is performed in collab-
oration with Ericsson AB in Sweden, where a large
effort to move from‘traditional’ pre-study intensive
development to lean development (agile) has been
ongoing for over 3 years. An early evaluation of the
move to lean development and its potential was
presented by Tomaszewski et al. (2008). The case
study in this article presents a postchange evalua-
tion at the same company, but from the perspective
of pre-project activities and the potential misalign-
ment between the needs of product management
and agile principles. In addition to this, the arti-
cle also quali?es the challenges with future research
directions andsuggestions as howthe misalignment
could be handled.
The rest of this article is outlined as follows:
Section 2 provides a background to agile software
development and market-driven software product
development (MDPD) where the common aspects
of agile methods are put against the special
needs in a market-driven context. Further, a short
overview of empirical evidence on agile methods is
provided. Section 3 gives details on study design
and execution. Case study results, analysis, and
discussion can be found in Section 4 and Section 5
respectively. The report is ?nalised by conclusions
and future work in section 6.
2. BACKGROUND AND RELATED WORK
2.1. Common Aspects of Agile Software
Development Methods
The introduction of extreme programming (XP) in
the late 90s is commonly acknowledgedas a starting
point, coining the term agile in software develop-
ment. In2001 other agile initiatives suchas Dynamic
Systems Development Method (DSDM), Crystal,
Feature Driven Development, and SCRUM joined
XPandthe ‘Agile Manifesto’ was formeddescribing
the ideas and agile commonalities (Abrahamsson
et al. 2003, Cohen et al. 2004).
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Nowadays agile methods are quite popular and
are seen as an alternative to the traditional plan-
driven methods, which thus far have been the
basis for accepted practices in software engineer-
ing (Abrahamsson et al. 2003, Cohen et al. 2004,
Tomaszewski et al. 2008). Plan-driven methods are
characterised by heavy upfront planning, focus on
documentation, predictability, and repeatable pro-
cesses (Boehm 2002). Lately these methods have
been criticised for their inability to accommodate
change and the high costs that are associated
with updating documentation and plans (High-
smith and Cockburn 2001, Poppendieck and Pop-
pendieck 2003, Lef?ngwell 2007). On the other
hand, agile methods are designed to accommodate
rapid change (Beck 2000, Williams and Cockburn
2003). In order to be ?exible, agile methods rely
on individuals and their knowledge rather than
processes, value working piece of software over
complete requirements speci?cations and design
plans; and encourage responding to a change rather
than planning for it (Manifesto for Agile Software
Development 2008).
The latest contribution to the agile commu-
nity, Lean Software Development (Lean SD) (Pop-
pendieck and Poppendieck 2003), is based on a
collection of attitudes and principles originating
from the successful concepts of lean manufacturing
developed by Toyota known as the Toyota pro-
duction system (Womack et al. 1991). The original
lean manufacturing principles at Toyota (Elimi-
nate waste, Amplify learning, Decide as late as
possible, Deliver as fast as possible, Empower the
team, Build integrity, etc.) are based on continuous
improvement and elimination of waste. Since these
principles are rather general they can be interpreted
and adapted to suit different applications and busi-
ness domains, for example software development.
This can be seen as an advantage as the appli-
cability of agile methods are generally considered
to be limited to small- to medium-sized enterprise
developing medium-sized non-critical applications
(Boehm 2002, Williams and Cockburn 2003, Sillitti
et al. 2005). However, the current translation of lean
principles to software development (Poppendieck
and Poppendieck 2003) is fully compliant with, or
even designed after, existing agile principles. This
might imply a limitation of this potential, limiting
the ?exibility of the origin ideas behind the lean
development.
In general, agile methods may vary when it
comes to the speci?c application of certain practices.
However, they all follow the main principle of
producing working software in small iterations,
and utilising small teams of dedicated individuals
that focus on software development. The common
aspects of agile methods can be summarised by
the following principles [hereafter called Agile
Property (AP)] (Highsmith and Cockburn 2001,
Abrahamsson et al. 2003, Cohen et al. 2004):
• AP1. Feature orientation: The main focus is on
the production of features as soon as possible.
The goal is to deliver working functionality that
is perceived to have the most value for the
customer, and this is done in small and frequent
iterations.
• AP2. Reactive development: Reactive develop-
ment is about responding to a change instead of
planning ahead, and delaying decisions as long
as possible. Agile methods promise ?exibility
and follow the ideology that one can not con-
trol the world, thus the strategy is to respond
to a change rather than plan for it. Examples
of reactive practices are refactoring, adjusting
requirements’ priorities, and release scope after
each iteration and delaying decisions for as long
as possible.
• AP3. Evolving project (release) scope: Perhaps
one of the main distinguishing features of agile
development is the change from a ?x-scope
approach to a more open-ended approach. In
the traditional ?x-scope approach much effort is
spent on de?ning and planning the content of
a product release of a project upfront. In agile
the release scope is emerging in the process
of development rather than planned ahead. A
prioritised list of requirements (product backlog
in SCRUM and prioritised user stories in XP)
serves as an initial input which is a kind of
wish-list of a release scope. The release scope
is expected to be re?ned and updated at the
end of each iteration in order to accommodate
changes and new information that was learned
in the latest iteration. This practice is in line with
the reactive development property described
in AP2.
2.2. Speci?c Needs of MDPD
In MDPD software products are often developed
as product families that are offered to a mass
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
market rather than a speci?c customer. The product
development has an iterative character where new
versions of the product are delivered to the market
via established release cycles (Dahlstedt et al. 2003,
Gorschek and Wohlin 2006).
The fact that the product is not ordered and
developed to suit the wishes and needs of one
speci?c customer creates special needs distinguish-
ing the characteristics of this type of develop-
ment from customer-speci?c (bespoke develop-
ment)(Potts 1995). In a bespoke situation the devel-
opment organisation can rely on the customer to
decide what functionality should be included in
the product and this information can be elicited
directly from the customer. However, in market-
driven development this is not feasible as there
are any number of potential customers. Instead
the development organisation itself decides what
functionality should be delivered to what market
segment and when (Potts 1995, Karlsson et al. 2003,
Ebert 2005, Regnell et al. 2005, van de Weerd et al.
2006). This creates a special focus on pre-project
activities usually associated with product planning
and management operations (van de Weerd et al.
2006). The speci?c needs of MDPD are summarised
below:
• N1. Balancing different requirements types:
Selecting a set of requirements that will be
included in future releases of a product is one
of the most important strategic decisions in
MDPD. This decision is based on comprehen-
sive analysis of the company’s business intel-
ligence, product planning and road-mapping,
marketing and sales information, and strate-
gic assets such as engineering know-how and
investments in product architecture (Greer and
Ruhe 2004, Ebert 2005, Regnell et al. 2005,
Saliu and Ruhe 2005). The speci?cs of this
task require that the development organisation
must ?nd an optimal balance between different
requirement types such as commercial require-
ments, innovations, requirements connected to
architecture improvements and also balance
quality attributes like maintainability, perfor-
mance, scalability, and usability across different
releases.
• N2. Trade-off between market-pull and tech-
nology-push: Studies in relation to MDPD have
shown that the development organisation not
only needs to respond to the current consumer
needs but also anticipate future needs as well as
in?uence the needs of the consumers via inno-
vations and technology breakthrough. Finding
a balance between market-pull and technology-
pushis consideredone of the challengingaspects
for companies operating in this context as it
indirectly involves balancing low- and high-risk
as well as long- and short-term considerations
(Karlsson et al. 2003, Regnell et al. 2005).
• N3. Release content planning (requirements
selection): Planning the content of a speci?c
release is recognised as one of the most chal-
lenging parts of MDPD (Carlshamre et al. 2001,
Carlshamre 2002, Greer and Ruhe 2004). This
activity occurs after a large number of initial
requirements have been ?ltered through the
steps of requirements triage/screening and pri-
oritisation. The reducedamount of requirements
is then considered for inclusion for a speci?c
release, which is the task of release scope plan-
ning. The ultimate goal of this activity is to ?nd
a selection of requirements that will give the
best possible return on investment (ROI) and
will be feasible to implement within a given
time- and resource-frame. The main character-
istics of this task require ?nding an appropriate
balance between relative cost and value of each
requirement, technical and business dependen-
cies betweenrequirements, andavailable budget
and resources at hand. The outcome of this
activity results in a list of requirements that con-
stitutes the plannedscope of a release. Havingan
establishedrelease scope is important fromthree
main aspects. One, it enables decision makers to
estimate and plan for the total value of a release,
and a comparison to the total value needed for
a speci?c market segment at a certain time. The
goals of a release may be combinatory in nature,
i.e. several projects in collaboration over time
can together offer a speci?c value for the mar-
ket. Two, a set release scope provides a baseline
that can be used to effectively evaluate emerging
changes with respect to how this change affects
the total value and cost of a release. This pro-
vides a basis for informed decisions and helps
managers to not only react but also ?nd the best
waytoreact ona givenchange. Three, it provides
a possibility to plan and implement long-term
product development and innovation that are
not based on current customer wishes but focus
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
on, for example, system evolution goals that go
beyond the project perspective.
2.3. Applying Agile Principles in MDPD
In order to understand the possible impact of agile
methods on pre-project activities, the properties
of agile methods described in Section 2.1 are put
against the needs of MDPDdescribed in Section 2.2.
The result is presented in Table1.
In Table 1, AP1 is put against N1 since fea-
ture orientation by de?nition favors feature-type
requirements thereby being the opposite of creating
a balance between different requirement types such
as feature and non-functional requirements. AP2:
Reactive development is associated with N2, i.e.
the need of ?nding trade-off between market-pull
and technology-push since there is a risk that the
agile view of adopting and reacting to customer
needs results in the company becoming too focused
on responding to current market needs and thus
being unable to push innovative ideas that do not
directly originate fromthe market or key-customers
at present. This can have devastating effects on the
long-term, invisible to the project perspective which
is inherentlyfocusedondeliveringthe requirements
relevant from the project perspective.
Using an evolving release scope (AP3) is by
de?nition at odds with planning the release scope
(N3) as it limits the decision maker’s ability to
actively control and in?uence release content. As
presented in Section 2.2 in MDPD there is a
need for an established release scope, where the
decision on what is included in a release is based
on careful analysis of all candidate requirements
(Carlshamre 2002, Greer and Ruhe 2004, Saliu and
Ruhe 2005, Ngo-The and Ruhe 2008). In contrast,
an agile project release scope is loosely de?ned
and is based on rough estimates and the initial
feelings of the customer about the requirements.
The intention in an agile project is not to have
Table 1. Agile properties vs. MDPD needs
Agile property Affected MDPD need
AP1. Feature
orientation
N1. Balancing different
requirements types
AP2. Reactive
development
N2. Trade-off between
market-pull and technology-push
AP3. Evolving
release scope
N3. Release content planning
the best selection but to re?ne the scope during
the course of development (Beck and Fowler 2001,
Poppendieck and Poppendieck 2003, Williams and
Cockburn 2003, Lef?ngwell 2007).
The lack of alignment between the properties
of agile methods and the needs of MDPD can be
further explored by studying certain assumptions
made in agile development methods and mapping
them to the product development practices in
market-drivencontext. These assumptions are listed
in Table 2. Each is elaborated upon below.
• Development context: Agile methods are bes-
poke in origin (Karlstrom and Runeson 2005)
and largely focus on a speci?c project rather
than long-term product development common
to MDPD where the focus is on the product
or product families offered to any number
of potential customers. Success in a bespoke
(project) perspective is the successful completion
of the project ful?lling the needs of the customer.
Table 2. Agile assumptions and MDPD reality
Agile methods MDPD
Development
context
One
customer – focus
on a speci?c
project. The
project is central.
Many potential
customers – focus
on a product or
product family.
Development is
focused on the
product, and any
number of
projects can
contribute to a
release.
Business context Customer owns
the product and
?nances the
development
effort.
Development
organisation owns
the product and
?nances the
development
activities itself.
The release
scope can be
unde?ned and
negotiated.
The release scope
needs to be
de?ned and is not
easily
renegotiable.
Understanding of
value
Simple. Complex.
Assumptions about
requirements
Requirements
are at large
unknown.
Requirements are
known through
market
investigations and
business
intelligence.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Success from a market-driven perspective is
measured in sales, revenue, market growth, and
the ability to create and maintain a ?exible
product architecture that will support future
product releases. Thus the difference between
agile and MDPD context is both in the scale
and the complexity of the projects. For example
creating a maintainable product architecture
is not as critical in a small bespoke project
compared to a project that is part of a large-
scale product development effort of a product
that will have a long life span.
• Business context: Agile methods assume that
the customer is responsible for identifying valu-
able requirements and ?nancing development
activities, as well as that the scope of the release
or a project is negotiable. In contrast in MDPD
the development organisation itself is respon-
sible and has to decide what requirements are
valuable for a current release and for ?nding
?nancial resources to develop the selected set
of functionality. The contents of the release can-
not be negotiable in the same sense as in agile
projects as there is no speci?c customer, rather
the decision of what to develop is arrived at
after complex deliberation involving product
management, marketing, key-customers, sales
and upper management, as well as long-term
plan in?uence. In fact, the scope of the release
has to be de?ned since it is quite common that
product management need to produce a mar-
keting message on what is to be expected in
the next release of the product long before the
development activities are ?nished (or even ini-
tiated). Applying the concept of evolving release
scope has some economical consequences as well
where the developing organisation (which in
MDPD stands for the development costs itself)
must evaluate how much updating, refactor-
ing and other correcting after-the-fact activities
can be afforded by a company that has to
deliver a certain value at a de?ned market
window time-point. In MDPD time-to-market
is generally seen as being of paramount impor-
tance.
• Understanding of value: Agile methods focus
oncreatingrapidvalue for a speci?c customer. In
MDPD the de?nition of what constitutes value
is more complex and the potential value for
a speci?c customer is just one component of
a value measure (this relates to N1 and N2
presented in Section 2.2). Also, agile methods
assume that the value of rapidly developedfunc-
tionality can be con?rmed by a customer or an
on-site customer representative almost immedi-
ately. InMDPDthe validationof perceivedvalue
of developed functionality requires longer lead-
times as well as different tools, for example GAP
analysis, customer value analysis (CVA) and
focus groups (Gorschek 2006). An agile project
member cannot go to an on-site customer as
this representative does not exist. The concept
of value not only transcends any one customer
but also the project itself. For example, a project
can be a part of a long-termdevelopment plan to
offer infrastructure to subsequent development
down the line. From a project perspective most
of the project contents might seem as waste, but
from a product perspective the view is another
(Gorschek and Davis 2008).
• Assumptions about requirements: Agile meth-
ods assume that at the beginning of the develop-
ment project requirements are largely unknown.
This is not the case for MDPDwhere large efforts
have been devoted to collecting large amounts
of potential requirements, whichundergo triage,
and subsequent re?nement and selection (and
packaging) prior to the project being created
(Potts 1995, Karlsson et al. 2003, Ebert 2005, Reg-
nell et al. 2005, van de Weerd et al. 2006). This
does not mean that the requirements given to a
project are perfect or even complete, but it does
mean that there has been a deliberate and critical
effort to select and deliver a set of requirements
to the project.
As a consequence to these differences in assump-
tions and properties of agile development methods
and MDPD needs, it seems reasonable to assume
that applying agile principles in this context will
have certain consequences on pre-project activities
connected to requirements selection and product
planning. This is the focus of this article and the
case study presented in sections 3 and 4.
First a background to agile development is given
with focus on reporting experiences from industry
usage.
2.4. Empirical Studies on Agile Methods
Agile software development models are relatively
new and have not been tested to the same
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
extent as traditional software development models
(Abrahamsson et al. 2003). A large part of the
existing empirical evidence regarding agile meth-
ods is focused on XP. Here research efforts are
mainly focused on studying isolated practices, such
as pair programming or test-driven development
(Erickson et al. 2005). When it comes to the impact
of agile methods onsoftware development activities
a number of case studies exist. These studies report
improvements in the quality of the developed code,
increasedeffectiveness andproductivityof software
developers, and customer satisfaction (Middleton
2001, Ilieva et al. 2004, Layman et al. 2004, Man-
naro et al. 2004, Mann and Maurer 2005). However,
a closer examination of these studies shows that
most of them focus on identifying the effect of agile
principles on in-project activities, and that observed
effects are primarilyidenti?edinthe context of small
development teams developing small- to medium-
sized applications. These results are in line with
the ?ndings of Abrahamsson et al. (2003), who in
their survey concluded that there is a lack of sound
empirical evidence to support the applicability of
agile methods in different development contexts
and application domains.
Empirical evidence in relation to the application
of agile practices in large-scale contexts is quite
scarce. In a recently conducted systematic review
of empirical studies on agile software development
270 reports were identi?ed as containing empirical
results on agile development methods (Dyb? a and
Dingsøyr 2008). After assessment of these according
to the principles of what constitutes good practices
of empirical research, only 33 of the original 270
were considered as credible empirical reports.
Out of these only a small fraction, two reports
(Dagnino et al. 2004, Karlstrom and Runeson 2005),
report on application of agile principles in large
organisations. Both of these studies focus on in-
project activities and report positive results of
applying agile principles. It is important to notice
though that in the works of Karlstromand Runeson
(2005) the application of XP practices was done
in the context of small pilot teams. Information
about the context of development size of developing
project and which XP practices had been applied
was unfortunately missing. In the works of Dagnino
et al. (2004) a rather conservative version of agile
development methodology was used to produce a
prototype for an internal customer.
2.4.1. Empirical Studies on the Impact of Agile
Methods on MDPD
When reviewing existing knowledge and research
on agile methods it is easy to notice that most of
the empirical reports focus on analyzing the impact
of agile methods on in-project activities such as
software design, development and test activities,
when studies focusing on pre-project activities and
product management in general are quite rare (see
Section 2.4).
Recently there has been interest in investigating
the application of agile methods for product line
engineering (PLE) (Clements and Northrop 2002),
which have some similarities with product man-
agement activities. At the current stage however
the research in this area is quite new, focusing on
studying in what way agile principles and PLE
activities can be combined (Tian and Cooper 2006,
Hanssen and Fægri 2008), or the application of the
selected principles of agile methods (such as col-
laboration and focus on individuals) in some PLE
activities (Noor et al. 2008).
When it comes to MDPD, to the best of our
knowledge and for the time being, studies focusing
on understanding of the impact of agile principles
on pre-project, product management activities do
not exist. This situation indicates a critical gap
in understanding, e.g. the long-term effects of
agile methods on product development. This is
especiallyrelevant whenconsideringMDPD, where
pre-project activities are critical (Regnell et al. 2005).
Studies investigating the impact of agile princi-
ples on pre-project activities are needed in order
to determine to what extent agile principles can be
adopted in the MDPD context. This can involve e.g.
how agile models need to be tailored, or what other
practices need to be in place in order to take full
advantage of positive aspects of agile development
without negatively effecting MDPD.
The case study described in this article inves-
tigates the characteristics of decision making in
Ericsson AB that has worked with adopting agile
principles over the last years. The goal of the case
study is to study and understand the character-
istics of the pre-project decision-making process
when applying agile development principles. The
identi?ed characteristics and speci?cs of the pre-
project process are analyzed in order to see if the
study ?ndings can support the expected impact of
agile principles on pre-project activities in MDPD
as described in Section 2.3.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
3. CASE STUDY SETTING AND DESIGN
The case studywas conductedduringthe fall of 2007
at EricssonABinSweden(calledEricssonhereafter).
Ericsson is one of the world’s leading companies
in telecommunication, providing a wide range of
products and solutions. The company operates in
a market-driven context where the products are
sold as generic solutions offered to an open market,
although customised versions of the products are
also developed and sold to key-customers.
With the goals of achieving higher process per-
formance and increased ?exibility when it comes
to accommodating changing requirements Ericsson
movedfroma traditional development process with
relatively extensive development projects which
lasted about a year or even more (following the
classical waterfall development steps) to lean devel-
opment. One of the main motivations for moving
to a new development process was to minimise
the number of change requests. Change requests
were associated with high development costs since
they often resulted in wasting development effort in
form of detailed analysis of requirements that were
not implemented in the ?nal product or expenses
associated with rework.
According to Tomaszewski et al. (2008), the tradi-
tional waterfall development projects at Ericsson
suffered from large number of change requests
mainly caused by long development cycles and
extensive analysis of the pre-de?ned release project
scope. The new agile development process called
Streamline (Tomaszewski et al. 2008) promised to
cut down the costs associated with the change
requests substantially. A recent evaluation of the
application of Streamline at Ericsson reports reduc-
tion of requirements volatility in the projects mainly
caused by application of small development pack-
ages and shortening the lead-time of development
projects (Petersen and Wohlin 2008). The Stream-
line development process (called only Streamline
hereafter) is strongly in?uenced by agile and espe-
cially Lean SD, and a summary of it can be found in
Section 4.1.
3.1. Research Roadmap
The goal of this study was to identify how the
introduction of Streamline has affected product
management [pre-project requirements engineering
(RE)] activities practiced at Ericsson. In order to
achieve this goal it was decided to ?rst identify
and study the process and the characteristics of pre-
project decisions at Ericsson. Collected information
was then analyzed using the structure seen in
Table 1. The intention here was to identify howwell
the study ?ndings support the anticipated impact
of agile principles on MDPD outlined in Section
2.3.
Information about the practiced pre-project activ-
ities in Streamline was gathered by means of
studying the pre-project RE decision-making pro-
cess applied in the development of three separate
products at Ericsson. Product 1 and product 2
are large mature systems with a large number of
releases operating all over the world at many cus-
tomer sites. Products 1 and 2 are over 9 years old
andhave undergone sevenandfour releases respec-
tively. Product 3 is a smaller product with only one
previous release since its creation in 2006.
In order to get an overview of the RE decision-
making process three main sources were used to
achieve a triangulation (Gorschek and Wohlin 2004)
of sources as can be seen in Figure 1.
Part A consisted of the study of of?cial process
documentation, Part B was interviews with prac-
titioners allowing for a balanced view where the
of?cial process was weighed against the one actu-
ally practiced, and Part C consisted of observations
(e.g. sitting at the meetings). The use and compari-
sonbetweendifferent sources is at the central core of
the triangulation (Gorschek and Wohlin 2004, Pet-
tersson et al. 2008). The details of study execution
are provided in Section 3.2, and the results obtained
are detailed in Section 4.
3.2. Study Execution
The initial stage was focused on studying the
of?cial process documentation in order to identify
Figure 1. Study overview of mapping pre-project RE
decisions
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
pre-project decisions, roles and responsibilities
associated with the decisions, and mapping the
decision characteristics. In addition, the study of
the of?cial process allowed a mapping of meetings
and forums for decision-making.
3.2.1. Process Documentation Study (Part A)
The documentation study was conducted by means
of reviewing of?cial process descriptions for pre-
project activities in Streamline. A senior expert,
responsible for process improvement activities was
used as a guide to the formal process in order
to identify relevant process documents. An impor-
tant selection criterion for the document study was
to consider those process descriptions and work-
?owguidelines that were commonfor development
activities.
The information provided in the process docu-
mentation was analyzed in order to identify the
major steps/activities and the decisions points
involved in pre-project RE. For each identi?ed
decision point the characteristics were mapped.
Characteristics in this case are the (i) goal(s)
for an activity, (ii) the decision criteria/method
used, and (iii) the decision support material used
and/or produced. The identi?ed roles and decision
forums were later used to plan the interviews and
observations.
3.2.2. Interviews with Practitioners (Part B)
The intention with the interviews was to elicit infor-
mation on the pre-project decision-making process
not evident from the formal process descriptions in
Part A. Semi-structured interviews were used in an
informal setting.
At the beginning of each interviewthe participant
was asked to describe the process of working
with pre-project requirements. In most cases the
interviewees would draw a ?gure of the overall
process and map the major steps/decisions in the
process.
Once the major steps and decisions were identi-
?ed the interviewcontinued detailing them and the
participants were asked a set of questions designed
to retrieve the characteristics of the decision points.
In order to allow a comparison between the formal
and practiced process, for each mentioned decision,
the interviewees answered questions on goals of a
decision, how the decisions were taken, what infor-
mation was important/necessary in order to take
a decision (decision support material used) as out-
lined in Section 3.2.1. At the end of each interview
participants were askedto identify major challenges
and improvement suggestions in relation to the
process and the characteristics.
The results of the interview were transcribed
into session summary sheets (Robson 2002) directly
after the interview session. Information placed in
these sheets followed the same template, providing
data on interviewed person, issues covered, and
researcher’s own notes regarding the information
obtained in the interview.
Once the interviews were completed, the infor-
mation from the individual interview was coded
in different data categories related to the prac-
ticed pre-project requirements decisions and their
characteristics. The utilised data categories covered
topics suchas practices requirements decision steps,
requirement types considered at each decision,
practiced approach for taking decision, required
decision material, experienced challenges, etc. The
coded data from each interview was then placed in
an excel sheet where it was analyzed again in order
to ?nd relations to the agile properties and MDPD
needs presented in Table 1.
The selection of the interview participants was
based on the process documentation where roles
involved in pre-project RE and decision-making
were identi?ed.
Further, the case study consisted of the study
of three different products at Ericsson to make
sure that the process and the characteristics studied
were representative for the organisation. Therefore
the interviewees were also selected to represent
the important roles for each of the products (see
Table 3).
In total 14 interviews were conducted. Each inter-
viewwas conducted individually. To avoid validity
issues such as the subjects feeling uncomfortable
with speaking their mind none of the interviews
were recorded. Detailed notes were taken during
the interviews, and during the subsequent re?ne-
ment of these notes supplemental questions were
posed to the interview subjects post-interview if
needed. The detailed and re?ned notes were then
used to validate understanding and avoid misinter-
pretations as they were shared with the subjects for
validation purposes. The distribution of the inter-
views was the following: Product Managers – 5;
SystemExperts – 3; Line Managers – 3; Project Man-
agers – 3.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Table 3. Roles identi?ed in pre-project RE
Name
(number interviewed)
Description Responsibility
Product Manager (5) This role has the
strategic product
responsibility and
decides the overall
product
development
direction
Select, prioritise
and plan
requirements for
future releases
System Expert (3) This role is
populated by
people with expert
knowledge of the
systems and their
architecture
Responsibility of
system
architecture and
system
development
plan
System experts
provide decision
material for product
management since
they are responsible
for providing
analysis of
pre-project
requirements, in the
form of feasibility,
impact and
technical
dependencies
Line Manager (3) Line managers have
overall
responsibility of
Development and
Testing (R&D)
resources. They
plan for R&D
utilisation in
development
projects and allocate
resources to
develop
requirements
selected by product
management
R&D capacity
overview,
planning of
development
projects
Project Manager (3) Responsible for the
detailed planning,
execution and
follow-up of
development
projects for a
speci?c release
Planning and
execution of a
speci?c project
3.2.3. Observations (Part C)
This part of the study was focused on attending
forums and meetings where pre-project decisions
were discussed. These forums were identi?ed
initially in the process study (Part A) and later
con?rmed by the process expert at the company.
Identi?ed decision forums are summarised in
Table 4.
In total four meetings were attended; Pre-project
Requirements Council (2), Release Scope re?nement
Board(1) andRelease PlanningBoard(1). Inorder to
minimise anypotential effect causedbythe presence
of a researcher the meetings were not recorded.
Instead a researcher observed the character and
content of discussions and decision-making process
during the meetings and notes were taken.
4. EMPIRICAL RESULTS
4.1. Process Documentation Study (Part A)
Figure 2 presents the major pre-project activities
in Streamline as described in the process docu-
mentation. The activities are displayed in chrono-
logical order (order of execution in the company).
Table 4. Decision forums
Name
(number visited)
Purpose
Pre-project
Requirements
Council (2)
This council consists of strategic
product managers, technical
product managers and system
experts. Decision forum is used
for decisions on which
requirements will be approved
for further analysis and how the
selected requirements will be
allocated.
Prioritisation
Workshop
Workshop participants include
product managers, system
experts and different requirement
representatives.
Decisions on which requirements
will be assigned highest priority
for the next release are taken.
Release Scope
Re?nement Board (1)
The board consists of product
manager, line manager and
system experts. Here the
decisions on approving
implementation proposals and
associated cost of a requirement
are taken.
Release Planning
Board (1)
The board consists of product
manager, line manager, system
expert and project manager. Here
the decisions regarding release
scope planning and initiating of
development projects are taken.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Figure 2. Pre-project decision making process in Streamline
As shown in the ?gure, pre-screening of incom-
ing requirements, requirements prioritisation and
release scope analysis and re?nement are the major
activities performedprior to initiating development
projects.
4.1.1. Pre-screening
According to Streamline, initial requirements are
elicited from different sources in a continuous
manner. Incoming requirements are then inserted
in the repository after which they pass through the
pre-screening step. The goal of this activity is to
identify a sub-set of requirements that is interesting
to include in a certain product. The process
involves two sub-steps: selection and analysis.
During selection requirements are analyzed in
order to determine suitability of a requirement
for a certain product. In this step requirements
that are wrongly allocated to a product, duplicate
requirements and other requirements that are
considered not suitable for a product are ?ltered
away. During analysis requirements are analyzed
to determine their business value and technical
impact. This information together with directives
from product plans and roadmaps are used to
allocate requirement to a certain release of a
product. At the end of the pre-screening step an
initial requirement is either allocated to a future
release, rejected, or considered so urgent that is
allocated to the release under de?nition.
4.1.2. Prioritisation
During this step requirements that are allocated to
a certain release are prioritised in order to produce
an initial release scope. At the end of a prioritisation
step only a small sub-set of all requirements that
are allocated to a certain release are selected to
be included in the list of prioritised requirements
for a certain release which in Streamline is called
‘Priority directive’ of a release. At the end of the
prioritisation step requirements included in the
‘Priority directive’ are handed over to the R&D
organisation (development and testing) for analysis
and realisation.
4.1.3. Release Scope Analysis and Re?nement
The goal of this activity is to analyze and package
requirements includedinthe ‘Prioritydirective’ into
small development projects each in size approx-
imately 3 months. Activities in this step have a
continuous and iterative character where require-
ments are analyzed and assigned to development
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
projects following the order of their priority in the
‘Priority directive’.
Once the priority directive is received by R&D
the initial step is to create a project anatomy plan.
The purpose of the anatomy plan is to identify
and describe functional dependencies between the
requirements in the priority directive, which are
subsequently used to update the priority order
taking the dependencies into account, resulting in a
function container list. This list provides a base for
the planning of development projects as it dictates
in which order the requirements will be analyzed
and assigned to the development projects.
When the ?rst version of the function container
list is available, R&D can start conducting techni-
cal analysis of requirements following the priority
order dictated by the list. Requirements are ana-
lyzed independently and development projects are
initiated as soon as the line management in the
R&D organisation can ?nd and allocate resources
necessary for realisation of the selected solution
proposal.
The technical analysis of eachrequirement should
take a maximum of twenty (20) person-hours and
produce a report detailing which components of
the existing system will be affected by the new
functionality, possible implementation solutions,
and a cost estimate of each solution. The results
of the technical investigation is presented at the
Release Planning Board (see Table 4) and the
solution that provides the best trade-off between
product management priorities, resource capacity,
and system architecture impact is selected. If an
acceptable trade-off cannot be reached, for example
the estimated cost of requirements implementation
is higher than expected by product management,
or the resource capacity is inadequate the priority
order of this requirement must be renegotiated.
4.1.4. Summary
Streamline is a process that tries to apply agile
principles in an MDPD context. The process has
clear characteristics of market-driven development,
where requirements are collected from different
sources and ?ltered through the pre-screening
and prioritisation steps to produce the ‘Priority
directive’ of a release.
Streamline also has a strong connection to
agile and lean development principles, which is
evident in the step of release content analysis and
re?nement. As shown in Section 4.1.3, the scope of a
release if not ?xedanddevelopment activities donot
wait until analysis of all requirements allocated to a
release are ?nalised, instead development projects
are initiated as soon as analysis of top priority
requirement allows for identifying what resources
are necessary and these resources can be allocated.
This approach is in line with the agile property
AP3 – Evolving release scope. In Streamline this
propertyis intendedto ensure that the development
effort is focused on top priority requirements and
to minimise waste connected to change requests
mentioned in Section 3.
4.2. Interviews and Observations (Part B
and Part C)
In this section we describe study results obtained
via interviews with the practitioners and conducted
meeting observations. The results are grouped
according to major pre-project steps identi?ed in
the process documentation study (see Section 4.1).
4.2.1. Results for Pre-screening (Step 1 in Figure 2)
4.2.1.1. Finding 1: Practiced Approach for Pre-screening
Interviews with the practitioners showed that in
general practiced activities followed the steps of the
documented process. However some differences
were identi?ed.
As shown in Table 5, for product 1 and prod-
uct 2 activities in pre-screening mainly focus on
de?ning if a requirement is appropriate for the
product, rather than evaluating requirement’s busi-
ness value and technical impact as prescribed by
the process documentation. This type of analysis
was performed in an informal way and no reports
were produced. Product managers for this product
explained: ‘‘we receive hundreds of requirements; there-
fore the ?rst step is to lower the volume by removing
duplicates and requirements that are wrongly allocated
to our product’’.
In the case of product 3 the pre-project activities
considered both technical analysis and value evalu-
ation. However compared to the technical analysis,
evaluation of the requirements value received little
attention. Moreover, mechanisms used for evaluat-
ing and determining value of a requirement were
not obvious. Observation of Pre-Project Require-
ments Council meetings for product 3 con?rmed
this since most of the meeting time was spent
on clarifying technical details around the require-
ments. Technical evaluation was mostly based on
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Table 5. Practiced approach for pre-screening
Approach/criteria
for pre-screening
Reqirement
types
Product 1 and
Product 2
Practiced approach
for pre-screening is
focused on
identifying:
(i) duplicates, (ii)
requirements that
are wrongly
addressed (not
applicable for a
product), (iii)
unreasonable
requirements like
‘‘you should have
no downtime’’
Commercial
requirements
from in?uential
customers and
market units
Product 3 Focus on evaluating
impact and cost of a
requirement
Commercial
requirements
from in?uential
customers and
market units
expert opinion. For requirements that were con-
sidered complex an of?cial technical report was
ordered and produced.
4.2.1.2. Finding 2: Balance between Different Require-
ment Types at Pre-screening During the interviews
product managers of eachproduct were askedto list
the different types of the requirements considered
by them during pre-screening. All product man-
agers listed commercial requirements originating
mainly from in?uential customers and marketing
units, while other types of requirements like tech-
nical and architectural improvements or product
life-cycle requirements were not mentioned.
4.2.2. Results for Requirements Prioritisation (Step 2
in Figure 2)
When it comes to requirements prioritisation,
interviews with practitioners provided detailed
information on the applied prioritisation technique
and evaluation criteria, which was missing in the
formal process descriptions. Findings identi?ed
through analysis of interview results are presented
below:
4.2.2.1. Finding 3: Practiced Approach for Prioritisation
For all the products studied the requirements
prioritisation of requirements in the overall product
planis performedevery6 months. The prioritisation
is performed in the form of a workshop where
experts with different competences participate (see
Table 4). The prioritisation is conducted using pair-
wise comparisons andsupportedby the commercial
tool Focal Point (Telelogic Focal Point – Software
for Product Management and Product Portfolio
Management 2009).
The components used as evaluation criteria
are presented below following the order of their
importance as de?ned by practitioners: (i) bene?t
(value) to company and alignment with product
strategy; (ii) bene?t (value) for potential customers;
(iii) cost; (iv) how well the requirement improves
non-functional characteristics.
For all three products the prioritisation and
qualifying the criteria, such as requirements cost
and value (for the organisation itself and potential
customers), were mainly based on expert opinion
(knowledge). Occasionally for estimating cost of
a requirement additional material such as technical
reports were used. Whenit came to estimating value
it was completely based on expert opinion. The
practitioners in general found it dif?cult to explain
the mechanism behind estimation of requirements
value. One of the product managers commented
‘‘we estimate requirements value based on the knowledge
of our product and our customers’ needs’’.
4.2.2.2. Finding 4: Balance between Different Require-
ments Types at Prioritisation At this stage of the
practicedprocess all products consideredboth com-
mercial and technical requirements. When it comes
to the question of balance between the commer-
cial and technical requirements the interviewed
system experts expressed their concern that sys-
temand architectural improvements were receiving
less attention compared to commercial require-
ments from e.g. market units and key-customers.
‘‘Internal requirements connected to architectural and
system improvement issues have a hard time compet-
ing with commercial features and often end up lower in
the prioritised list of requirements’’ mentioned one of
the system experts. Another expert noted: ‘‘system
requirements receive attention when we can show that
they are necessary for implementation of some important
commercial requirement’’. System experts anticipated
that this development could in the long run cause
deterioration of the system architecture. The inter-
views systemexperts also expressed that describing
the value of system requirements was not easy and
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
that they needed guidelines for formulating the
‘business case’ for system requirements.
4.2.3. Results for Release Scope Analysis and
Re?nement (Step 3 in Figure 2)
Analysis of the interviews with involved roles
in this step, and data collected via observations
of Release Scope re?nement Board and Release
Planning Board meetings (see Table 4) revealed
that involved parties made a real effort to follow
the agile way of working described in the process
documentation. However, following lean principles
to 100% when planning the contents of the future
release proved to be problematic.
4.2.3.1. Finding 5: In Practice It Was Not Realistic to
Follow Lean Development Principles Fully The study
results indicated that following the practices of
evolving release scope (AP3) as described in the
of?cial documentation for Streamline (see Section
4.1.3) made it dif?cult to know which of the
requirements included in the priority directive
would be included in the ?nal release. This created
disturbances for product managers who were in
need to have a good overview of release plan and
its contents. As one product managers explained
‘‘if we follow agile then I can not tell market units and
in?uential customers what functionality will be delivered
in the next release’’.
According to the interviewed line managers and
product managers it was usual that the number of
requirements included in the priority directive was
more than the capacity of the organisation, thus
not all requirements could be implemented. Conse-
quently the product managers required con?rma-
tion from the R&D department on how many of
the requirements in the priority directive would be
possible to include in the release. This in turn meant
that all requirements in the priority directive had
to be analyzed to produce a reliable cost overview
of the requirements included in the priority direc-
tive (according to interviewed line managers the
available information on the cost from the previous
pre-project steps was too high level to be trusted).
This situation created problems since analyzing the
entire scope of the release was against the lean
philosophy of Streamline and line and project man-
agers at the R&D department were afraid to fall
back into the waterfall way of working.
In order to ?nd a middle ground between lean
principles and the needs of product management
a commitment model was suggested according to
which the R&D organisation would commit up to
50% of requirements in the priority directive from
the start. This meant that the scope of the release
would be de?ned ahead of development projects
and it would contain the ?rst half of all prioritised
requirements. The remaining requirements would
remain as candidates for in-scoping and would be
considered only after the analysis of the committed
scope was ?nished and necessary resources for
producing the requirements assigned to the scope
were secured.
4.2.3.2. Finding 6: Related topic: Different Attitudes
Towards Agile in R&D and Product Management
Interviews revealed a difference between the atti-
tudes towards agile principles in the R&Dorganisa-
tion and in the product management organisation.
Line and project managers who are representing
R&D were in general positive and enthusiastic
towards agile, while product managers in general
expressedconcernabout agile. As one product man-
ager said ‘‘I must feel con?dent about the contents of
the release in order to be able to market our product and
handle competition’’. It is interesting to note that the
R&D organisation perceived the product managers
concern about agile principles to be due to ‘‘the old
way of thinking’’. As some of the project managers
said ‘‘Product managers just have to ?nd different ways
to sell our products.’’
4.2.4. Summary
In this section the ?ndings identi?ed through inter-
views and observations will be analyzed with
regard to the extent the practiced process follows
the of?cial Streamline process described in Section
4.1. After this, the ?ndings from the interviews
and observations are organised in practiced pro-
cess symptoms, providing ground to discuss the
implication of agile properties on MDPD needs.
Comparison between of?cial and practiced pro-
cesses: Finding 1 and Finding 3 show that for
the steps of pre-screening and prioritisation the
practiced process closely followed the steps out-
lined by the of?cial process (see Section 4.1). Some
differences were identi?ed showing misalignment
when it comes to the focus of the activities (for
example in pre-screening the activities were less
focused on value analysis than expected). In addi-
tion, the produced decision support material was
not always written down as of?cial reports on
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
technical and business analysis (as mandated by
the formal process), but often consisted of informal
decisions based on expert opinion.
According to Finding 5 the largest difference
between practiced and of?cial process was identi-
?ed in the step of release planning and re?nement,
where the practice of evolving release scope as
prescribed by Streamline was in reality dif?cult to
follow. It is important to notice that the step of
release scope analysis and re?nement represents
the actual change from the waterfall approach to
the new agile way of working with the require-
ments. According to the existing research on the
extent of methodology adoption (Fitzgerald 1998) it
is not uncommon that the prescribed development
methodology in reality is not followed rigorously.
However, in this case the interviews and obser-
vations provided clear indications that due to the
problems associated with the old way of working,
the practitioners have made every effort to follow
the prescribed process. It was due to the misalign-
ment with the needs of decision makers that the
adaptations to the prescribed way of release content
analysis and planning was necessary.
4.2.4.1. Practiced Process Symptom 1: Pre-project
Activities are Focused on Commercial Requirements
Analysis of the ?ndings for the pre-screening and
prioritisation steps shows clearly that these initial
pre-project activities are mainly driven by commer-
cial requirements (see Finding 2 and Finding 4).
Additionally according to Finding 4, commercial
features are often prioritised over other types of
requirements like architectural improvements.
4.2.4.2. Practiced Process Symptom 2: Evolving Release
Scope Was Found Wanting in Relation to the Needs of
Decision Makers Finding 5 indicates that applying
the concept of evolving release scope (AP3) was
dif?cult for release planning purposes in a market-
driven context. Thus there was a need to ?nd a
solution where agile properties would be adjusted
to the needs of pre-project decisions. The introduced
approach of a commitment model is an example of
?nding a middle ground between agile principles
and the company’s needs. Further, Finding 6
indicates a lack of understanding of the challenges
and business constraints of pre-project decisions in
a market-driven context.
4.2.4.3. Practiced Process Symptom 3: Requirements
Value is De?ned through Expert Judgement Findings
1 and 3 reveal that practitioners do not have a
clear mechanism for describing, evaluating and
comparing value of different requirement types.
According to Finding 3 evaluation of requirements
value is mainly a tacit process based on expect
opinion, knowledge of product’s business case
and customer needs. Moreover, data presented in
Finding 4 indicate a need to de?ne clear procedures
and guidelines that can be used for representing
different requirement types, for example system
requirements.
5. DISCUSSION
In Table 6 the symptoms of the practiced process
identi?ed through the case study are connected to
the MDPD needs and agile properties that were
presented in Section 2.3.
As shown in the table, Symptom 1 and Symptom
3 of the practiced process is associated with the
agile properties AP1 and AP2 and is considered
to impact the need to ?nd an appropriate balance
between different requirement types, such as com-
mercial requirements, requirements connected to
technologyinnovationandarchitectural andsystem
improvements (N1 and N2). Symptom2 is connected
to AP3 and is considered to impact the needto effec-
tivelyplanthe content of the future release (N3). The
following sections elaborate on the implications of
applying agile properties on pre-project activities in
the MDPD context, and discuss possible solutions
to decrease the gap between agile properties and
needs in MDPD.
5.1. Feature Orientation vs. Balancing Different
Requirement Types
In the MDPD context balancing commercial, archi-
tectural and quality requirements are extremely
important (Ebert 2005, Regnell et al. 2005). The sys-
tem architecture is seen as one of the assets on
which future releases will be built andmaintainabil-
ity issues are connected to the cost of supporting
different versions of the products in the market
over time (Tomaszewski et al. 2008). The problems
of ?nding a balance between features and architec-
ture improvements have been acknowledged and
reported by other researchers (Wohlin and Aurum
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Table 6. Alignment of study results with agile and MDPD properties
Agile property MDPD need Observed symptom Possible impact
AP1. Feature orientation N1. Balancing different
requirements types
Symptom 1: Pre-project
activities are focused
on commercial
requirements
- Short-term thinking
AP2. Reactive development N2. Trade-off between
market-pull and
technology-push
Symptom 3:
Requirements value is
de?ned through expert
judgement
- Possible architecture
deterioration
- Product integration
problems
- Limited ability for
pre-emptive release of
features and thus
in?uencing markets
AP3. Evolving release scope N3. Release content
planning
Symptom 2: Evolving
release scope was
found un?tting for the
needs of decision
makers
- Limited possibility to
in?uence and plan
release content and
related development
cost
- Limited
understanding of total
release value
- Change management
becomes dif?cult (no
baseline to compare)
2005) and are common to Market Driven Require-
ments Engineering (MDRE).
The results of the conducted case study have
shown the dominance of commercial requirements
in Streamline, threatening to create an imbalance
between features and other types of requirements
not driven by the perceived immediate needs to the
customer or market.
In the case studied in this article we can not
claim that a perfect balance existed prior to the
introduction of Streamline. However there is a risk
that due to the agile properties of feature orientation
and reactive development (AP1 and AP2), ?nding
the balance might be even more dif?cult. This
assumption partly is motivated by a lack of support
for handling non-functional requirements in agile
methods (Paetsch et al. 2003, Sillitti et al. 2005), as
well as existing research where feature orientation
and reactive development in agile methods is
named as a threat for long-term goals such as
maintaining a clean system architecture and other
quality aspects (Boehm 2002, Tomaszewski et al.
2008).
The risk of increased dominance of commercial
requirements when applying agile methods can be
explained by examining the de?nition of require-
ments value and requirements priority in agile
methods.
As discussed in Section 2.3, agile methods focus
on delivering rapid value for a customer, where
requirements value and consequently its priority
is strongly associated to the customer value of a
requirement (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007). This de?nition of a require-
ment’s value in agile methods in combination with
unclear procedures for de?ning requirements value
(Practiced Symptom 3) can easily encourage pri-
oritisation of commercial requirements which have
a direct link to existing customers and overlook
the value of requirements which cannot be easily
linked to the customer, for example system and
architecture related requirements.
The latest studies of requirements prioritisation
practices applied in industry have revealed that
having unclear procedures when it comes to def-
inition of requirements value is not uncommon
(Barney et al. 2006, Lehtola and Kauppinen 2006).
Thus for companies aiming to combine market-
driven development with agile practices and still
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
maintaina reasonable balance betweenthe commer-
cial and other types of requirements it is extremely
important to (i) establish a clear picture of what
is/should be perceived as valuable for a company,
as opposed to value based only on the current needs
of customers and howcommercial and other type of
requirements ?t in this picture; and (ii) de?ne clear
procedures and guidelines for expressing the value
of non-commercial requirements.
5.2. Evolving Release Scope vs. Release Content
Planning
Previously in this article it was arguedthat applying
the concept of evolving release scope as de?ned in
AP3 fundamentally limits product managers’ abil-
ity to preemptively plan and control the contents
and value of a release. The potential limitations
of applying the evolving release scope concept in
MDPDcontext can be explainedby the assumptions
of agile methods regarding development and busi-
ness context in which a company operates (Section
2.3), as well as the simplistic view of agile meth-
ods when it comes to deciding the priority order of
requirements and managing the release scope.
In agile methods all development is orchestrated
by the priority order of requirements, making
the priority list central and very important. The
question is then how this priority is decided.
Agile methods provide quite a simple solution
to this where the task is left to the customer
who decides priority based on the business value
of a requirement. In order to help the customer
prioritise, the developers provide some rough cost
estimates, but mainly the order is decided by the
business value (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007).
In MDPD the priority and implementation order
of a requirement is a function of the expected value
and cost of a requirement, technical dependencies
of a requirement and value dependencies between
the requirements (Carlshamre 2002, Greer andRuhe
2004, SaliuandRuhe 2005, Ngo-The andRuhe 2008).
The mentioned difference in de?nition of priority
implies that for the same set of initial requirements
agile and MDPD will produce different priority
orderings of these. More importantly, the de?nition
of requirements priority in agile, in combination
withthe concept of the evolvingrelease scope affects
the possibilities to plan and follow up the contents
and expected ROI of a release. This point is further
on exempli?ed in Figure 3.
Figure 3 shows typical process steps of release
content planning and evolution in an agile (to
the left) and market-driven (to the right) context
respectively and inputs and outputs for each step.
Looking at the ?gure it is easy to notice that both
scenarios follow the same process steps. In both
of the scenarios there are collections of prioritised
requirements that represent the initial release scope
and both of the scenarios are iterative, where the
development activities follow the priority order of
requirements placed in the release scope. After each
iteration there is a process step allowing analysis of
delivered results and progress, as well as handling
of changes, for example dealing with newly elicited
requirements (Req. x in the ?gure). This analysis may
result in re-prioritisation and an updated release
scope.
A closer look at Figure 3 however uncovers
critical differences between the two scenarios, most
of which is caused by the difference in how the
priority and implementation order of a requirement
is de?ned in agile vs. MDPD.
The differences between the scenarios are sum-
marised below: (i) priority order of requirements in
the initial scope is different between the scenarios,
resulting in differences in development activities.
For example in the agile scenario the ?rst iteration
focuses on Req. a, and in the MDPDscenario on Req.
c; (ii) requirements analysis and re-prioritisation
step results in different content and requirements
priority order in the updated scope of each scenario;
where for example the newly arrived requirement
Req. x in the agile scenario receives high priority
and in the market-driven scenario does not. (iii)
And ?nally in MDPDscenario pre-project decisions
are tightly connected with de?ning and following
up the total value and expected ROI of the ?nal
release (in the ?gure this is indicated by assigning arbi-
trary values for total release ROI and total release value)
whereas in agile scenario this kind of analysis is
dif?cult (denoted by having question marks for the same
variables).
The de?nition of the priority order of the require-
ments in MDPD demands a proper understanding
of all requirements which are assigned to the scope.
This way it provides a base for estimating the target
ROI and total value provided by the requirements
selection (Saliu and Ruhe 2005, Ngo-The and Ruhe
2008). This base is thenusedinorder toplan, control,
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Figure 3. Differences in approach towards release planning between Agile and MDPD
and follow up how well the selected list of require-
ment satis?es target business goals of a release. In
addition it is important to gauge the consequences
of how removing or adding a new requirement to
a release scope affects the total value and expected
ROI of a release, making it possible to deal with a
change in an appropriate way.
The simple de?nition of the priority order of
the requirements in agile methods combined with
the property of an evolving release scope (AP3)
does not allow an in-depth analysis of all candidate
requirements (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007). This makes it dif?cult
to de?ne the target ROI and total value to be
deliveredby the release andcreates a risk of abusing
the practice of ‘delaying the decisions’ where the
decision on what will be included in the release is
taken after the fact, and thus the target ROI and the
total value provided by the release is not clear until
after the delivery.
Results of the conducted case study have pro-
vided two important insights regarding this issue.
Firstly the results uncovered dif?culties to follow
the practice of evolving release scope, mainly due
to posed limitations to product management oper-
ations (see Finding 5). This result relates well to the
MDPD characteristics presented in Section 2.2, and
provides support for above-outlined discussion on
misalignment between product management needs
and limited possibility of managing and controlling
release scope in agile methods.
Secondly the results have indicated different
attributes towards agile methods in the organisa-
tion, showing that while R&D part of the organisa-
tion was in general positive to application of agile
practices in development project, there was lim-
ited understanding of how agile properties affected
product management (see Finding 6).
The above mentioned ?ndings are important
since they show that while agile is appreciated
in separate development projects (Karlstrom and
Runeson 2005, Svensson and H¨ ost 2005, Petersen
and Wohlin 2008) they are not directly suited
or designed for long-term product planning and
product management, thus there is a need to ?nd
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
a way to apply agile methods in development
projects without disrupting product management
operations which are in need of more long-term
planning and control.
The need for ?nding a compromise between
agile and plan-driven approaches and tailoring
agile methods to meet speci?cs of different prod-
uct development and business contexts has been
suggested by other researchers as well (Boehm
2002, Abrahamsson et al. 2003, Cohen et al. 2004,
Fitzgerald et al. 2006), however currently a concrete
suggestion on how to accomplish this in MDPD
context has not been suggested. The commitment
model described in Finding 5 represents one exam-
ple of such a compromise. However, it is important
to notice that in order to determine the ?st selection
of functionality committed to by R&D, somewhat
reliable information on the relative value and the
cost of all requirements assignedto the release scope
should be available. This implies that some pre-
study work is still necessary. The question is what
is good-enough, and howto support informed deci-
sion making without investing too much effort or
over analysing the requirements (Fricker et al. 2007).
5.3. Validity
Issues connected to construct validity; internal
validity and external validity describe commonly
known validity threats associated with empirical
studies (Yin 1994, Wohlin et al. 2000).
Construct validity is concerned with establishing
the correct operational measures in order to assure
that the proper information will be collected. This
includes decisions on how the information sources
are selected. The usual way to handle this threat is to
use multiple sources of information. The case study
at Ericsson was designed to use multiple sources
of information and multiple ways of collection
from documentation analysis and interviews to
observation sessions during meetings. All these
sources allowed for data triangulation. As shown
in Section 3.1, studied documents, interviews, and
meetings were carefully selectedto achieve a correct
representation.
Whenconductinginvestigations that are basedon
interviews, the amount and form of the interviews
are important. In this case study budget and time
considerations as well as availability constraints
allowed for a total of 14 interviews. The interviews
were semi-structured. Notes and conclusions made
during the interview sessions were also con?rmed
by sending them to the interview subjects, where
additional questions for clari?cation were attached
where relevant. In some cases an extra interview
was arranged, however these extra interviews are
not included in the total count of the interviews in
the study.
Internal validity threats are usually important
when examining the causal relationships. The
case study presented in this article is mainly
focused of studying the characteristics of pre-
project activities. It has an exploratory character
thus the internal validity threats can be considered
as minimal. In the discussion section study ?ndings
are used to explore how well the study ?ndings
support the anticipated misalignment between
agile properties and MDPD needs as described
in Section 2.3. For example the dominance of
commercial requirements in pre-project activities
(Symptom 1) is connected to the agile properties
feature orientation (AP1) and reactive development
(AP2) and dif?culties with applying the concept of
evolving release scope (Symptom 2) is associated to
the agile property of evolving release scope (AP3).
External validity is concerned with generalisabil-
ity issues and is a threat that is common to case
study research. Even though the case study in this
report is conducted in a concrete industrial setting,
we hope that the study results should be generalis-
able beyond the studied case since the investigated
pre-project activities are not speci?c only for Erics-
son but are common for most companies operating
in a market-driven context.
6. CONCLUSIONS
In this article we have investigated the applicability
of agile methods for MDPD, focusing particularly
on pre-project activities such as requirements pre-
screening, prioritisation and release planning. The
presented work is considered to add value since
it is one of the ?rst contributions that investigates
the applicability of agile practices in this context,
providing extensive analysis and comparison of
agile practices andneeds inMDPD, as well as results
froma large empirical study at Ericsson. This area is
especiallyrelevant consideringthe current hype and
popularity of agile methods, and the contents and
conclusions of this article should be interesting for
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
anysoftware companyoperatingina market-driven
context planning to adopt agile practices.
The initial analysis and comparison of agile prop-
erties and MDPD needs (see Section 2.3) indicated
a misalignment between the two. This was further
con?rmed by the results of the case study, where
the impact of agile properties was studied for three
different products developed at Ericsson. The out-
come of the case study has providedcon?rmation of
the misalignment between agile property ‘evolving
release scope’ and the needs for release planning
in the market-driven context. Further, case study
?ndings also provided indications that ‘feature ori-
entation’ and ‘reactive development’ might be a
threat when it comes to balancing commercial and
other types of requirements, and achieving a trade-
off between market-pull and technology-push as
these aspects are not central in agile development.
Looking at the origin of agile/lean develop-
ment the misalignment can be partially explained.
Agile methodology having bespoke software devel-
opment origin was developed with customer–
developer relationships in mind and has a project
focus. Thus agile methods such as Scrum and XP
are lacking support for anoverall long-termproduct
development focus, normally associated with soft-
ware product management activities in companies
like Ericsson.
The main conclusion drawn is that agile methods
do not directly support the needs of pre-project
activities in MDPD. Application of agile properties
in an organisation operating in market-driven
context places limitations on product management
activities, and may have a detrimental effect on
long-term product development.
Research results presented in this article indicate
that agile principles in their current formshould not
be forced on product management tasks since they
are not ?t for it. In MDPD product managers need
to maintain long-term focus, differentiate between
customer and enterprise value and plan and control
the scope of a release. However, this does not mean
that product management can not bene?t from
agile/lean principles at all. The ideas from Lean
SD can be reused to ?nd ways for producing good-
enough decision material for product management,
enabling informed decisions far beyond the scope
of any individual project. For example companies
should bene?t from practices which will allow
minimising time and effort spent on analysing
pre-project decisions. These practices should also
guarantee that minimising effort does not come
at cost of jeopardising product managers’ ability
to take informed decisions or increased costs in
later stages of product development. The point here
is that while it is important to produce fast, it
is also important to maintain the big picture and
understand how the achievements of individual
development projects bene?t both short- and long-
term business goals of the company developing the
product.
6.1. Future Work
Through the investigation and uncovering of the
impact of agile practices on software product
management activities the authors of this article
hope to create a foundation for ?nding ways
to incorporate agile projects in MDPD without
compromising long-term product goals.
The initial steps towards solving this issue will
be connected to resolving the uncovered misalign-
ment points between agile principles and product
management needs. The future research will evolve
in two directions: (i) the ?rst direction will focus on
helping software companies maintain an appropri-
ate balance between different types of requirements
even when following agile development princi-
ples. In order to achieve this we plan to work
on separation of customer value from enterprise
value and ?nding approaches for de?ning and
comparing value of commercial and architectural
requirements. (ii) The second direction intends to
?nd ways of applying lean development ideas in
software product and release planning situations.
The key here is in ?nding just-enough level of anal-
ysis of the entire release scope without requiring
excessive details but also allowing for the presence
of decision support material (e.g. in the form of
good-enoughrequirements). Inthis way the authors
hope to facilitate de?ning practices for Lean SD.
ACKNOWLEDGEMENTS
We would like to express our gratitude to Ericsson,
an industrial partner of the BESQ(Blekinge Institute
of Technology, Sweden;http://www.bth.se/besq)
research centre, for making this study possible.
In the search for a middle ground between agile
and plan-driven models Ericsson has taken an
important step to integrate agile methods into their
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
product development. Through the experience of
using these methods, Ericsson started adding to
state-of-the-art by investing effort in ?nding new
and improved ways of applying agile principles
to large-scale product development. These efforts
are a part of joint ongoing research projects. Last
but not least we would like to thank all the skilled
and dedicated professionals at Ericsson for seeing
opportunities and not problems.
REFERENCES
Abrahamsson P, Warsta J, Siponen M, Ronkainen J. 2003.
Newdirections on agile methods: a comparative analysis.
25th International Conference on Software Engineering
(ICSE’03). IEEE Press.
Barney S, Aurum A, Wohlin C. 2006. Quest for a
Silver Bullet: Creating Software Product Value through
Requirements Selection. 32nd EUROMICRO Conference
on Software Engineering and Advanced Applications
(EUROMICRO’06), IEEE Computer Society. Cavtat,
Croatia.
Beck K. 1999. Extreme Programming Explained: Embrace
Change. Addison-Wesley: Massachusetts, Boston MA.
Beck K, Fowler M. 2001. Planning Extreme Programming,
The XP series. Addison-Wesley: Boston, MA.
Boehm B. 2002. Get ready for agile methods, with care.
Computer 35(1): 64–69.
Carlshamre P. 2002. Release planning in market-
driven software product development: provoking an
understanding. Requirements Engineering 7(3): 139–151.
Carlshamre P, Sandahl K, Lindvall M, Regnell B, Nattoch
Dag J. 2001. An industrial survey of requirements
interdependencies in software product release planning.
Proceedings of the Fifth IEEE International Symposium
on Requirements Engineering, Los Alamitos, CA, IEEE.
Clements P, Northrop L. 2002. Software product lines:
practices and patterns. The SEI Series in Software
Engineering. Addison-Wesley: Boston, MA; 608.
Cohen D, Lindvall M, Costa P. 2004. An introduction to
agile methods. Advances in Computers 62: 1–66.
Dagnino A, Smiley K, Srikanth H, Anton AI, Williams L.
2004. Experiences inapplyingagile software development
practices in new product development. 8th IASTED
International Conference on Software Engineering and
Applications: Cambridge, MA.
Dahlstedt A, Karlsson L, Persson A, NattochDag J,
Regnell B. 2003. Market-driven requirements engineering
processes for software products – a report on current
practices. International Workshop on COTS and Product
Software RECOTS, held in conjunction with the 11th IEEE
International Requirements Engineering Conference, Los
Alamitos, CA, IEEE.
Dyb? a T, Dingsøyr T. 2008. Empirical studies of agile
software development: a systematic review. Information
and Software Technology 50(9–10): 833–859.
Ebert C. 2005. Requirements BEFORE the requirements:
understanding the upstream impacts. 13th IEEE
International Conference on Requirements Engineering
(RE’05), IEEE Paris, France.
Erickson J, Lyytinen K, Siau K. 2005. Agile modeling,
agile software development, and extreme programming:
the state of research. Journal of Database Management 16(4):
88–100.
Fitzgerald B. 1998. An empirical investigation into the
adoption of systems development methodologies. Journal
of Information & Management 34: 317–328.
Fitzgerald B, Hartnett G, Conboy K. 2006. Customizing
agile methods to software practices at Intel Shannon.
European Journal of Information Systems 15: 200–213.
Fricker S, Gorschek T, Myllyperki ¨ o P. 2007. Handshaking
between software projects and stakeholders using
implementation proposals. Requirements Engineering:
Foundation for Software Quality, (REFSQ’07). Springer
Berlin/Heidelberg: Trondheim.
Gorschek T. 2006. Requirements engineering support-
ing technical product management. School of Engineer-
ing – Department of Systems and Software Engineering.
Blekinge Institute of Technology: Ronneby. 342.
Gorschek T, Davis A. 2008. Requirements engineering: in
searchof the dependent variables. Informationand Software
Technology 50: 67–75.
Gorschek T, Wohlin C. 2004. Packaging software process
improvement issues – a method and a case study.
Software: Practice and Experience 34(14): 1311–1344.
Gorschek T, Wohlin C. 2006. Requirements abstraction
model. Requirements Engineering 11(1): 79–101.
Greer D, Ruhe G. 2004. Software release planning: an
evolutionary and iterative approach. Information and
Software Technology 46(4): 243–253.
Hanssen GK, Fægri TE. 2008. Process fusion: anindustrial
case study on agile software product line engineering.
Journal of Systems and Software 81(6): 843–854.
Highsmith J, Cockburn A. 2001. Agile software
development: the business of innovation. IEEE Computer
34(9): 120–122.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Ilieva S, Ivanov P, Stefanova E. 2004. Analyses of an agile
methodology implementation. 30th Euromicro Conference.
IEEE Computer Society Press.
Karlsson L, Dahlstedt
?
A, Nattoch Dag J, Regnell B,
Persson A. 2003. Challenges in market-driven
requirements engineering – an industrial interview
study. Proceedings of the Eighth International Workshop
on Requirements Engineering: Foundation for Software
Quality (REFSQ’02). Essen, Germany, Universit¨ at
Duisburg-Essen.
Karlstrom D, Runeson P. 2005. Combining agile methods
with stage-gate project management. IEEE Software 22(3):
43–49.
Koch AS. 2005. Agile Software Development Evaluating the
Methods for Your Organization. Artech House Publishers:
London.
Layman L, Williams L, Cunningham L. 2004. Exploring
extreme programming in context: an industrial case
study. Agile Development Conference, Salt lake city, UT;
published by IEEE Computer Society Press.
Lef?ngwell D. 2007. Scaling Software Agility. Addison-
Wesley: Boston, MA.
Lehtola L, Kauppinen M. 2006. Suitability of require-
ments prioritization methods for market-driven software
product development. Software Process: Improvement and
Practice 11(1): 7–19.
Cunningham W, Manifesto for Agile Software
Development. 2001. [cited 2008-09-30]; Available from:http://www.agilemanifesto.org.
Mann C, Maurer F. 2005. A case study on the impact
of scrum on overtime and customer satisfaction. Agile
Development Conference (ADC’05). IEEEComputer Society:
Denver, CO; published by IEEE Computer Society Press.
Mannaro K, Melis M, Marchesi M. 2004. Empirical
analysis on the satisfaction of IT employees comparing
XP practices with other software development
methodologies. Extreme Programming and Agile Processes in
Software Engineering. Lecture Notes in Computer Science,
Springer, Berlin.
Middleton P. 2001. Lean software development: two case
studies. Software Quality Journal 9(4): 241–252.
Ngo-The A, Ruhe G. 2008. A systematic approach for
solving the wicked problemof software release planning.
Soft Computing – AFusion of Foundations, Methodologies and
Applications 12(1): 95–108.
Noor MA, Rabiser R, Gr ¨ unbacher P. 2008. Agile product
line planning: a collaborative approach and a case study.
Journal of Systems and Software 81(6): 868–882.
North American and European Enterprise Software
and Services Survey. 2005. Business Technographics.
Survey conducted by Forrester Research inc. Available
athttp://www.Forrester.com/ER/Research/Survey/
Excerpt/0, 5449, 436,00.html.
Paetsch F, Eberlein A, Maurer F. 2003. Requirements
engineering and agile software development. 12th IEEE
international Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises, IEEE, Linz,
Austria.
Petersen K, Wohlin C. 2008. Issues and advantages
of using agile and incremental practices. The Eighth
Conference on Software Engineering Research and
Practice in Sweden (SERPS’08), Karlskrona, Sweden.
Pettersson F, Ivarsson M, Gorschek T, Ohman P. 2008.
A practitioner’s guide to light weight software process
assessment and improvement planning. Journal of Systems
and Software 81(6): 972–995.
Poppendieck M, Poppendieck T. 2003. Lean Software
Development – An Agile Toolkit. Addison-Wesley: Boston,
MA.
Potts C. Invented requirements and imagined customers:
requirements engineering for off-the-shelf software. 1995.
Proceedings of the SecondIEEEInternational Symposium
on Requirements Engineering, Los Alamitos, IEEE.
Regnell B, Brinkkemper S. 2005. Market-Driven Require-
ments Engineering for Software Products. In Engineering
and Managing Software Requirements, Wohlin C, Aurum A
(eds). Springer: Heidelberg, Berlin 287–308.
Robson C. 2002. Real World Research: A Resource for Social
Scientists and Practitioner-Researchers, 2nd edn. Blackwell
Publishers: Oxford.
Saliu O, Ruhe G. 2005. Supporting software release
planning decisions for evolving systems. 29th Annual
IEEE/NASA Software Engineering Workshop (SEW’05),
IEEE, Greenbelt, MD.
Schwaber K, Beedle M. 2001. Agile Software Development
with Scrum. Prentice Hall: Upper Saddle River, NJ.
Sillitti A, Succi G. 2005. Requirements engineering for
agile methods. In Engineering and Managing Software
Requirements, Wohlin C, Aurum A (eds). Springer: New
York, NY; 309–326.
Svensson H, H¨ ost M. 2005. Introducing an agile process
in a software maintenance and evoluition organization.
9th European Conference on Software Maintenance and
Reengineering (CSMR 2005). Manchester, UK.
Telelogic Focal Point – Software for Product Management
and Product Portfolio Management. 2009. [cited
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
2009-01-22]; Available from:http://www.telelogic.com
/corp/products/focalpoint/index.cfmIBMCorporation.
Tian K, Cooper K. 2006. Agile and software product
line methods: are they so different?. 1st International
Workshop on Agile Product Line Engineering: collocated
with the 10th International Software Product Line
Conference (SPLC), Baltimore, MD.
Tomaszewski P, Berander P, Damm L-O. 2008. From
traditional to streamline development – opportunities
and challenges. Software Process: Improvement and Practice
13(2): 195–212.
van de Weerd I, Brinkkemper S, Nieuwenhuis R,
Versendaal J, Bijlsma L. 2006. Towards a reference
framework for software product management.
Proceedings of the 14th IEEE International Requirements
Engineering Conference (RE’06), IEEE Computer Society,
Minneapolis, MN.
Williams L, Cockburn A. 2003. Agile software
development: it’s about feedback and change. Computer
36(6): 39–43.
Wohlin C, Aurum A. 2005. What is important when
deciding to include a software requirement in a project or
release?. International Symposiumon Empirical Software
Engineering, IEEE, Noosa Heads, Australia.
Wohlin C, Runeson P, H¨ ost M, Ohlson MC, Regnell B,
Wessl´ en A. 2000. Experimentation in Software Engineering:
An Introduction, The Kluwer International Series in Software
Engineering. Kluwer Academic: Boston, MA; 204.
Womack JP, Jones DT, Roos D. 1991. The Machine That
Changed the World : The Story of Lean Production. Harper
Perennial: New york.
Yin R. 1994. Case Study Research. SAGE Publications:
Thousand Oaks, CA.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
doc_317065581.pdf
Agile development methods such as extreme programming (XP), SCRUM, Lean Software Development (Lean SD) and others have gained much popularity during the last years.
SOFTWARE PROCESS IMPROVEMENT AND PRACTICE
Softw. Process Improve. Pract. (2009)
Published online in Wiley InterScience
(www.interscience.wiley.com) DOI: 10.1002/spip.420
The Impact of Agile
Principles on
Market-Driven Software
Product Development
Research Section
Nina Dzamashvili Fogelstr¨ om,
1
* Tony Gorschek,
1
Mikael Svahnberg,
1
and Peo Olsson
2
1
Department of Systems and Software Engineering, Blekinge Institute of
Technology, PO Box 520, S-372 25 Ronneby, Sweden
2
Ericsson AB, Business Unit Multimedia
¨
Olandsgatan 1, Box 518 S-371 23
Karlskrona, Sweden
Agile development methods such as extreme programming (XP), SCRUM, Lean Software
Development (Lean SD) and others have gained much popularity during the last years. Agile
methodologies promise faster time-to-market, satis?ed customers and high quality software.
While these prospects are appealing, the suitability of agile practices to different domains and
business contexts still remains unclear. In this article we investigate the applicability of agile
principles in the context of market-driven software product development (MDPD), focusing on
pre-project activities. This article presents results of a comparison between typical properties
of agile methods to the needs of MDPD, as well as ?ndings of a case study conducted at
Ericsson, an early adopter of agile product development. The results show misalignment
between the agile principles and needs of pre-project activities in market-driven development.
This misalignment threatens to subtract from the positive aspects of agile development, but
maybe more importantly, threaten the overall product development by disabling effective
product management. Copyright © 2009 John Wiley & Sons, Ltd.
KEY WORDS: market-driven software development; software product management; agile methods; case study
1. INTRODUCTION
Agile methods are attractive to software companies
since they promise shorter time-to-market, as well
as higher ?exibility to accommodate changes in the
requirements and thereby increased ability to react
?
Correspondence to: Nina Dzamashvili Fogelstr¨ om, Depart-
ment of Systems and Software Engineering, Blekinge Institute of
Technology, PO Box 520, S-372 25 Ronneby, Sweden
†
E-mail: [email protected]
Copyright © 2009 John Wiley & Sons, Ltd.
to changing customer (market) needs (Williams and
Cockburn 2003, 2005).
The major feature of agile methods is to use
iterations of small development projects developing
limited sets of the most important functionality at a
given point in time. The common property of agile
methods is reactive rather than proactive tactics,
encouraging quick adaptation to change rather
than planning for it. The goal of agile methods
is to eliminate long pre-study and analysis of
requirements and start feature production as soon
as possible. The positive aspect of this approach is
that it speeds up the production of functionality that
Research Section
N. Dzamashvili Fogelstr¨ om et al.
is considered important at present; the downside is
that it limits the possibility to control and plan the
content of a release (Boehm 2002, Williams and
Cockburn 2003).
The ?exibility and ability to quickly respond to
market ?uctuations makes agile/lean development
methods attractive for companies operating in a
market-drivencontext, despite the fact that the long-
term impact of adopting these principles and their
applicability in the market-driven context are to a
large extent unknown. Existing studies and experi-
ence reports from application of agile methods are
mostly isolated to evaluating the performance of
these methods on software development activities,
such as increasingdevelopers’ ef?ciency, producing
better quality code and so on (Dyb? a and Dingsøyr
2008). Isolated experience articles on increased cus-
tomer satisfaction exist, but then the studied project
was developed according to bespoke practices, i.e.
in a customer–developer relationship with a con-
tractually bound effort and not in a market-driven
context (Mannaro et al. 2004, Mann and Maurer
2005).
To the best of our knowledge, currently there
are no studies analyzing the impacts of agile/lean
development principles on either pre-project activ-
ities, such as product planning/management in
MDPD, or the long-term impact of optimising the
project perspective rather than that of products or
product portfolios.
The most important aspects of MDPDare require-
ments triage (initial selection), requirements pri-
oritisation and planning (release planning), i.e.
deciding which of the thousands of potential
requirements should be implemented, and when
(Carlshamre 2002, Karlsson et al. 2003, Regnell et al.
2005). The main task of product management is
to weigh all types of criteria ranging from market
demands, trends, key-customer demands, to tech-
nical and long-term product impact, and arrive at
decisions supported by the company and product
strategy. Selecting the best sub-set of requirements
for implementation has to take both the long-term
and short-term perspectives into account as well as
market-pull and technology-push.
In light of the effect of pre-project activities on the
success of any company practicing market-driven
development, it becomes important to know what
kind of impact agile principles have on product
management and critical pre-project activities such
as initial requirements triage, prioritisation, and
release planning. This is important in order to
determine to what extent agile principles can be
adopted in market-driven organisations, and what
product management and pre-project practices
should be in place to maximise the positive aspects
of lean development in projects (Carlshamre 2002,
Karlsson et al. 2003, Regnell et al. 2005).
This article investigates the impact of agile princi-
ples on pre-project activities in MDPD by studying
an industry case. The study is performed in collab-
oration with Ericsson AB in Sweden, where a large
effort to move from‘traditional’ pre-study intensive
development to lean development (agile) has been
ongoing for over 3 years. An early evaluation of the
move to lean development and its potential was
presented by Tomaszewski et al. (2008). The case
study in this article presents a postchange evalua-
tion at the same company, but from the perspective
of pre-project activities and the potential misalign-
ment between the needs of product management
and agile principles. In addition to this, the arti-
cle also quali?es the challenges with future research
directions andsuggestions as howthe misalignment
could be handled.
The rest of this article is outlined as follows:
Section 2 provides a background to agile software
development and market-driven software product
development (MDPD) where the common aspects
of agile methods are put against the special
needs in a market-driven context. Further, a short
overview of empirical evidence on agile methods is
provided. Section 3 gives details on study design
and execution. Case study results, analysis, and
discussion can be found in Section 4 and Section 5
respectively. The report is ?nalised by conclusions
and future work in section 6.
2. BACKGROUND AND RELATED WORK
2.1. Common Aspects of Agile Software
Development Methods
The introduction of extreme programming (XP) in
the late 90s is commonly acknowledgedas a starting
point, coining the term agile in software develop-
ment. In2001 other agile initiatives suchas Dynamic
Systems Development Method (DSDM), Crystal,
Feature Driven Development, and SCRUM joined
XPandthe ‘Agile Manifesto’ was formeddescribing
the ideas and agile commonalities (Abrahamsson
et al. 2003, Cohen et al. 2004).
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Nowadays agile methods are quite popular and
are seen as an alternative to the traditional plan-
driven methods, which thus far have been the
basis for accepted practices in software engineer-
ing (Abrahamsson et al. 2003, Cohen et al. 2004,
Tomaszewski et al. 2008). Plan-driven methods are
characterised by heavy upfront planning, focus on
documentation, predictability, and repeatable pro-
cesses (Boehm 2002). Lately these methods have
been criticised for their inability to accommodate
change and the high costs that are associated
with updating documentation and plans (High-
smith and Cockburn 2001, Poppendieck and Pop-
pendieck 2003, Lef?ngwell 2007). On the other
hand, agile methods are designed to accommodate
rapid change (Beck 2000, Williams and Cockburn
2003). In order to be ?exible, agile methods rely
on individuals and their knowledge rather than
processes, value working piece of software over
complete requirements speci?cations and design
plans; and encourage responding to a change rather
than planning for it (Manifesto for Agile Software
Development 2008).
The latest contribution to the agile commu-
nity, Lean Software Development (Lean SD) (Pop-
pendieck and Poppendieck 2003), is based on a
collection of attitudes and principles originating
from the successful concepts of lean manufacturing
developed by Toyota known as the Toyota pro-
duction system (Womack et al. 1991). The original
lean manufacturing principles at Toyota (Elimi-
nate waste, Amplify learning, Decide as late as
possible, Deliver as fast as possible, Empower the
team, Build integrity, etc.) are based on continuous
improvement and elimination of waste. Since these
principles are rather general they can be interpreted
and adapted to suit different applications and busi-
ness domains, for example software development.
This can be seen as an advantage as the appli-
cability of agile methods are generally considered
to be limited to small- to medium-sized enterprise
developing medium-sized non-critical applications
(Boehm 2002, Williams and Cockburn 2003, Sillitti
et al. 2005). However, the current translation of lean
principles to software development (Poppendieck
and Poppendieck 2003) is fully compliant with, or
even designed after, existing agile principles. This
might imply a limitation of this potential, limiting
the ?exibility of the origin ideas behind the lean
development.
In general, agile methods may vary when it
comes to the speci?c application of certain practices.
However, they all follow the main principle of
producing working software in small iterations,
and utilising small teams of dedicated individuals
that focus on software development. The common
aspects of agile methods can be summarised by
the following principles [hereafter called Agile
Property (AP)] (Highsmith and Cockburn 2001,
Abrahamsson et al. 2003, Cohen et al. 2004):
• AP1. Feature orientation: The main focus is on
the production of features as soon as possible.
The goal is to deliver working functionality that
is perceived to have the most value for the
customer, and this is done in small and frequent
iterations.
• AP2. Reactive development: Reactive develop-
ment is about responding to a change instead of
planning ahead, and delaying decisions as long
as possible. Agile methods promise ?exibility
and follow the ideology that one can not con-
trol the world, thus the strategy is to respond
to a change rather than plan for it. Examples
of reactive practices are refactoring, adjusting
requirements’ priorities, and release scope after
each iteration and delaying decisions for as long
as possible.
• AP3. Evolving project (release) scope: Perhaps
one of the main distinguishing features of agile
development is the change from a ?x-scope
approach to a more open-ended approach. In
the traditional ?x-scope approach much effort is
spent on de?ning and planning the content of
a product release of a project upfront. In agile
the release scope is emerging in the process
of development rather than planned ahead. A
prioritised list of requirements (product backlog
in SCRUM and prioritised user stories in XP)
serves as an initial input which is a kind of
wish-list of a release scope. The release scope
is expected to be re?ned and updated at the
end of each iteration in order to accommodate
changes and new information that was learned
in the latest iteration. This practice is in line with
the reactive development property described
in AP2.
2.2. Speci?c Needs of MDPD
In MDPD software products are often developed
as product families that are offered to a mass
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
market rather than a speci?c customer. The product
development has an iterative character where new
versions of the product are delivered to the market
via established release cycles (Dahlstedt et al. 2003,
Gorschek and Wohlin 2006).
The fact that the product is not ordered and
developed to suit the wishes and needs of one
speci?c customer creates special needs distinguish-
ing the characteristics of this type of develop-
ment from customer-speci?c (bespoke develop-
ment)(Potts 1995). In a bespoke situation the devel-
opment organisation can rely on the customer to
decide what functionality should be included in
the product and this information can be elicited
directly from the customer. However, in market-
driven development this is not feasible as there
are any number of potential customers. Instead
the development organisation itself decides what
functionality should be delivered to what market
segment and when (Potts 1995, Karlsson et al. 2003,
Ebert 2005, Regnell et al. 2005, van de Weerd et al.
2006). This creates a special focus on pre-project
activities usually associated with product planning
and management operations (van de Weerd et al.
2006). The speci?c needs of MDPD are summarised
below:
• N1. Balancing different requirements types:
Selecting a set of requirements that will be
included in future releases of a product is one
of the most important strategic decisions in
MDPD. This decision is based on comprehen-
sive analysis of the company’s business intel-
ligence, product planning and road-mapping,
marketing and sales information, and strate-
gic assets such as engineering know-how and
investments in product architecture (Greer and
Ruhe 2004, Ebert 2005, Regnell et al. 2005,
Saliu and Ruhe 2005). The speci?cs of this
task require that the development organisation
must ?nd an optimal balance between different
requirement types such as commercial require-
ments, innovations, requirements connected to
architecture improvements and also balance
quality attributes like maintainability, perfor-
mance, scalability, and usability across different
releases.
• N2. Trade-off between market-pull and tech-
nology-push: Studies in relation to MDPD have
shown that the development organisation not
only needs to respond to the current consumer
needs but also anticipate future needs as well as
in?uence the needs of the consumers via inno-
vations and technology breakthrough. Finding
a balance between market-pull and technology-
pushis consideredone of the challengingaspects
for companies operating in this context as it
indirectly involves balancing low- and high-risk
as well as long- and short-term considerations
(Karlsson et al. 2003, Regnell et al. 2005).
• N3. Release content planning (requirements
selection): Planning the content of a speci?c
release is recognised as one of the most chal-
lenging parts of MDPD (Carlshamre et al. 2001,
Carlshamre 2002, Greer and Ruhe 2004). This
activity occurs after a large number of initial
requirements have been ?ltered through the
steps of requirements triage/screening and pri-
oritisation. The reducedamount of requirements
is then considered for inclusion for a speci?c
release, which is the task of release scope plan-
ning. The ultimate goal of this activity is to ?nd
a selection of requirements that will give the
best possible return on investment (ROI) and
will be feasible to implement within a given
time- and resource-frame. The main character-
istics of this task require ?nding an appropriate
balance between relative cost and value of each
requirement, technical and business dependen-
cies betweenrequirements, andavailable budget
and resources at hand. The outcome of this
activity results in a list of requirements that con-
stitutes the plannedscope of a release. Havingan
establishedrelease scope is important fromthree
main aspects. One, it enables decision makers to
estimate and plan for the total value of a release,
and a comparison to the total value needed for
a speci?c market segment at a certain time. The
goals of a release may be combinatory in nature,
i.e. several projects in collaboration over time
can together offer a speci?c value for the mar-
ket. Two, a set release scope provides a baseline
that can be used to effectively evaluate emerging
changes with respect to how this change affects
the total value and cost of a release. This pro-
vides a basis for informed decisions and helps
managers to not only react but also ?nd the best
waytoreact ona givenchange. Three, it provides
a possibility to plan and implement long-term
product development and innovation that are
not based on current customer wishes but focus
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
on, for example, system evolution goals that go
beyond the project perspective.
2.3. Applying Agile Principles in MDPD
In order to understand the possible impact of agile
methods on pre-project activities, the properties
of agile methods described in Section 2.1 are put
against the needs of MDPDdescribed in Section 2.2.
The result is presented in Table1.
In Table 1, AP1 is put against N1 since fea-
ture orientation by de?nition favors feature-type
requirements thereby being the opposite of creating
a balance between different requirement types such
as feature and non-functional requirements. AP2:
Reactive development is associated with N2, i.e.
the need of ?nding trade-off between market-pull
and technology-push since there is a risk that the
agile view of adopting and reacting to customer
needs results in the company becoming too focused
on responding to current market needs and thus
being unable to push innovative ideas that do not
directly originate fromthe market or key-customers
at present. This can have devastating effects on the
long-term, invisible to the project perspective which
is inherentlyfocusedondeliveringthe requirements
relevant from the project perspective.
Using an evolving release scope (AP3) is by
de?nition at odds with planning the release scope
(N3) as it limits the decision maker’s ability to
actively control and in?uence release content. As
presented in Section 2.2 in MDPD there is a
need for an established release scope, where the
decision on what is included in a release is based
on careful analysis of all candidate requirements
(Carlshamre 2002, Greer and Ruhe 2004, Saliu and
Ruhe 2005, Ngo-The and Ruhe 2008). In contrast,
an agile project release scope is loosely de?ned
and is based on rough estimates and the initial
feelings of the customer about the requirements.
The intention in an agile project is not to have
Table 1. Agile properties vs. MDPD needs
Agile property Affected MDPD need
AP1. Feature
orientation
N1. Balancing different
requirements types
AP2. Reactive
development
N2. Trade-off between
market-pull and technology-push
AP3. Evolving
release scope
N3. Release content planning
the best selection but to re?ne the scope during
the course of development (Beck and Fowler 2001,
Poppendieck and Poppendieck 2003, Williams and
Cockburn 2003, Lef?ngwell 2007).
The lack of alignment between the properties
of agile methods and the needs of MDPD can be
further explored by studying certain assumptions
made in agile development methods and mapping
them to the product development practices in
market-drivencontext. These assumptions are listed
in Table 2. Each is elaborated upon below.
• Development context: Agile methods are bes-
poke in origin (Karlstrom and Runeson 2005)
and largely focus on a speci?c project rather
than long-term product development common
to MDPD where the focus is on the product
or product families offered to any number
of potential customers. Success in a bespoke
(project) perspective is the successful completion
of the project ful?lling the needs of the customer.
Table 2. Agile assumptions and MDPD reality
Agile methods MDPD
Development
context
One
customer – focus
on a speci?c
project. The
project is central.
Many potential
customers – focus
on a product or
product family.
Development is
focused on the
product, and any
number of
projects can
contribute to a
release.
Business context Customer owns
the product and
?nances the
development
effort.
Development
organisation owns
the product and
?nances the
development
activities itself.
The release
scope can be
unde?ned and
negotiated.
The release scope
needs to be
de?ned and is not
easily
renegotiable.
Understanding of
value
Simple. Complex.
Assumptions about
requirements
Requirements
are at large
unknown.
Requirements are
known through
market
investigations and
business
intelligence.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Success from a market-driven perspective is
measured in sales, revenue, market growth, and
the ability to create and maintain a ?exible
product architecture that will support future
product releases. Thus the difference between
agile and MDPD context is both in the scale
and the complexity of the projects. For example
creating a maintainable product architecture
is not as critical in a small bespoke project
compared to a project that is part of a large-
scale product development effort of a product
that will have a long life span.
• Business context: Agile methods assume that
the customer is responsible for identifying valu-
able requirements and ?nancing development
activities, as well as that the scope of the release
or a project is negotiable. In contrast in MDPD
the development organisation itself is respon-
sible and has to decide what requirements are
valuable for a current release and for ?nding
?nancial resources to develop the selected set
of functionality. The contents of the release can-
not be negotiable in the same sense as in agile
projects as there is no speci?c customer, rather
the decision of what to develop is arrived at
after complex deliberation involving product
management, marketing, key-customers, sales
and upper management, as well as long-term
plan in?uence. In fact, the scope of the release
has to be de?ned since it is quite common that
product management need to produce a mar-
keting message on what is to be expected in
the next release of the product long before the
development activities are ?nished (or even ini-
tiated). Applying the concept of evolving release
scope has some economical consequences as well
where the developing organisation (which in
MDPD stands for the development costs itself)
must evaluate how much updating, refactor-
ing and other correcting after-the-fact activities
can be afforded by a company that has to
deliver a certain value at a de?ned market
window time-point. In MDPD time-to-market
is generally seen as being of paramount impor-
tance.
• Understanding of value: Agile methods focus
oncreatingrapidvalue for a speci?c customer. In
MDPD the de?nition of what constitutes value
is more complex and the potential value for
a speci?c customer is just one component of
a value measure (this relates to N1 and N2
presented in Section 2.2). Also, agile methods
assume that the value of rapidly developedfunc-
tionality can be con?rmed by a customer or an
on-site customer representative almost immedi-
ately. InMDPDthe validationof perceivedvalue
of developed functionality requires longer lead-
times as well as different tools, for example GAP
analysis, customer value analysis (CVA) and
focus groups (Gorschek 2006). An agile project
member cannot go to an on-site customer as
this representative does not exist. The concept
of value not only transcends any one customer
but also the project itself. For example, a project
can be a part of a long-termdevelopment plan to
offer infrastructure to subsequent development
down the line. From a project perspective most
of the project contents might seem as waste, but
from a product perspective the view is another
(Gorschek and Davis 2008).
• Assumptions about requirements: Agile meth-
ods assume that at the beginning of the develop-
ment project requirements are largely unknown.
This is not the case for MDPDwhere large efforts
have been devoted to collecting large amounts
of potential requirements, whichundergo triage,
and subsequent re?nement and selection (and
packaging) prior to the project being created
(Potts 1995, Karlsson et al. 2003, Ebert 2005, Reg-
nell et al. 2005, van de Weerd et al. 2006). This
does not mean that the requirements given to a
project are perfect or even complete, but it does
mean that there has been a deliberate and critical
effort to select and deliver a set of requirements
to the project.
As a consequence to these differences in assump-
tions and properties of agile development methods
and MDPD needs, it seems reasonable to assume
that applying agile principles in this context will
have certain consequences on pre-project activities
connected to requirements selection and product
planning. This is the focus of this article and the
case study presented in sections 3 and 4.
First a background to agile development is given
with focus on reporting experiences from industry
usage.
2.4. Empirical Studies on Agile Methods
Agile software development models are relatively
new and have not been tested to the same
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
extent as traditional software development models
(Abrahamsson et al. 2003). A large part of the
existing empirical evidence regarding agile meth-
ods is focused on XP. Here research efforts are
mainly focused on studying isolated practices, such
as pair programming or test-driven development
(Erickson et al. 2005). When it comes to the impact
of agile methods onsoftware development activities
a number of case studies exist. These studies report
improvements in the quality of the developed code,
increasedeffectiveness andproductivityof software
developers, and customer satisfaction (Middleton
2001, Ilieva et al. 2004, Layman et al. 2004, Man-
naro et al. 2004, Mann and Maurer 2005). However,
a closer examination of these studies shows that
most of them focus on identifying the effect of agile
principles on in-project activities, and that observed
effects are primarilyidenti?edinthe context of small
development teams developing small- to medium-
sized applications. These results are in line with
the ?ndings of Abrahamsson et al. (2003), who in
their survey concluded that there is a lack of sound
empirical evidence to support the applicability of
agile methods in different development contexts
and application domains.
Empirical evidence in relation to the application
of agile practices in large-scale contexts is quite
scarce. In a recently conducted systematic review
of empirical studies on agile software development
270 reports were identi?ed as containing empirical
results on agile development methods (Dyb? a and
Dingsøyr 2008). After assessment of these according
to the principles of what constitutes good practices
of empirical research, only 33 of the original 270
were considered as credible empirical reports.
Out of these only a small fraction, two reports
(Dagnino et al. 2004, Karlstrom and Runeson 2005),
report on application of agile principles in large
organisations. Both of these studies focus on in-
project activities and report positive results of
applying agile principles. It is important to notice
though that in the works of Karlstromand Runeson
(2005) the application of XP practices was done
in the context of small pilot teams. Information
about the context of development size of developing
project and which XP practices had been applied
was unfortunately missing. In the works of Dagnino
et al. (2004) a rather conservative version of agile
development methodology was used to produce a
prototype for an internal customer.
2.4.1. Empirical Studies on the Impact of Agile
Methods on MDPD
When reviewing existing knowledge and research
on agile methods it is easy to notice that most of
the empirical reports focus on analyzing the impact
of agile methods on in-project activities such as
software design, development and test activities,
when studies focusing on pre-project activities and
product management in general are quite rare (see
Section 2.4).
Recently there has been interest in investigating
the application of agile methods for product line
engineering (PLE) (Clements and Northrop 2002),
which have some similarities with product man-
agement activities. At the current stage however
the research in this area is quite new, focusing on
studying in what way agile principles and PLE
activities can be combined (Tian and Cooper 2006,
Hanssen and Fægri 2008), or the application of the
selected principles of agile methods (such as col-
laboration and focus on individuals) in some PLE
activities (Noor et al. 2008).
When it comes to MDPD, to the best of our
knowledge and for the time being, studies focusing
on understanding of the impact of agile principles
on pre-project, product management activities do
not exist. This situation indicates a critical gap
in understanding, e.g. the long-term effects of
agile methods on product development. This is
especiallyrelevant whenconsideringMDPD, where
pre-project activities are critical (Regnell et al. 2005).
Studies investigating the impact of agile princi-
ples on pre-project activities are needed in order
to determine to what extent agile principles can be
adopted in the MDPD context. This can involve e.g.
how agile models need to be tailored, or what other
practices need to be in place in order to take full
advantage of positive aspects of agile development
without negatively effecting MDPD.
The case study described in this article inves-
tigates the characteristics of decision making in
Ericsson AB that has worked with adopting agile
principles over the last years. The goal of the case
study is to study and understand the character-
istics of the pre-project decision-making process
when applying agile development principles. The
identi?ed characteristics and speci?cs of the pre-
project process are analyzed in order to see if the
study ?ndings can support the expected impact of
agile principles on pre-project activities in MDPD
as described in Section 2.3.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
3. CASE STUDY SETTING AND DESIGN
The case studywas conductedduringthe fall of 2007
at EricssonABinSweden(calledEricssonhereafter).
Ericsson is one of the world’s leading companies
in telecommunication, providing a wide range of
products and solutions. The company operates in
a market-driven context where the products are
sold as generic solutions offered to an open market,
although customised versions of the products are
also developed and sold to key-customers.
With the goals of achieving higher process per-
formance and increased ?exibility when it comes
to accommodating changing requirements Ericsson
movedfroma traditional development process with
relatively extensive development projects which
lasted about a year or even more (following the
classical waterfall development steps) to lean devel-
opment. One of the main motivations for moving
to a new development process was to minimise
the number of change requests. Change requests
were associated with high development costs since
they often resulted in wasting development effort in
form of detailed analysis of requirements that were
not implemented in the ?nal product or expenses
associated with rework.
According to Tomaszewski et al. (2008), the tradi-
tional waterfall development projects at Ericsson
suffered from large number of change requests
mainly caused by long development cycles and
extensive analysis of the pre-de?ned release project
scope. The new agile development process called
Streamline (Tomaszewski et al. 2008) promised to
cut down the costs associated with the change
requests substantially. A recent evaluation of the
application of Streamline at Ericsson reports reduc-
tion of requirements volatility in the projects mainly
caused by application of small development pack-
ages and shortening the lead-time of development
projects (Petersen and Wohlin 2008). The Stream-
line development process (called only Streamline
hereafter) is strongly in?uenced by agile and espe-
cially Lean SD, and a summary of it can be found in
Section 4.1.
3.1. Research Roadmap
The goal of this study was to identify how the
introduction of Streamline has affected product
management [pre-project requirements engineering
(RE)] activities practiced at Ericsson. In order to
achieve this goal it was decided to ?rst identify
and study the process and the characteristics of pre-
project decisions at Ericsson. Collected information
was then analyzed using the structure seen in
Table 1. The intention here was to identify howwell
the study ?ndings support the anticipated impact
of agile principles on MDPD outlined in Section
2.3.
Information about the practiced pre-project activ-
ities in Streamline was gathered by means of
studying the pre-project RE decision-making pro-
cess applied in the development of three separate
products at Ericsson. Product 1 and product 2
are large mature systems with a large number of
releases operating all over the world at many cus-
tomer sites. Products 1 and 2 are over 9 years old
andhave undergone sevenandfour releases respec-
tively. Product 3 is a smaller product with only one
previous release since its creation in 2006.
In order to get an overview of the RE decision-
making process three main sources were used to
achieve a triangulation (Gorschek and Wohlin 2004)
of sources as can be seen in Figure 1.
Part A consisted of the study of of?cial process
documentation, Part B was interviews with prac-
titioners allowing for a balanced view where the
of?cial process was weighed against the one actu-
ally practiced, and Part C consisted of observations
(e.g. sitting at the meetings). The use and compari-
sonbetweendifferent sources is at the central core of
the triangulation (Gorschek and Wohlin 2004, Pet-
tersson et al. 2008). The details of study execution
are provided in Section 3.2, and the results obtained
are detailed in Section 4.
3.2. Study Execution
The initial stage was focused on studying the
of?cial process documentation in order to identify
Figure 1. Study overview of mapping pre-project RE
decisions
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
pre-project decisions, roles and responsibilities
associated with the decisions, and mapping the
decision characteristics. In addition, the study of
the of?cial process allowed a mapping of meetings
and forums for decision-making.
3.2.1. Process Documentation Study (Part A)
The documentation study was conducted by means
of reviewing of?cial process descriptions for pre-
project activities in Streamline. A senior expert,
responsible for process improvement activities was
used as a guide to the formal process in order
to identify relevant process documents. An impor-
tant selection criterion for the document study was
to consider those process descriptions and work-
?owguidelines that were commonfor development
activities.
The information provided in the process docu-
mentation was analyzed in order to identify the
major steps/activities and the decisions points
involved in pre-project RE. For each identi?ed
decision point the characteristics were mapped.
Characteristics in this case are the (i) goal(s)
for an activity, (ii) the decision criteria/method
used, and (iii) the decision support material used
and/or produced. The identi?ed roles and decision
forums were later used to plan the interviews and
observations.
3.2.2. Interviews with Practitioners (Part B)
The intention with the interviews was to elicit infor-
mation on the pre-project decision-making process
not evident from the formal process descriptions in
Part A. Semi-structured interviews were used in an
informal setting.
At the beginning of each interviewthe participant
was asked to describe the process of working
with pre-project requirements. In most cases the
interviewees would draw a ?gure of the overall
process and map the major steps/decisions in the
process.
Once the major steps and decisions were identi-
?ed the interviewcontinued detailing them and the
participants were asked a set of questions designed
to retrieve the characteristics of the decision points.
In order to allow a comparison between the formal
and practiced process, for each mentioned decision,
the interviewees answered questions on goals of a
decision, how the decisions were taken, what infor-
mation was important/necessary in order to take
a decision (decision support material used) as out-
lined in Section 3.2.1. At the end of each interview
participants were askedto identify major challenges
and improvement suggestions in relation to the
process and the characteristics.
The results of the interview were transcribed
into session summary sheets (Robson 2002) directly
after the interview session. Information placed in
these sheets followed the same template, providing
data on interviewed person, issues covered, and
researcher’s own notes regarding the information
obtained in the interview.
Once the interviews were completed, the infor-
mation from the individual interview was coded
in different data categories related to the prac-
ticed pre-project requirements decisions and their
characteristics. The utilised data categories covered
topics suchas practices requirements decision steps,
requirement types considered at each decision,
practiced approach for taking decision, required
decision material, experienced challenges, etc. The
coded data from each interview was then placed in
an excel sheet where it was analyzed again in order
to ?nd relations to the agile properties and MDPD
needs presented in Table 1.
The selection of the interview participants was
based on the process documentation where roles
involved in pre-project RE and decision-making
were identi?ed.
Further, the case study consisted of the study
of three different products at Ericsson to make
sure that the process and the characteristics studied
were representative for the organisation. Therefore
the interviewees were also selected to represent
the important roles for each of the products (see
Table 3).
In total 14 interviews were conducted. Each inter-
viewwas conducted individually. To avoid validity
issues such as the subjects feeling uncomfortable
with speaking their mind none of the interviews
were recorded. Detailed notes were taken during
the interviews, and during the subsequent re?ne-
ment of these notes supplemental questions were
posed to the interview subjects post-interview if
needed. The detailed and re?ned notes were then
used to validate understanding and avoid misinter-
pretations as they were shared with the subjects for
validation purposes. The distribution of the inter-
views was the following: Product Managers – 5;
SystemExperts – 3; Line Managers – 3; Project Man-
agers – 3.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Table 3. Roles identi?ed in pre-project RE
Name
(number interviewed)
Description Responsibility
Product Manager (5) This role has the
strategic product
responsibility and
decides the overall
product
development
direction
Select, prioritise
and plan
requirements for
future releases
System Expert (3) This role is
populated by
people with expert
knowledge of the
systems and their
architecture
Responsibility of
system
architecture and
system
development
plan
System experts
provide decision
material for product
management since
they are responsible
for providing
analysis of
pre-project
requirements, in the
form of feasibility,
impact and
technical
dependencies
Line Manager (3) Line managers have
overall
responsibility of
Development and
Testing (R&D)
resources. They
plan for R&D
utilisation in
development
projects and allocate
resources to
develop
requirements
selected by product
management
R&D capacity
overview,
planning of
development
projects
Project Manager (3) Responsible for the
detailed planning,
execution and
follow-up of
development
projects for a
speci?c release
Planning and
execution of a
speci?c project
3.2.3. Observations (Part C)
This part of the study was focused on attending
forums and meetings where pre-project decisions
were discussed. These forums were identi?ed
initially in the process study (Part A) and later
con?rmed by the process expert at the company.
Identi?ed decision forums are summarised in
Table 4.
In total four meetings were attended; Pre-project
Requirements Council (2), Release Scope re?nement
Board(1) andRelease PlanningBoard(1). Inorder to
minimise anypotential effect causedbythe presence
of a researcher the meetings were not recorded.
Instead a researcher observed the character and
content of discussions and decision-making process
during the meetings and notes were taken.
4. EMPIRICAL RESULTS
4.1. Process Documentation Study (Part A)
Figure 2 presents the major pre-project activities
in Streamline as described in the process docu-
mentation. The activities are displayed in chrono-
logical order (order of execution in the company).
Table 4. Decision forums
Name
(number visited)
Purpose
Pre-project
Requirements
Council (2)
This council consists of strategic
product managers, technical
product managers and system
experts. Decision forum is used
for decisions on which
requirements will be approved
for further analysis and how the
selected requirements will be
allocated.
Prioritisation
Workshop
Workshop participants include
product managers, system
experts and different requirement
representatives.
Decisions on which requirements
will be assigned highest priority
for the next release are taken.
Release Scope
Re?nement Board (1)
The board consists of product
manager, line manager and
system experts. Here the
decisions on approving
implementation proposals and
associated cost of a requirement
are taken.
Release Planning
Board (1)
The board consists of product
manager, line manager, system
expert and project manager. Here
the decisions regarding release
scope planning and initiating of
development projects are taken.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Figure 2. Pre-project decision making process in Streamline
As shown in the ?gure, pre-screening of incom-
ing requirements, requirements prioritisation and
release scope analysis and re?nement are the major
activities performedprior to initiating development
projects.
4.1.1. Pre-screening
According to Streamline, initial requirements are
elicited from different sources in a continuous
manner. Incoming requirements are then inserted
in the repository after which they pass through the
pre-screening step. The goal of this activity is to
identify a sub-set of requirements that is interesting
to include in a certain product. The process
involves two sub-steps: selection and analysis.
During selection requirements are analyzed in
order to determine suitability of a requirement
for a certain product. In this step requirements
that are wrongly allocated to a product, duplicate
requirements and other requirements that are
considered not suitable for a product are ?ltered
away. During analysis requirements are analyzed
to determine their business value and technical
impact. This information together with directives
from product plans and roadmaps are used to
allocate requirement to a certain release of a
product. At the end of the pre-screening step an
initial requirement is either allocated to a future
release, rejected, or considered so urgent that is
allocated to the release under de?nition.
4.1.2. Prioritisation
During this step requirements that are allocated to
a certain release are prioritised in order to produce
an initial release scope. At the end of a prioritisation
step only a small sub-set of all requirements that
are allocated to a certain release are selected to
be included in the list of prioritised requirements
for a certain release which in Streamline is called
‘Priority directive’ of a release. At the end of the
prioritisation step requirements included in the
‘Priority directive’ are handed over to the R&D
organisation (development and testing) for analysis
and realisation.
4.1.3. Release Scope Analysis and Re?nement
The goal of this activity is to analyze and package
requirements includedinthe ‘Prioritydirective’ into
small development projects each in size approx-
imately 3 months. Activities in this step have a
continuous and iterative character where require-
ments are analyzed and assigned to development
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
projects following the order of their priority in the
‘Priority directive’.
Once the priority directive is received by R&D
the initial step is to create a project anatomy plan.
The purpose of the anatomy plan is to identify
and describe functional dependencies between the
requirements in the priority directive, which are
subsequently used to update the priority order
taking the dependencies into account, resulting in a
function container list. This list provides a base for
the planning of development projects as it dictates
in which order the requirements will be analyzed
and assigned to the development projects.
When the ?rst version of the function container
list is available, R&D can start conducting techni-
cal analysis of requirements following the priority
order dictated by the list. Requirements are ana-
lyzed independently and development projects are
initiated as soon as the line management in the
R&D organisation can ?nd and allocate resources
necessary for realisation of the selected solution
proposal.
The technical analysis of eachrequirement should
take a maximum of twenty (20) person-hours and
produce a report detailing which components of
the existing system will be affected by the new
functionality, possible implementation solutions,
and a cost estimate of each solution. The results
of the technical investigation is presented at the
Release Planning Board (see Table 4) and the
solution that provides the best trade-off between
product management priorities, resource capacity,
and system architecture impact is selected. If an
acceptable trade-off cannot be reached, for example
the estimated cost of requirements implementation
is higher than expected by product management,
or the resource capacity is inadequate the priority
order of this requirement must be renegotiated.
4.1.4. Summary
Streamline is a process that tries to apply agile
principles in an MDPD context. The process has
clear characteristics of market-driven development,
where requirements are collected from different
sources and ?ltered through the pre-screening
and prioritisation steps to produce the ‘Priority
directive’ of a release.
Streamline also has a strong connection to
agile and lean development principles, which is
evident in the step of release content analysis and
re?nement. As shown in Section 4.1.3, the scope of a
release if not ?xedanddevelopment activities donot
wait until analysis of all requirements allocated to a
release are ?nalised, instead development projects
are initiated as soon as analysis of top priority
requirement allows for identifying what resources
are necessary and these resources can be allocated.
This approach is in line with the agile property
AP3 – Evolving release scope. In Streamline this
propertyis intendedto ensure that the development
effort is focused on top priority requirements and
to minimise waste connected to change requests
mentioned in Section 3.
4.2. Interviews and Observations (Part B
and Part C)
In this section we describe study results obtained
via interviews with the practitioners and conducted
meeting observations. The results are grouped
according to major pre-project steps identi?ed in
the process documentation study (see Section 4.1).
4.2.1. Results for Pre-screening (Step 1 in Figure 2)
4.2.1.1. Finding 1: Practiced Approach for Pre-screening
Interviews with the practitioners showed that in
general practiced activities followed the steps of the
documented process. However some differences
were identi?ed.
As shown in Table 5, for product 1 and prod-
uct 2 activities in pre-screening mainly focus on
de?ning if a requirement is appropriate for the
product, rather than evaluating requirement’s busi-
ness value and technical impact as prescribed by
the process documentation. This type of analysis
was performed in an informal way and no reports
were produced. Product managers for this product
explained: ‘‘we receive hundreds of requirements; there-
fore the ?rst step is to lower the volume by removing
duplicates and requirements that are wrongly allocated
to our product’’.
In the case of product 3 the pre-project activities
considered both technical analysis and value evalu-
ation. However compared to the technical analysis,
evaluation of the requirements value received little
attention. Moreover, mechanisms used for evaluat-
ing and determining value of a requirement were
not obvious. Observation of Pre-Project Require-
ments Council meetings for product 3 con?rmed
this since most of the meeting time was spent
on clarifying technical details around the require-
ments. Technical evaluation was mostly based on
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
Table 5. Practiced approach for pre-screening
Approach/criteria
for pre-screening
Reqirement
types
Product 1 and
Product 2
Practiced approach
for pre-screening is
focused on
identifying:
(i) duplicates, (ii)
requirements that
are wrongly
addressed (not
applicable for a
product), (iii)
unreasonable
requirements like
‘‘you should have
no downtime’’
Commercial
requirements
from in?uential
customers and
market units
Product 3 Focus on evaluating
impact and cost of a
requirement
Commercial
requirements
from in?uential
customers and
market units
expert opinion. For requirements that were con-
sidered complex an of?cial technical report was
ordered and produced.
4.2.1.2. Finding 2: Balance between Different Require-
ment Types at Pre-screening During the interviews
product managers of eachproduct were askedto list
the different types of the requirements considered
by them during pre-screening. All product man-
agers listed commercial requirements originating
mainly from in?uential customers and marketing
units, while other types of requirements like tech-
nical and architectural improvements or product
life-cycle requirements were not mentioned.
4.2.2. Results for Requirements Prioritisation (Step 2
in Figure 2)
When it comes to requirements prioritisation,
interviews with practitioners provided detailed
information on the applied prioritisation technique
and evaluation criteria, which was missing in the
formal process descriptions. Findings identi?ed
through analysis of interview results are presented
below:
4.2.2.1. Finding 3: Practiced Approach for Prioritisation
For all the products studied the requirements
prioritisation of requirements in the overall product
planis performedevery6 months. The prioritisation
is performed in the form of a workshop where
experts with different competences participate (see
Table 4). The prioritisation is conducted using pair-
wise comparisons andsupportedby the commercial
tool Focal Point (Telelogic Focal Point – Software
for Product Management and Product Portfolio
Management 2009).
The components used as evaluation criteria
are presented below following the order of their
importance as de?ned by practitioners: (i) bene?t
(value) to company and alignment with product
strategy; (ii) bene?t (value) for potential customers;
(iii) cost; (iv) how well the requirement improves
non-functional characteristics.
For all three products the prioritisation and
qualifying the criteria, such as requirements cost
and value (for the organisation itself and potential
customers), were mainly based on expert opinion
(knowledge). Occasionally for estimating cost of
a requirement additional material such as technical
reports were used. Whenit came to estimating value
it was completely based on expert opinion. The
practitioners in general found it dif?cult to explain
the mechanism behind estimation of requirements
value. One of the product managers commented
‘‘we estimate requirements value based on the knowledge
of our product and our customers’ needs’’.
4.2.2.2. Finding 4: Balance between Different Require-
ments Types at Prioritisation At this stage of the
practicedprocess all products consideredboth com-
mercial and technical requirements. When it comes
to the question of balance between the commer-
cial and technical requirements the interviewed
system experts expressed their concern that sys-
temand architectural improvements were receiving
less attention compared to commercial require-
ments from e.g. market units and key-customers.
‘‘Internal requirements connected to architectural and
system improvement issues have a hard time compet-
ing with commercial features and often end up lower in
the prioritised list of requirements’’ mentioned one of
the system experts. Another expert noted: ‘‘system
requirements receive attention when we can show that
they are necessary for implementation of some important
commercial requirement’’. System experts anticipated
that this development could in the long run cause
deterioration of the system architecture. The inter-
views systemexperts also expressed that describing
the value of system requirements was not easy and
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
that they needed guidelines for formulating the
‘business case’ for system requirements.
4.2.3. Results for Release Scope Analysis and
Re?nement (Step 3 in Figure 2)
Analysis of the interviews with involved roles
in this step, and data collected via observations
of Release Scope re?nement Board and Release
Planning Board meetings (see Table 4) revealed
that involved parties made a real effort to follow
the agile way of working described in the process
documentation. However, following lean principles
to 100% when planning the contents of the future
release proved to be problematic.
4.2.3.1. Finding 5: In Practice It Was Not Realistic to
Follow Lean Development Principles Fully The study
results indicated that following the practices of
evolving release scope (AP3) as described in the
of?cial documentation for Streamline (see Section
4.1.3) made it dif?cult to know which of the
requirements included in the priority directive
would be included in the ?nal release. This created
disturbances for product managers who were in
need to have a good overview of release plan and
its contents. As one product managers explained
‘‘if we follow agile then I can not tell market units and
in?uential customers what functionality will be delivered
in the next release’’.
According to the interviewed line managers and
product managers it was usual that the number of
requirements included in the priority directive was
more than the capacity of the organisation, thus
not all requirements could be implemented. Conse-
quently the product managers required con?rma-
tion from the R&D department on how many of
the requirements in the priority directive would be
possible to include in the release. This in turn meant
that all requirements in the priority directive had
to be analyzed to produce a reliable cost overview
of the requirements included in the priority direc-
tive (according to interviewed line managers the
available information on the cost from the previous
pre-project steps was too high level to be trusted).
This situation created problems since analyzing the
entire scope of the release was against the lean
philosophy of Streamline and line and project man-
agers at the R&D department were afraid to fall
back into the waterfall way of working.
In order to ?nd a middle ground between lean
principles and the needs of product management
a commitment model was suggested according to
which the R&D organisation would commit up to
50% of requirements in the priority directive from
the start. This meant that the scope of the release
would be de?ned ahead of development projects
and it would contain the ?rst half of all prioritised
requirements. The remaining requirements would
remain as candidates for in-scoping and would be
considered only after the analysis of the committed
scope was ?nished and necessary resources for
producing the requirements assigned to the scope
were secured.
4.2.3.2. Finding 6: Related topic: Different Attitudes
Towards Agile in R&D and Product Management
Interviews revealed a difference between the atti-
tudes towards agile principles in the R&Dorganisa-
tion and in the product management organisation.
Line and project managers who are representing
R&D were in general positive and enthusiastic
towards agile, while product managers in general
expressedconcernabout agile. As one product man-
ager said ‘‘I must feel con?dent about the contents of
the release in order to be able to market our product and
handle competition’’. It is interesting to note that the
R&D organisation perceived the product managers
concern about agile principles to be due to ‘‘the old
way of thinking’’. As some of the project managers
said ‘‘Product managers just have to ?nd different ways
to sell our products.’’
4.2.4. Summary
In this section the ?ndings identi?ed through inter-
views and observations will be analyzed with
regard to the extent the practiced process follows
the of?cial Streamline process described in Section
4.1. After this, the ?ndings from the interviews
and observations are organised in practiced pro-
cess symptoms, providing ground to discuss the
implication of agile properties on MDPD needs.
Comparison between of?cial and practiced pro-
cesses: Finding 1 and Finding 3 show that for
the steps of pre-screening and prioritisation the
practiced process closely followed the steps out-
lined by the of?cial process (see Section 4.1). Some
differences were identi?ed showing misalignment
when it comes to the focus of the activities (for
example in pre-screening the activities were less
focused on value analysis than expected). In addi-
tion, the produced decision support material was
not always written down as of?cial reports on
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
technical and business analysis (as mandated by
the formal process), but often consisted of informal
decisions based on expert opinion.
According to Finding 5 the largest difference
between practiced and of?cial process was identi-
?ed in the step of release planning and re?nement,
where the practice of evolving release scope as
prescribed by Streamline was in reality dif?cult to
follow. It is important to notice that the step of
release scope analysis and re?nement represents
the actual change from the waterfall approach to
the new agile way of working with the require-
ments. According to the existing research on the
extent of methodology adoption (Fitzgerald 1998) it
is not uncommon that the prescribed development
methodology in reality is not followed rigorously.
However, in this case the interviews and obser-
vations provided clear indications that due to the
problems associated with the old way of working,
the practitioners have made every effort to follow
the prescribed process. It was due to the misalign-
ment with the needs of decision makers that the
adaptations to the prescribed way of release content
analysis and planning was necessary.
4.2.4.1. Practiced Process Symptom 1: Pre-project
Activities are Focused on Commercial Requirements
Analysis of the ?ndings for the pre-screening and
prioritisation steps shows clearly that these initial
pre-project activities are mainly driven by commer-
cial requirements (see Finding 2 and Finding 4).
Additionally according to Finding 4, commercial
features are often prioritised over other types of
requirements like architectural improvements.
4.2.4.2. Practiced Process Symptom 2: Evolving Release
Scope Was Found Wanting in Relation to the Needs of
Decision Makers Finding 5 indicates that applying
the concept of evolving release scope (AP3) was
dif?cult for release planning purposes in a market-
driven context. Thus there was a need to ?nd a
solution where agile properties would be adjusted
to the needs of pre-project decisions. The introduced
approach of a commitment model is an example of
?nding a middle ground between agile principles
and the company’s needs. Further, Finding 6
indicates a lack of understanding of the challenges
and business constraints of pre-project decisions in
a market-driven context.
4.2.4.3. Practiced Process Symptom 3: Requirements
Value is De?ned through Expert Judgement Findings
1 and 3 reveal that practitioners do not have a
clear mechanism for describing, evaluating and
comparing value of different requirement types.
According to Finding 3 evaluation of requirements
value is mainly a tacit process based on expect
opinion, knowledge of product’s business case
and customer needs. Moreover, data presented in
Finding 4 indicate a need to de?ne clear procedures
and guidelines that can be used for representing
different requirement types, for example system
requirements.
5. DISCUSSION
In Table 6 the symptoms of the practiced process
identi?ed through the case study are connected to
the MDPD needs and agile properties that were
presented in Section 2.3.
As shown in the table, Symptom 1 and Symptom
3 of the practiced process is associated with the
agile properties AP1 and AP2 and is considered
to impact the need to ?nd an appropriate balance
between different requirement types, such as com-
mercial requirements, requirements connected to
technologyinnovationandarchitectural andsystem
improvements (N1 and N2). Symptom2 is connected
to AP3 and is considered to impact the needto effec-
tivelyplanthe content of the future release (N3). The
following sections elaborate on the implications of
applying agile properties on pre-project activities in
the MDPD context, and discuss possible solutions
to decrease the gap between agile properties and
needs in MDPD.
5.1. Feature Orientation vs. Balancing Different
Requirement Types
In the MDPD context balancing commercial, archi-
tectural and quality requirements are extremely
important (Ebert 2005, Regnell et al. 2005). The sys-
tem architecture is seen as one of the assets on
which future releases will be built andmaintainabil-
ity issues are connected to the cost of supporting
different versions of the products in the market
over time (Tomaszewski et al. 2008). The problems
of ?nding a balance between features and architec-
ture improvements have been acknowledged and
reported by other researchers (Wohlin and Aurum
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Table 6. Alignment of study results with agile and MDPD properties
Agile property MDPD need Observed symptom Possible impact
AP1. Feature orientation N1. Balancing different
requirements types
Symptom 1: Pre-project
activities are focused
on commercial
requirements
- Short-term thinking
AP2. Reactive development N2. Trade-off between
market-pull and
technology-push
Symptom 3:
Requirements value is
de?ned through expert
judgement
- Possible architecture
deterioration
- Product integration
problems
- Limited ability for
pre-emptive release of
features and thus
in?uencing markets
AP3. Evolving release scope N3. Release content
planning
Symptom 2: Evolving
release scope was
found un?tting for the
needs of decision
makers
- Limited possibility to
in?uence and plan
release content and
related development
cost
- Limited
understanding of total
release value
- Change management
becomes dif?cult (no
baseline to compare)
2005) and are common to Market Driven Require-
ments Engineering (MDRE).
The results of the conducted case study have
shown the dominance of commercial requirements
in Streamline, threatening to create an imbalance
between features and other types of requirements
not driven by the perceived immediate needs to the
customer or market.
In the case studied in this article we can not
claim that a perfect balance existed prior to the
introduction of Streamline. However there is a risk
that due to the agile properties of feature orientation
and reactive development (AP1 and AP2), ?nding
the balance might be even more dif?cult. This
assumption partly is motivated by a lack of support
for handling non-functional requirements in agile
methods (Paetsch et al. 2003, Sillitti et al. 2005), as
well as existing research where feature orientation
and reactive development in agile methods is
named as a threat for long-term goals such as
maintaining a clean system architecture and other
quality aspects (Boehm 2002, Tomaszewski et al.
2008).
The risk of increased dominance of commercial
requirements when applying agile methods can be
explained by examining the de?nition of require-
ments value and requirements priority in agile
methods.
As discussed in Section 2.3, agile methods focus
on delivering rapid value for a customer, where
requirements value and consequently its priority
is strongly associated to the customer value of a
requirement (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007). This de?nition of a require-
ment’s value in agile methods in combination with
unclear procedures for de?ning requirements value
(Practiced Symptom 3) can easily encourage pri-
oritisation of commercial requirements which have
a direct link to existing customers and overlook
the value of requirements which cannot be easily
linked to the customer, for example system and
architecture related requirements.
The latest studies of requirements prioritisation
practices applied in industry have revealed that
having unclear procedures when it comes to def-
inition of requirements value is not uncommon
(Barney et al. 2006, Lehtola and Kauppinen 2006).
Thus for companies aiming to combine market-
driven development with agile practices and still
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
maintaina reasonable balance betweenthe commer-
cial and other types of requirements it is extremely
important to (i) establish a clear picture of what
is/should be perceived as valuable for a company,
as opposed to value based only on the current needs
of customers and howcommercial and other type of
requirements ?t in this picture; and (ii) de?ne clear
procedures and guidelines for expressing the value
of non-commercial requirements.
5.2. Evolving Release Scope vs. Release Content
Planning
Previously in this article it was arguedthat applying
the concept of evolving release scope as de?ned in
AP3 fundamentally limits product managers’ abil-
ity to preemptively plan and control the contents
and value of a release. The potential limitations
of applying the evolving release scope concept in
MDPDcontext can be explainedby the assumptions
of agile methods regarding development and busi-
ness context in which a company operates (Section
2.3), as well as the simplistic view of agile meth-
ods when it comes to deciding the priority order of
requirements and managing the release scope.
In agile methods all development is orchestrated
by the priority order of requirements, making
the priority list central and very important. The
question is then how this priority is decided.
Agile methods provide quite a simple solution
to this where the task is left to the customer
who decides priority based on the business value
of a requirement. In order to help the customer
prioritise, the developers provide some rough cost
estimates, but mainly the order is decided by the
business value (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007).
In MDPD the priority and implementation order
of a requirement is a function of the expected value
and cost of a requirement, technical dependencies
of a requirement and value dependencies between
the requirements (Carlshamre 2002, Greer andRuhe
2004, SaliuandRuhe 2005, Ngo-The andRuhe 2008).
The mentioned difference in de?nition of priority
implies that for the same set of initial requirements
agile and MDPD will produce different priority
orderings of these. More importantly, the de?nition
of requirements priority in agile, in combination
withthe concept of the evolvingrelease scope affects
the possibilities to plan and follow up the contents
and expected ROI of a release. This point is further
on exempli?ed in Figure 3.
Figure 3 shows typical process steps of release
content planning and evolution in an agile (to
the left) and market-driven (to the right) context
respectively and inputs and outputs for each step.
Looking at the ?gure it is easy to notice that both
scenarios follow the same process steps. In both
of the scenarios there are collections of prioritised
requirements that represent the initial release scope
and both of the scenarios are iterative, where the
development activities follow the priority order of
requirements placed in the release scope. After each
iteration there is a process step allowing analysis of
delivered results and progress, as well as handling
of changes, for example dealing with newly elicited
requirements (Req. x in the ?gure). This analysis may
result in re-prioritisation and an updated release
scope.
A closer look at Figure 3 however uncovers
critical differences between the two scenarios, most
of which is caused by the difference in how the
priority and implementation order of a requirement
is de?ned in agile vs. MDPD.
The differences between the scenarios are sum-
marised below: (i) priority order of requirements in
the initial scope is different between the scenarios,
resulting in differences in development activities.
For example in the agile scenario the ?rst iteration
focuses on Req. a, and in the MDPDscenario on Req.
c; (ii) requirements analysis and re-prioritisation
step results in different content and requirements
priority order in the updated scope of each scenario;
where for example the newly arrived requirement
Req. x in the agile scenario receives high priority
and in the market-driven scenario does not. (iii)
And ?nally in MDPDscenario pre-project decisions
are tightly connected with de?ning and following
up the total value and expected ROI of the ?nal
release (in the ?gure this is indicated by assigning arbi-
trary values for total release ROI and total release value)
whereas in agile scenario this kind of analysis is
dif?cult (denoted by having question marks for the same
variables).
The de?nition of the priority order of the require-
ments in MDPD demands a proper understanding
of all requirements which are assigned to the scope.
This way it provides a base for estimating the target
ROI and total value provided by the requirements
selection (Saliu and Ruhe 2005, Ngo-The and Ruhe
2008). This base is thenusedinorder toplan, control,
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Figure 3. Differences in approach towards release planning between Agile and MDPD
and follow up how well the selected list of require-
ment satis?es target business goals of a release. In
addition it is important to gauge the consequences
of how removing or adding a new requirement to
a release scope affects the total value and expected
ROI of a release, making it possible to deal with a
change in an appropriate way.
The simple de?nition of the priority order of
the requirements in agile methods combined with
the property of an evolving release scope (AP3)
does not allow an in-depth analysis of all candidate
requirements (Beck and Fowler 2001, Poppendieck
and Poppendieck 2003, Williams and Cockburn
2003, Lef?ngwell 2007). This makes it dif?cult
to de?ne the target ROI and total value to be
deliveredby the release andcreates a risk of abusing
the practice of ‘delaying the decisions’ where the
decision on what will be included in the release is
taken after the fact, and thus the target ROI and the
total value provided by the release is not clear until
after the delivery.
Results of the conducted case study have pro-
vided two important insights regarding this issue.
Firstly the results uncovered dif?culties to follow
the practice of evolving release scope, mainly due
to posed limitations to product management oper-
ations (see Finding 5). This result relates well to the
MDPD characteristics presented in Section 2.2, and
provides support for above-outlined discussion on
misalignment between product management needs
and limited possibility of managing and controlling
release scope in agile methods.
Secondly the results have indicated different
attributes towards agile methods in the organisa-
tion, showing that while R&D part of the organisa-
tion was in general positive to application of agile
practices in development project, there was lim-
ited understanding of how agile properties affected
product management (see Finding 6).
The above mentioned ?ndings are important
since they show that while agile is appreciated
in separate development projects (Karlstrom and
Runeson 2005, Svensson and H¨ ost 2005, Petersen
and Wohlin 2008) they are not directly suited
or designed for long-term product planning and
product management, thus there is a need to ?nd
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
a way to apply agile methods in development
projects without disrupting product management
operations which are in need of more long-term
planning and control.
The need for ?nding a compromise between
agile and plan-driven approaches and tailoring
agile methods to meet speci?cs of different prod-
uct development and business contexts has been
suggested by other researchers as well (Boehm
2002, Abrahamsson et al. 2003, Cohen et al. 2004,
Fitzgerald et al. 2006), however currently a concrete
suggestion on how to accomplish this in MDPD
context has not been suggested. The commitment
model described in Finding 5 represents one exam-
ple of such a compromise. However, it is important
to notice that in order to determine the ?st selection
of functionality committed to by R&D, somewhat
reliable information on the relative value and the
cost of all requirements assignedto the release scope
should be available. This implies that some pre-
study work is still necessary. The question is what
is good-enough, and howto support informed deci-
sion making without investing too much effort or
over analysing the requirements (Fricker et al. 2007).
5.3. Validity
Issues connected to construct validity; internal
validity and external validity describe commonly
known validity threats associated with empirical
studies (Yin 1994, Wohlin et al. 2000).
Construct validity is concerned with establishing
the correct operational measures in order to assure
that the proper information will be collected. This
includes decisions on how the information sources
are selected. The usual way to handle this threat is to
use multiple sources of information. The case study
at Ericsson was designed to use multiple sources
of information and multiple ways of collection
from documentation analysis and interviews to
observation sessions during meetings. All these
sources allowed for data triangulation. As shown
in Section 3.1, studied documents, interviews, and
meetings were carefully selectedto achieve a correct
representation.
Whenconductinginvestigations that are basedon
interviews, the amount and form of the interviews
are important. In this case study budget and time
considerations as well as availability constraints
allowed for a total of 14 interviews. The interviews
were semi-structured. Notes and conclusions made
during the interview sessions were also con?rmed
by sending them to the interview subjects, where
additional questions for clari?cation were attached
where relevant. In some cases an extra interview
was arranged, however these extra interviews are
not included in the total count of the interviews in
the study.
Internal validity threats are usually important
when examining the causal relationships. The
case study presented in this article is mainly
focused of studying the characteristics of pre-
project activities. It has an exploratory character
thus the internal validity threats can be considered
as minimal. In the discussion section study ?ndings
are used to explore how well the study ?ndings
support the anticipated misalignment between
agile properties and MDPD needs as described
in Section 2.3. For example the dominance of
commercial requirements in pre-project activities
(Symptom 1) is connected to the agile properties
feature orientation (AP1) and reactive development
(AP2) and dif?culties with applying the concept of
evolving release scope (Symptom 2) is associated to
the agile property of evolving release scope (AP3).
External validity is concerned with generalisabil-
ity issues and is a threat that is common to case
study research. Even though the case study in this
report is conducted in a concrete industrial setting,
we hope that the study results should be generalis-
able beyond the studied case since the investigated
pre-project activities are not speci?c only for Erics-
son but are common for most companies operating
in a market-driven context.
6. CONCLUSIONS
In this article we have investigated the applicability
of agile methods for MDPD, focusing particularly
on pre-project activities such as requirements pre-
screening, prioritisation and release planning. The
presented work is considered to add value since
it is one of the ?rst contributions that investigates
the applicability of agile practices in this context,
providing extensive analysis and comparison of
agile practices andneeds inMDPD, as well as results
froma large empirical study at Ericsson. This area is
especiallyrelevant consideringthe current hype and
popularity of agile methods, and the contents and
conclusions of this article should be interesting for
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
anysoftware companyoperatingina market-driven
context planning to adopt agile practices.
The initial analysis and comparison of agile prop-
erties and MDPD needs (see Section 2.3) indicated
a misalignment between the two. This was further
con?rmed by the results of the case study, where
the impact of agile properties was studied for three
different products developed at Ericsson. The out-
come of the case study has providedcon?rmation of
the misalignment between agile property ‘evolving
release scope’ and the needs for release planning
in the market-driven context. Further, case study
?ndings also provided indications that ‘feature ori-
entation’ and ‘reactive development’ might be a
threat when it comes to balancing commercial and
other types of requirements, and achieving a trade-
off between market-pull and technology-push as
these aspects are not central in agile development.
Looking at the origin of agile/lean develop-
ment the misalignment can be partially explained.
Agile methodology having bespoke software devel-
opment origin was developed with customer–
developer relationships in mind and has a project
focus. Thus agile methods such as Scrum and XP
are lacking support for anoverall long-termproduct
development focus, normally associated with soft-
ware product management activities in companies
like Ericsson.
The main conclusion drawn is that agile methods
do not directly support the needs of pre-project
activities in MDPD. Application of agile properties
in an organisation operating in market-driven
context places limitations on product management
activities, and may have a detrimental effect on
long-term product development.
Research results presented in this article indicate
that agile principles in their current formshould not
be forced on product management tasks since they
are not ?t for it. In MDPD product managers need
to maintain long-term focus, differentiate between
customer and enterprise value and plan and control
the scope of a release. However, this does not mean
that product management can not bene?t from
agile/lean principles at all. The ideas from Lean
SD can be reused to ?nd ways for producing good-
enough decision material for product management,
enabling informed decisions far beyond the scope
of any individual project. For example companies
should bene?t from practices which will allow
minimising time and effort spent on analysing
pre-project decisions. These practices should also
guarantee that minimising effort does not come
at cost of jeopardising product managers’ ability
to take informed decisions or increased costs in
later stages of product development. The point here
is that while it is important to produce fast, it
is also important to maintain the big picture and
understand how the achievements of individual
development projects bene?t both short- and long-
term business goals of the company developing the
product.
6.1. Future Work
Through the investigation and uncovering of the
impact of agile practices on software product
management activities the authors of this article
hope to create a foundation for ?nding ways
to incorporate agile projects in MDPD without
compromising long-term product goals.
The initial steps towards solving this issue will
be connected to resolving the uncovered misalign-
ment points between agile principles and product
management needs. The future research will evolve
in two directions: (i) the ?rst direction will focus on
helping software companies maintain an appropri-
ate balance between different types of requirements
even when following agile development princi-
ples. In order to achieve this we plan to work
on separation of customer value from enterprise
value and ?nding approaches for de?ning and
comparing value of commercial and architectural
requirements. (ii) The second direction intends to
?nd ways of applying lean development ideas in
software product and release planning situations.
The key here is in ?nding just-enough level of anal-
ysis of the entire release scope without requiring
excessive details but also allowing for the presence
of decision support material (e.g. in the form of
good-enoughrequirements). Inthis way the authors
hope to facilitate de?ning practices for Lean SD.
ACKNOWLEDGEMENTS
We would like to express our gratitude to Ericsson,
an industrial partner of the BESQ(Blekinge Institute
of Technology, Sweden;http://www.bth.se/besq)
research centre, for making this study possible.
In the search for a middle ground between agile
and plan-driven models Ericsson has taken an
important step to integrate agile methods into their
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
product development. Through the experience of
using these methods, Ericsson started adding to
state-of-the-art by investing effort in ?nding new
and improved ways of applying agile principles
to large-scale product development. These efforts
are a part of joint ongoing research projects. Last
but not least we would like to thank all the skilled
and dedicated professionals at Ericsson for seeing
opportunities and not problems.
REFERENCES
Abrahamsson P, Warsta J, Siponen M, Ronkainen J. 2003.
Newdirections on agile methods: a comparative analysis.
25th International Conference on Software Engineering
(ICSE’03). IEEE Press.
Barney S, Aurum A, Wohlin C. 2006. Quest for a
Silver Bullet: Creating Software Product Value through
Requirements Selection. 32nd EUROMICRO Conference
on Software Engineering and Advanced Applications
(EUROMICRO’06), IEEE Computer Society. Cavtat,
Croatia.
Beck K. 1999. Extreme Programming Explained: Embrace
Change. Addison-Wesley: Massachusetts, Boston MA.
Beck K, Fowler M. 2001. Planning Extreme Programming,
The XP series. Addison-Wesley: Boston, MA.
Boehm B. 2002. Get ready for agile methods, with care.
Computer 35(1): 64–69.
Carlshamre P. 2002. Release planning in market-
driven software product development: provoking an
understanding. Requirements Engineering 7(3): 139–151.
Carlshamre P, Sandahl K, Lindvall M, Regnell B, Nattoch
Dag J. 2001. An industrial survey of requirements
interdependencies in software product release planning.
Proceedings of the Fifth IEEE International Symposium
on Requirements Engineering, Los Alamitos, CA, IEEE.
Clements P, Northrop L. 2002. Software product lines:
practices and patterns. The SEI Series in Software
Engineering. Addison-Wesley: Boston, MA; 608.
Cohen D, Lindvall M, Costa P. 2004. An introduction to
agile methods. Advances in Computers 62: 1–66.
Dagnino A, Smiley K, Srikanth H, Anton AI, Williams L.
2004. Experiences inapplyingagile software development
practices in new product development. 8th IASTED
International Conference on Software Engineering and
Applications: Cambridge, MA.
Dahlstedt A, Karlsson L, Persson A, NattochDag J,
Regnell B. 2003. Market-driven requirements engineering
processes for software products – a report on current
practices. International Workshop on COTS and Product
Software RECOTS, held in conjunction with the 11th IEEE
International Requirements Engineering Conference, Los
Alamitos, CA, IEEE.
Dyb? a T, Dingsøyr T. 2008. Empirical studies of agile
software development: a systematic review. Information
and Software Technology 50(9–10): 833–859.
Ebert C. 2005. Requirements BEFORE the requirements:
understanding the upstream impacts. 13th IEEE
International Conference on Requirements Engineering
(RE’05), IEEE Paris, France.
Erickson J, Lyytinen K, Siau K. 2005. Agile modeling,
agile software development, and extreme programming:
the state of research. Journal of Database Management 16(4):
88–100.
Fitzgerald B. 1998. An empirical investigation into the
adoption of systems development methodologies. Journal
of Information & Management 34: 317–328.
Fitzgerald B, Hartnett G, Conboy K. 2006. Customizing
agile methods to software practices at Intel Shannon.
European Journal of Information Systems 15: 200–213.
Fricker S, Gorschek T, Myllyperki ¨ o P. 2007. Handshaking
between software projects and stakeholders using
implementation proposals. Requirements Engineering:
Foundation for Software Quality, (REFSQ’07). Springer
Berlin/Heidelberg: Trondheim.
Gorschek T. 2006. Requirements engineering support-
ing technical product management. School of Engineer-
ing – Department of Systems and Software Engineering.
Blekinge Institute of Technology: Ronneby. 342.
Gorschek T, Davis A. 2008. Requirements engineering: in
searchof the dependent variables. Informationand Software
Technology 50: 67–75.
Gorschek T, Wohlin C. 2004. Packaging software process
improvement issues – a method and a case study.
Software: Practice and Experience 34(14): 1311–1344.
Gorschek T, Wohlin C. 2006. Requirements abstraction
model. Requirements Engineering 11(1): 79–101.
Greer D, Ruhe G. 2004. Software release planning: an
evolutionary and iterative approach. Information and
Software Technology 46(4): 243–253.
Hanssen GK, Fægri TE. 2008. Process fusion: anindustrial
case study on agile software product line engineering.
Journal of Systems and Software 81(6): 843–854.
Highsmith J, Cockburn A. 2001. Agile software
development: the business of innovation. IEEE Computer
34(9): 120–122.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
N. Dzamashvili Fogelstr¨ om et al.
Ilieva S, Ivanov P, Stefanova E. 2004. Analyses of an agile
methodology implementation. 30th Euromicro Conference.
IEEE Computer Society Press.
Karlsson L, Dahlstedt
?
A, Nattoch Dag J, Regnell B,
Persson A. 2003. Challenges in market-driven
requirements engineering – an industrial interview
study. Proceedings of the Eighth International Workshop
on Requirements Engineering: Foundation for Software
Quality (REFSQ’02). Essen, Germany, Universit¨ at
Duisburg-Essen.
Karlstrom D, Runeson P. 2005. Combining agile methods
with stage-gate project management. IEEE Software 22(3):
43–49.
Koch AS. 2005. Agile Software Development Evaluating the
Methods for Your Organization. Artech House Publishers:
London.
Layman L, Williams L, Cunningham L. 2004. Exploring
extreme programming in context: an industrial case
study. Agile Development Conference, Salt lake city, UT;
published by IEEE Computer Society Press.
Lef?ngwell D. 2007. Scaling Software Agility. Addison-
Wesley: Boston, MA.
Lehtola L, Kauppinen M. 2006. Suitability of require-
ments prioritization methods for market-driven software
product development. Software Process: Improvement and
Practice 11(1): 7–19.
Cunningham W, Manifesto for Agile Software
Development. 2001. [cited 2008-09-30]; Available from:http://www.agilemanifesto.org.
Mann C, Maurer F. 2005. A case study on the impact
of scrum on overtime and customer satisfaction. Agile
Development Conference (ADC’05). IEEEComputer Society:
Denver, CO; published by IEEE Computer Society Press.
Mannaro K, Melis M, Marchesi M. 2004. Empirical
analysis on the satisfaction of IT employees comparing
XP practices with other software development
methodologies. Extreme Programming and Agile Processes in
Software Engineering. Lecture Notes in Computer Science,
Springer, Berlin.
Middleton P. 2001. Lean software development: two case
studies. Software Quality Journal 9(4): 241–252.
Ngo-The A, Ruhe G. 2008. A systematic approach for
solving the wicked problemof software release planning.
Soft Computing – AFusion of Foundations, Methodologies and
Applications 12(1): 95–108.
Noor MA, Rabiser R, Gr ¨ unbacher P. 2008. Agile product
line planning: a collaborative approach and a case study.
Journal of Systems and Software 81(6): 868–882.
North American and European Enterprise Software
and Services Survey. 2005. Business Technographics.
Survey conducted by Forrester Research inc. Available
athttp://www.Forrester.com/ER/Research/Survey/
Excerpt/0, 5449, 436,00.html.
Paetsch F, Eberlein A, Maurer F. 2003. Requirements
engineering and agile software development. 12th IEEE
international Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises, IEEE, Linz,
Austria.
Petersen K, Wohlin C. 2008. Issues and advantages
of using agile and incremental practices. The Eighth
Conference on Software Engineering Research and
Practice in Sweden (SERPS’08), Karlskrona, Sweden.
Pettersson F, Ivarsson M, Gorschek T, Ohman P. 2008.
A practitioner’s guide to light weight software process
assessment and improvement planning. Journal of Systems
and Software 81(6): 972–995.
Poppendieck M, Poppendieck T. 2003. Lean Software
Development – An Agile Toolkit. Addison-Wesley: Boston,
MA.
Potts C. Invented requirements and imagined customers:
requirements engineering for off-the-shelf software. 1995.
Proceedings of the SecondIEEEInternational Symposium
on Requirements Engineering, Los Alamitos, IEEE.
Regnell B, Brinkkemper S. 2005. Market-Driven Require-
ments Engineering for Software Products. In Engineering
and Managing Software Requirements, Wohlin C, Aurum A
(eds). Springer: Heidelberg, Berlin 287–308.
Robson C. 2002. Real World Research: A Resource for Social
Scientists and Practitioner-Researchers, 2nd edn. Blackwell
Publishers: Oxford.
Saliu O, Ruhe G. 2005. Supporting software release
planning decisions for evolving systems. 29th Annual
IEEE/NASA Software Engineering Workshop (SEW’05),
IEEE, Greenbelt, MD.
Schwaber K, Beedle M. 2001. Agile Software Development
with Scrum. Prentice Hall: Upper Saddle River, NJ.
Sillitti A, Succi G. 2005. Requirements engineering for
agile methods. In Engineering and Managing Software
Requirements, Wohlin C, Aurum A (eds). Springer: New
York, NY; 309–326.
Svensson H, H¨ ost M. 2005. Introducing an agile process
in a software maintenance and evoluition organization.
9th European Conference on Software Maintenance and
Reengineering (CSMR 2005). Manchester, UK.
Telelogic Focal Point – Software for Product Management
and Product Portfolio Management. 2009. [cited
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
Research Section
Agile Methods in MDPD
2009-01-22]; Available from:http://www.telelogic.com
/corp/products/focalpoint/index.cfmIBMCorporation.
Tian K, Cooper K. 2006. Agile and software product
line methods: are they so different?. 1st International
Workshop on Agile Product Line Engineering: collocated
with the 10th International Software Product Line
Conference (SPLC), Baltimore, MD.
Tomaszewski P, Berander P, Damm L-O. 2008. From
traditional to streamline development – opportunities
and challenges. Software Process: Improvement and Practice
13(2): 195–212.
van de Weerd I, Brinkkemper S, Nieuwenhuis R,
Versendaal J, Bijlsma L. 2006. Towards a reference
framework for software product management.
Proceedings of the 14th IEEE International Requirements
Engineering Conference (RE’06), IEEE Computer Society,
Minneapolis, MN.
Williams L, Cockburn A. 2003. Agile software
development: it’s about feedback and change. Computer
36(6): 39–43.
Wohlin C, Aurum A. 2005. What is important when
deciding to include a software requirement in a project or
release?. International Symposiumon Empirical Software
Engineering, IEEE, Noosa Heads, Australia.
Wohlin C, Runeson P, H¨ ost M, Ohlson MC, Regnell B,
Wessl´ en A. 2000. Experimentation in Software Engineering:
An Introduction, The Kluwer International Series in Software
Engineering. Kluwer Academic: Boston, MA; 204.
Womack JP, Jones DT, Roos D. 1991. The Machine That
Changed the World : The Story of Lean Production. Harper
Perennial: New york.
Yin R. 1994. Case Study Research. SAGE Publications:
Thousand Oaks, CA.
Copyright © 2009 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., (2009)
DOI: 10.1002/spip
doc_317065581.pdf