7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
1/112
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
2/112
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
3/112
VTT PUBLICATIONS 478
Agile software development Review and analysis
Pekka Abrahamsson, Outi Salo & Jussi Ro
VTT Electronics
Juhani Warsta
University of Oulu
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
4/112
ISBN 9513860094 (soft back ed.)ISSN 12350621 (soft back ed.)
ISBN 9513860108 (URL: http://www.inf.vtt.fi/pdf/)ISSN 14550849 (URL: http://www.inf.vtt.fi/pdf/)
Copyright VTT 2002
JULKAISIJA UTGIVARE PUBLISHER
VTT, Vuorimiehentie 5, PL 2000, 02044 VTTpuh. vaihde (09) 4561, faksi (09) 456 4374
VTT, Bergsmansvgen 5, PB 2000, 02044 VTTtel. vxel (09) 4561, fax (09) 456 4374
VTT Technical Research Centre of Finland, Vuorimiehentie 5, P.O.Box 2000, FINphone internat. + 358 9 4561, fax + 358 9 456 4374
VTT Elektroniikka, Kaitovyl 1, PL 1100, 90571 OULUpuh. vaihde (08) 551 2111, faksi (08) 551 2320
VTT Elektronik, Kaitovyl 1, PB 1100, 90571 ULEBORGtel. vxel (08) 551 2111, fax (08) 551 2320
VTT Electronics, Kaitovyl 1, P.O.Box 1100, FIN90571 OULU, Finland
phone internat. + 358 8 551 2111, fax + 358 8 551 2320
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
5/112
Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi & Warsta, Juhani. Agile
methods. Review and analysis. Espoo 2002. VTT Publications 478. 107 p.Keywords: Software development, agile processes, agile methods, extrem
modelling, open source software development, software projec
Abstract
Agile denoting the quality of being agile; readiness for mo
activity, dexterity in motion software development methods
offer an answer to the eager business community asking for lig
with faster and nimbler software development processes. Thicase with the rapidly growing and volatile Internet software in
for the emerging mobile application environment. The new ag
evoked a substantial amount of literature and debates. Ho
research on the subject is still scarce, as most of existing public
by practitioners or consultants.
The aim of this publication is to begin filling this gap b
reviewing the existing literature on agile software developme
This publication has three purposes. First, it proposes a
classification of agile software development approaches. Seco
software development methods that can be characterized as bei
the defined criteria. Third, it compares these methods andsimilarities and differences. Based on this analysis, future r
identified and discussed.
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
6/112
Contents
Abstract ......................................................................................
1. Introduction..........................................................................
2. Agile overview, definitions and characterizations...............2.1. Background ................................................................
2.2. Overview and definitions ...........................................
2.3. Characterization..........................................................
2.4. Summary ....................................................................
3. Existing agile methods.........................................................3.1. Extreme Programming................................................
3.1.1. Process ...........................................................
3.1.2. Roles and responsibilities...............................
3.1.3. Practices .........................................................
3.1.4. Adoption and experiences..............................
3.1.5. Scope of use ...................................................3.1.6. Current research .............................................
3.2. Scrum..........................................................................
3.2.1. Process ...........................................................
3.2.2. Roles and responsibilities...............................
3.2.3. Practices .........................................................
3.2.4. Adoption and experiences..............................3.2.5. Scope of use ...................................................
3.2.6. Current research .............................................
3.3. Crystal family of methodologies ................................
3 3 1 P
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
7/112
3.4.3. Practices .........................................................
3.4.4. Adoption and experiences..............................
3.4.5. Scope of use ...................................................
3.4.6. Current research .............................................
3.5. The Rational Unified Process .....................................
3.5.1. Process ...........................................................
3.5.2. Roles and responsibilities...............................
3.5.3. Practices .........................................................
3.5.4. Adoption and experiences..............................
3.5.5. Scope of use ...................................................
3.5.6. Current research .............................................
3.6. Dynamic Systems Development Method ...................
3.6.1. Process ...........................................................3.6.2. Roles and responsibilities...............................
3.6.3. Practices .........................................................
3.6.4. Adoption and experiences..............................
3.6.5. Scope of use ...................................................
3.6.6. Current research .............................................
3.7. Adaptive Software Development................................3.7.1. Process ...........................................................
3.7.2. Roles and responsibilities...............................
3.7.3. Practices .........................................................
3.7.4. Adoption and experiences..............................
3.7.5. Scope of use ...................................................
3.7.6. Current research .............................................3.8. Open Source Software development ..........................
3.8.1. Process ...........................................................
3.8.2. Roles and responsibilities...............................
3 8 3 Practices
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
8/112
4. Comparison of agile methods ..............................................
4.1. Introduction ................................................................4.2. General features..........................................................
4.3. Adoption.....................................................................
5. Conclusions..........................................................................
References..................................................................................
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
9/112
1. IntroductionThe field of software development is not shy of introducing ne
Indeed, in the last 25 years, a large number of different appro
development have been introduced, of which only few have su
today. A recent study (Nandhakumar and Avison 1999) argu
information systems1(IS) development methodologies are trea
necessary fiction to present an image of control or to provide a
The same study further claims that these methodologies are t
be used in detail. Parnas and Clements (1986) have made
early on. Truex et al. (2000) take an extreme position and state
that traditional methods are merely unattainable ideals and h
men that provide normative guidance to utopian developmenresult, industrial software developers have become skepti
solutions that are difficult to grasp and thus remain not used
This is the background for the emergence of agile softw
methods.
While no agreement on what the concept of agile actually has generated a lot of interest among practitioners and l
academia. The introduction of the extreme programming meth
as the XP, Beck 1999a; Beck 1999b) has been widely ackn
starting point for the various agile software development appr
also a number of other methods either invented or rediscover
appear to belong to the same family of methodologies. Smethodologies are, e.g., Crystal Methods (Cockburn 2000
Development (Palmer and Felsing 2002), and Adaptive Softw
(Highsmith 2000). As a sign of the increased interest, the Cut
recently dedicated three full issues to the treatment of light m
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
10/112
the participation of at least two major international conferen
limited due to a high number of attendees.
While little is known about the actual payoff of the inves
process technologies (Glass 1999), even less is known abo
organization will benefit from the use of agile softw
methodologies. The initial experience reports from industry a
positive (e.g., Anderson et al. 1998; Williams et al. 2000; Gren
numbers, however, are difficult to obtain at this stage.
Despite the high interest in the subject, no clear agreement has
how to distinguish agile software development from
approaches. The boundaries if such exist have thus established. However, it has been shown that certain methods a
suitable for all individuals (Naur 1993) or settings (Baskervill
this reason, e.g. Humphrey (1995) calls for the developme
process for each software developer. Despite these findings l
been placed on analyzing for which situations agile methods
than others. To our knowledge, no systematic review of amethodologies has been done yet. As a result of this, curre
procedures available for the practitioner for choosing the me
greatest benefit for the given circumstances.
Our goal, therefore, is to begin filling this gap by systematica
existing literature on agile software development metpublication has thus three purposes. Firstly, as a result of
analysis a definition and a classification of agile approac
Secondly, an analysis of the proposed approaches against the d
provided and thirdly agile development methods introduced
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
11/112
2. Agile overview, definitioncharacterizations
The purpose of this section is to characterize the meanings
associated with the concept of agile, and to provide a defi
software development method as used in the context of this pub
2.1. Background
Agile denoting the quality of being agile; readiness for mo
activity, dexterity in motion2 software development methods
offer once again an answer to the eager business community weight along with faster and nimbler software development
especially the case with the rapidly growing and volatile
industry as well as for the emerging mobile application envir
agile methods have evoked substantial amount of literature an
the following feature articles in the Cutter IT Journal3: The Gre
Debate: Part 1 and Part 2. However, academic research on tscarce, as most of existing publications are written by
consultants.
Truex et al. (2000) question if the information systems d
practice actually executed following the rules and guideline
numerous software development methods available. Theprivileged and marginalized methodological information syst
processes as proposed by the authors are presented in Table 1.
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
12/112
Table 1.
Some differences of the privileged
and marginalized
ISD processes.
Privileged methodological text Marginalized meth
Information systems development is:
A managed, controlled process Random, opportunist
by accident
A linear, sequential process Processes are simulta
overlapping and there
between
A replicable, universal process Occurs in completely
idiographic forms
A rational, determined, and goal-
driven process
Negotiated, comprom
capricious
This comparison gives an interesting and enlightening perspec
some background for analyzing the agile software developme
light methods). Privileged method projects use commonly ac(also known as plan-driven) software development methods, w
methods have much in common with the novel agile softw
methods, which are discussed in more depth below.
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
13/112
2.2. Overview and definitions
The Agile Movement in software industry saw the light of d
Software Development Manifesto4 published by a gro
practitioners and consultants in 2001 (Beck et al. 2001; Cock
focal values honored by the agilists are presented in the followi
- Individuals and interactionsover processes and t
- Working softwareover comprehensive document
- Customer collaborationover contract negotiation
- Responding to changeover following a plan
These central values that the agile community adheres to are:
First, the agile movement emphasizes the relationship and
software developers and the human role reflected in the contrainstitutionalized processes and development tools. In the existi
this manifests itself in close team relationships, close wor
arrangements, and other procedures boosting team spirit.
Second, the vital objective of the software team is to continuou
working software. New releases are produced at frequent iapproaches even hourly or daily, but more usually bi-monthly
developers are urged to keep the code simple, straightforward,
advanced as possible, thus lessening the documentation burden
level
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
14/112
maintaining a viable relationship. From a business poin
development is focused on delivering business value immediastarts, thus reducing the risks of non-fulfillment regarding the c
Fourth, the development group, comprising both software
customer representatives, should be well-informed, competent
consider possible adjustment needs emerging during the dev
life-cycle. This means that the participants are prepared to m
that also the existing contracts are formed with tools that suppo
enhancements to be made.
According to Highsmith and Cockburn (2001, p. 122), what i
methods is not the practices they use, but their recognition
primary drivers of project success, coupled with an i
effectiveness and maneuverability. This yields a new combina
principles that define an agile world view. Boehm (200
spectrum of different planning methods with Figure 1, in w
placed at one end and the so called inch-pebble ironbound con
at the opposite end:
XP
AdaptiveSW
development
Milestonerisk-driven
models
Milestoneplan-driven
models
irc
... ...
Agile methods
Hackers
Software CMM
CMM
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
15/112
there is no one-size-fits-all software development model that su
purposes. This opinion is shared by several experts in the field
Cockburn (2002a, p. xxii) defines the core of agile softw
methods as the use of light-but-sufficient rules of project behav
human- and communication-oriented rules. The agile process
sufficient. Lightness is a means of remaining maneuverable
matter of staying in the game (Cockburn 2002a). He propo
sweet spots the presence of which in software development w
prospects for a successful project outcome:
- Two to eight people in one room
o Communication and community
- Onsite usage experts
o Short and continuous feedback cycles
- Short increments
o One to three months, allows quick testing a
- Fully automated regression tests
o Unit and functional tests stabilize
continuous improvement
Experienced developers
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
16/112
2.3. Characterization
Miller (2001) gives the following characteristics to agile so
from the fast delivery point of view, which allow shortening
projects:
1. Modularity on development process level
2. Iterative with short cycles enabling fast verifications an
3. Time-bound with iteration cycles from one to six week
4. Parsimony in development process removes all unnece
5. Adaptive with possible emergent new risks
6. Incremental process approach that allows functio
building in small steps
7. Convergent (and incremental) approach minimizes the
8. People-oriented, i.e. agile processes favor people ov
technology
9. Collaborative and communicative working style
Favaro (2002) discusses the emergence of strategies for con
process showing changing requirements. He proposes the itera
paradigm as the common denominator of agile processes Req
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
17/112
together with relevant project or work order agreements re
development in software business, which inherently supports software development (Warsta 2001).
Highsmith and Cockburn (2001) report that the changing
software business also affects the software development proces
the authors, to satisfy the customers at the time of delivery has
over satisfying the customer at the moment of the project ini
for procedures not so much dealing with how to stop change
but how to better handle inevitable changes throughout its life
claimed that agile methods are designed to:
- produce the first delivery in weeks, to achieve
rapid feedback
- invent simple solutions, so there is less to change
changes is easier
- improve design quality continually, making the n
costly to implement, and
- test constantly, for earlier, less expensive, defect de
The basic principles of agile methods comprise an unforg
working code, effectiveness of people working together w
focus on teamwork. A set of commonsense approaches em
software development processes have been suggested by A
follows:
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
18/112
Boehm (2002) analyses the agile and process-oriented metho
driven as he calls them. Table 2 shows how the Open Sourcparadigm places itself between the agile and plan-driven met
still fairly new in business environment and a number of in
questions remain to be analyzed and answered. Thus the OSS
seen as one variant of the multifaceted agile methods.
Table 2.
Home ground for agile and plan-driven methods (
augmented with open source software column
Home-ground
area
Agile methods Open source
software
Plan
Developers Agile,knowledgeable,
collocated, and
collaborative
Geographicallydistributed,
collaborative,
knowledgeable and
agile teams
Planskill
know
Customers Dedicated,
knowledgeable,
collocated,collaborative,
representative, and
empowered
Dedicated ,
knowledgeable,
collaborative, andempowered
Acce
know
collarepre
emp
Requirements Largely emergent;
rapid change
Largely emergent;
rapid change,
commonly owned,continually evolving
never finalized
Know
stabl
Architecture Designed for
current
Open, designed for
current requirements
Desi
fores
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
19/112
2.4. Summary
The focal aspects of light and agile methods are simplici
development work, accordingly, the development group concen
functions needed at first hand, delivering them fast, collect
reacting to received information. Based on the above discussi
proposed for the agile software development approach, and
publication.
What makes a development method an agile one? This is the ca
development is incremental (small software releases, wi
cooperative (customer and developers working constantly to
communication), straightforward (the method itself is easy
modify, well documented), and adaptive(able to make last mo
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
20/112
3. Existing agile method
In this chapter, the current state of agile software develop
reviewed. The selection of methods is based on the definition
As a result the following methods are included in this a
Programming (Beck 1999b), Scrum (Schwaber 1995; Schw
2002), Crystal family of methodologies (Cockburn 2002a)
Development (Palmer and Felsing 2002), the Rational
(Kruchten 1996; Kruchten 2000), Dynamic Systems Deve
(Stapleton 1997), Adaptive Software Development (Highsmith
Source Software development (e.g., O'Reilly 1999).
Methods will be introduced and reviewed systematically by
structure where process, roles and responsibilities, practic
experiences, scope of use and current research regarding
identified. Process refers to the description of phases in the
through which the software is being produced. Roles and respo
the allocation of specific roles through which the software
development team is carried out. Practices are concretworkproducts that a method defines to be used in the proce
experiences refer primarly to existing experience reports reg
method in practice and method developers considerations
should be introduced in an organization. Scope of use identif
regarding each method, i.e. if such have been documented. F
research and publications are surveyed in order to get an scientific and practical status of the method.
Agile modeling (Ambler 2002a) and pragmatic programming (
2000) are introduced briefly in the last section called Othe
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
21/112
started as 'simply an opportunity to get the job done' (Ha
practices that had been found effective in software develduring the preceding decades (Beck 1999b). After a number o
in practice (Anderson et al. 1998), the XP methodology was "
key principles and practices used (Beck 1999b). Even thou
practices of XP are not new as such, in XP they have been coll
to function with each other in a novel way thus forming a new
software development. The term 'extreme' comes fro
commonsense principles and practices to extreme levels (Beck
3.1.1. Process
The life cycle of XP consists of five phases: Exploration, Plan
Release, Productionizing, Maintenance and Death (Figure 2).
COLLECTIVE
CODEBASE
REGULAR
UPDATES
Priorities Effort
estimates
EXPLORATION
PHASE
PLANNING
PHASE
ITERATIONS TO
RELEASE PHASE
PRODUCTIONIZING
PHASE
STORIES
STORIES
FOR NEXT
ITERATION
TEST
ANALYSIS DESIGN
PLANNING
FOR
TESTING
TESTING
PAIR
PROGRAMMING
CONTINUOUS
REVIEW
FEEDBACK
CONTINUOUS
INTEGRATION
CUSTOME
APPROVA
SMALL
RELEASE
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
22/112
In the Exploration phase, the customers write out the story ca
to be included in the first release. Each story card describes a finto the program. At the same time the project team familiariz
the tools, technology and practices they will be using in
technology to be used will be tested and the architecture po
system are explored by building a prototype of the system
phase takes between a few weeks to a few months, dependin
familiar the technology is to the programmers.
The Planning phasesets the priority order for the stories and
the contents of the first small release is made. The programm
how much effort each story requires and the schedule is then
time span of the schedule of the first release does not norm
months. The planning phase itself takes a couple of days.
The Iterations to releasephase includes several iterations of t
the first release. The schedule set in the planning stage is b
number of iterations that will each take one to four weeks t
first iteration creates a system with the architecture of the whoachieved by selecting the stories that will enforce building th
whole system. The customer decides the stories to be selected
The functional tests created by the customer are run at the end
At the end of the last iteration the system is ready for productio
The Productionizing phase requires extra testing and performance of the system before the system can be released to
this phase, new changes may still be found and the decision
they are included in the current release. During this phase, t
need to be quickened from three weeks to one week The po
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
23/112
system is in production. The maintenance phase may require i
people into the team and changing the team structure.
The Deathphaseis near when the customer does no longer h
be implemented. This requires that the system satisfies custo
other respects (e.g., concerning performance and reliability). T
the XP process when the necessary documentation of the
written as no more changes to the architecture, design or codemay also occur if the system is not delivering the desired
becomes too expensive for further development.
3.1.2. Roles and responsibilities
There are different roles in XP for different tasks and pur
process and its practices. In the following, these roles are prese
Beck (1999b).
ProgrammerProgrammers write tests and keep the program code as simp
possible. The first issue making XP successful is to communica
with other programmers and team members.
Customer
The customer writes the stories and functional tests, and derequirement is satisfied. The customer sets the implementatio
requirements.
Tester
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
24/112
evaluates whether the goal is reachable within the given r
constraints or if any changes are needed in the process.
Coach
Coach is the person responsible for the process as a
understanding of XP is important in this role enabling the c
other team members in following the process.
Consultant
Consultant is an external member possessing the specific tec
needed. The consultant guides the team in solving their specific
Manager (Big Boss)
Manager makes the decisions. In order to be able to do this, he
with the project team to determine the current situation, and to
difficulties or deficiencies in the process.
3.1.3. Practices
XP is a collection of ideas and practices drawn from
methodologies (Beck 1999a). The decision making structure
Figure 3, in which the customer makes business decisions w
decide on technical issues is derived from the ideas of Alexa
rapid type of evolution in XP has its roots in the ideas behind and Nonaka 1986) and the pattern language6 of Cunningham
idea of scheduling projects based on customer stories is draw
(Jacobsen 1994) and the evolutional delivery is adopted from
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
25/112
the spiral model, the initial response to the waterfall model, ha
on the XP method. The metaphors of XP originate from the woJohnson (1998), and Coyne (1995). Finally, the physical wor
for programmers is adopted from Coplien (1998) and DeM
(1999).
Figure 3.Roots of Extreme Programming.
XP aims at enabling successful software development dconstantly changing requirements in small to medium siz
iterations with small releases and rapid feedback, custom
communication and coordination, continuous integration and
ownership of the code, limited documentation and pair program
the main characteristics of XP. The practices of XP are
following according to Beck (1999a).
Planning game
Close interaction between the customer and the programmers.
estimate the effort needed for the implementation of custom
X1970 1980 1990
Decision making
[Alexander, 1979]
Rapid evolution [Takeuchi and
Nonaka, 1986], [Cunningham, 1996]
Feature based specification a
sheduling of projects [Jacobs
Evolutionary delivery [Gilb, 1988]
Spiral Model [Boehm, 1988]
Metaphors [Lakoff, J1998], [Coyne, 1995
Physical e[Coplien, 1
Individual practices of XP
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
26/112
Metaphor
The system is defined by a metaphor/set of metaphors betweenthe programmers. This "shared story" guides all development b
the system works.
Simple design
The emphasis is on designing the simplest possible
implementable at the moment. Unnecessary complexity anremoved immediately.
Testing
Software development is test driven. Unit tests are implemente
and are run continuously. Customers write the functional tests.
Refactoring
Restructuring the system by removing duplication, improving
simplifying and adding flexibility.
Pair programming
Two people write the code at one computer.
Collective ownership
Anyone can change any part of the code at any time.
Continuous integrationA new piece of code is integrated into the code-base as soon as
the system is integrated and built many times a day. All tests
have to be passed for the changes in the code to be accepted.
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
27/112
Coding standards
Coding rules exist and are followed by the programmersthrough the code should be emphasized.
Open workspace
A large room with small cubicles is preferred. Pair progra
placed in the center of the space.
Just rules
Team has its own rules that are followed, but can also be cha
The changes have to be agreed upon and their impact has to be
3.1.4. Adoption and experiences
Beck suggests (1999a, p. 77) that XP should be adopted gradua
"If you want to try XP, for goodness sake don't try to sw
at once. Pick the worst problem in your current proce
solving it the XP way."
One of the fundamental ideas of XP is that there is no proce
project as such, but rather practices should be tailored to
individual projects (Beck 1999b). The question is how f
practices and principles can be stretched so that we can still talXP? And just how much can we leave out? In fact, there a
reports in which all the practices of XP have been adopted.
adoption of XP practices, as suggested by Beck, has been re
occasions (Grenning 2001; Schuh 2001)
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
28/112
problem might be solved. The adoption process itself is not
book, but the techniques covered lower the adoption thrconcrete examples of what it is like to actually perform XP.
XP is the most documented one of the different agile me
triggered new research, articles and experience reports on t
practices, such as pair programming (e.g.,Williams et al. 2000;
well as on applying the method itself. Mostly successful Anderson et al. 1998; Schuh 2001) of applying XP have bee
studies provide insight on the possibilities and restrictions of
Martel (2002a) include some concrete numbers regarding the p
from using XP in a web development project. They report an av
66.3% in the new lines of code produced, 302.1% increase in t
methods developed and 282.6% increase in the number
implemented in a development effort. More details of their m
the results obtained can be found in (Maurer and Martel 2002b)
3.1.5. Scope of use
As stated by Beck (1999b), the XP methodology is by n
everywhere, nor have all its limits yet been identified. Th
empirical and experimental research on the subject from diffe
However, some limits have been identified.
XP is aimed for small and medium sized teams. Beck (1999b)
size to be limited between three and a maximum of twenty proj
physical environment is also important in XP. Communication
between project members should be enabled at all times F
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
29/112
1999b). Also technology might provide insuperable obstacles
an XP project. For example, a technology that does not change" or demands a long feedback time is not suitable for XP
3.1.6. Current research
Research on XP is growing. There are many published papers oof XP, but probably due to it being seen more as a practic
academic method, most papers focus on experiences of usin
scopes, and empirical findings on its practices. Some of the
found in, e.g., (Succi and Marchesi 2000).
3.2. Scrum
The first references in the literature to the term 'Scrum' poin
Takeuchi and Nonaka (1986) in which an adaptive, quick
product development process originating from Japan is present
Beedle 2002). The term 'scrum' originally derives from a strate
rugby where it denotes "getting an out-of play ball back int
teamwork (Schwaber and Beedle 2002).
The Scrum approach has been developed for managing the sys
process. It is an empirical approach applying the ideas of control theory to systems development resulting in an approach
the ideas of flexibility, adaptability and productivity (Schw
2002). It does not define any specific software development t
implementation phase Scrum concentrates on how the team
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
30/112
result of the development process, a system is produced whi
delivered (Schwaber 1995).
Scrum helps to improve the existing engineering practices (e.g
in an organization, for it involves frequent management ac
consistently identifying any deficiencies or impediments in
process as well as the practices that are used.
3.2.1. Process
Scrum process includes three phases: pre-game, developmen
(Figure 4).
Priorities Effort estimates
PREGAME
PHASEDEVELOPMENT
PHASE
P
Sprint
backloglist
Planning
High level design/Architecture
Product
backlog
list
Regular
updates
Goals ofnext
Sprint
StandardsConventions
TechnologyResources
Architecture
SPRINT
Requirements
AnalysisDesign
Evolution
TestingDelivery
No more requirements
In
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
31/112
In the following, the Scrum phases are introduced according to
Schwaber and Beedle 2002).
The pre-game phaseincludes two sub-phases: Planning and
level design (Figure 4).
Planning includes the definition of the system being devel
Backlog list (see 3.2.3) is created containing all the requcurrently known. The requirements can originate from th
and marketing division, customer support or software
requirements are prioritized and the effort needed for their
estimated. The product Backlog list is constantly updated w
detailed items, as well as with more accurate estimations
orders. Planning also includes the definition of the projec
other resources, risk assessment and controlling issues, tr
verification management approval. At every iteration, the
Backlog is reviewed by the Scrum Team(s) so as to gain
for the next iteration.
In the architecture phase, the high level design of the sys
architecture is planned based on the current items in the Pr
case of an enhancement to an existing system, the cha
implementing the Backlog items are identified along with
may cause. A design review meeting is held to go over the
implementation and decisions are made on the basis oaddition, preliminary plans for the contents of releases are p
The development phase (also called the game phase) is the
Scrum approach This phase is treated as a "black box" where
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
32/112
In the development phase the system is developed in Sprints
also section 3.2.3). Sprints are iterative cycles where thedeveloped or enhanced to produce new increments. Each Sp
traditional phases of software development: requirements,
evolution and delivery (Figure 4) phases. The architecture and
system evolve during the Sprint development. One Sprint is pl
one week to one month. There may be, for example, three to ei
systems development process before the system is ready for there may be more than one team building the increment.
The post-game phasecontains the closure of the release. Thi
when an agreement has been made that the environmental var
requirements are completed. In this case, no more items and is
nor can any new ones be invented. The system is now ready f
the preparation for this is done during the post-game phase, in
such as the integration, system testing and documentation (Figu
3.2.2. Roles and responsibilities
There are six identifiable roles in Scrum that have different ta
during the process and its practices: Scrum Master, Produ
Team, Customer, User and Management. In the following
presented according to the definitions of Schwaber and Beedle
Scrum Master
Scrum Master is a new management role introduced by Scrum
responsible for ensuring that the project is carried through
practices values and rules of Scrum and that it progresses a
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
33/112
the customer and the management. He makes the final deci
related to product Backlog (see 3.2.3), participates indevelopment effort for Backlog items and turns the issues in
features to be developed.
Scrum Team
Scrum Team is the project team that has the authority to decide
actions and to organize itself in order to achieve the goals ofscrum team is involved, for example, in effort estimation, c
Backlog (see 3.2.3), reviewing the product Backlog list
impediments that need to be removed from the project.
Customer
Customer participates in the tasks related to product Backlogfor the system being developed or enhanced.
Management
Management is in charge of final decision making, along w
standards and conventions to be followed in the project. M
participates in the setting of goals and requirements. F
management is involved in selecting the Product Owner, gau
and reducing the Backlog with Scrum Master.
3.2.3. Practices
Scrum does not require or provide any specific softw
methods/practices to be used. Instead, it requires certain man
and tools in the various phases of Scrum to avoid the
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
34/112
Product Backlog
Product Backlog defines everything that is needed in the finalcurrent knowledge. Thus, Product Backlog defines the work
project. It comprises a prioritized and constantly updated lis
technical requirements for the system being built or enhance
can include, for example, features, functions, bug fixes, d
enhancements and technology upgrades. Also issues requirin
other Backlog items can be done are included in the list. Mparticipate in generating Product Backlog items, such as custo
marketing and sales, management and customer support.
This practice includes the tasks for creating the Product B
controlling it consistently during the process by adding, remo
updating, and prioritizing Product Backlog items. The Presponsible for maintaining the Product Backlog.
Effort estimation
Effort estimation is an iterative process, in which the Backlog
focused on a more accurate level when more information
certain Product Backlog item. The Product Owner together
Team(s) are responsible for performing the effort estimation.
Sprint
Sprint is the procedure of adapting to the changing enviro
(requirements, time, resources, knowledge, technology etc.). organizes itself to produce a new executable product incremen
lasts approximately thirty calendar days. The working tools
Sprint Planning Meetings, Sprint Backlog and Daily Scru
below) The Sprint with its practices and inputs is illustrated in
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
35/112
Daily Sc
Meetin
Sprint
backloglist
Product
backlog
list
Standards
Conventions
Technology
Resources
Architecture
Requirements
Sprint
Planning
Meeting
30 da
SPRINEffortestimation
Figure 5.Practices and Inputs of Sprint.
Sprint Planning meeting
A Sprint Planning Meeting is a two-phase meeting organiz
Master. The customers, users, management, Product Owner participate in the first phase of the meeting to decide upon
functionality of the next Sprint (see Sprint Backlog below). Th
the meeting is held by the Scrum Master and the Scrum Team
the product increment is implemented during the Sprint.
Sprint Backlog
Sprint Backlog is the starting point for each Sprint. It is a list o
items selected to be implemented in the next Sprint. The item
the Scrum Team together with the Scrum Master and the Prod
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
36/112
done since the last meeting and what is to be done before th
problems and other variable matters are discussed and contro(approximately 15 minutes) meeting held daily. Any
impediments in the systems development process or enginee
looked for, identified and removed to improve the process. T
conducts the Scrum meetings. Besides the Scrum team also the
example, can participate in the meeting.
Sprint Review meeting
On the last day of the Sprint, the Scrum Team and the Scrum M
results (i.e. working product increment) of the Sprint to
customers, users and the Product Owner in an informal meeting
assess the product increment and make the decision abo
activities. The review meeting may bring out new Backlogchange the direction of the system being built.
3.2.4. Adoption and experiences
Since Scrum does not require any specific engineering pra
adopted to manage whatever engineering practices are used in
(Schwaber and Beedle 2002). However, Scrum may change th
and customs of the Scrum project team considerably. For exa
manager, i.e. the Scrum Master, does no longer organize the t
organizes itself and makes the decisions concerning what to
called a self organizing team (Schwaber and Beedle 2002). In
Master works to remove the impediments of the process, run
decisions in the Daily Scrums and validates them with the man
is now more that of a coach rather than manager in the project
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
37/112
"demonstrate any piece of user functionality on the sele
(Schwaber and Beedle 2002, p. 59). This will help the team toand the customer to believe in the team. During the Daily S
Sprint, the impediments of the project are identified and re
progress for the team. At the end of the first Sprint, the custo
together with the Scrum Master hold a Sprint Review and toge
to go next. In case of carrying on with the project, a Sprint Pl
held to decide upon the goals and requirements for the followin
In case of adopting Scrum in a new project, Schwaber an
suggest first working with the team and the customer for severa
initial Product Backlog. At this point, the Product Backlog
business functionality and technology requirements. The goal
is then to "demonstrate a key piece of user functionalitytechnology" (Schwaber and Beedle 2002, p. 59). This, natura
designing and building an initial system framework, i.e. a wor
the system to be built, and to which new features can be a
Backlog should include the tasks necessary for reaching the g
As the main issue at this point concerns the adoption of S
Backlog also includes the tasks of setting up the team and
building management practices in addition to the actual tasks
the demo. As the team is working with the Sprint Backlog, th
works with the customer to build a more comprehensive Produ
the next Sprint can be planned after the first Sprint Review is h
Rising and Janof (2000) report successful experiences of usin
software development projects. They suggest that Clearly,
approach for large, complex team structures, but we found
isolated teams on a large project could make use of some el
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
38/112
3.2.5. Scope of use
Scrum is a method suitable for small teams of less than 10 eng
and Beedle suggest for the team to comprise five to nine
(2002). If more people are available, multiple teams should be
3.2.6. Current research
Recently, efforts to integrate XP and Scrum8 together can be
seen to provide the project management framework, which is
XP practices to form an integrated package for software de
Authors claim that this increases xp scalability to larger proje
studies exist that would support their arguments.
3.3. Crystal family of methodolog
The Crystal family of methodologies includes a num
methodologies for selecting the most suitable methodology foproject. Besides the methodologies, the Crystal approach also i
for tailoring the methodologies to fit the varying circumsta
projects.
Each member of the Crystal family is marked with a col
'heaviness' of the methodology, i.e. the darker the colormethodology. Crystal suggests choosing the appropriate colo
for a project based on its size and criticality (Figure 6). Larger
to ask for more coordination and heavier methodologies than
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
39/112
The dimensions of criticality and size are represented by a
symbol described in Figure 6; thus, for example, D6 denotesmaximum of six persons delivering a system of maxim
discretionary money.
C6
Clear
Criticality
of the
system
D20
C20
D80
C80
Yellow Orange Red
L6
E6
L20 L40 L80
D6
E20 E80E40
D40
C40
Figure 6.
Dimensions of Crystal methodologies (Cockbu
There are certain rules, features and values that are common tin the Crystal family. First of all, the projects always
development cycles with a maximum increment length of
preferably between one and three months (Cockburn 2002a). T
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
40/112
There are currently three main Crystal methodologies construc
Crystal Orange and Crystal Orange Web (Cockburn 2002a).these have been experimented in practice and are thus als
discussed in this section.
3.3.1. Process
All of the methodologies of the Crystal family provide gui
standards, work products, "local matters", tools, standards and
to be followed in the development process. Crystal Clear and C
the two Crystal family members that have been constructed an
1998; Cockburn 2002a). Crystal Orange (Cockburn 1998)
activities included in the process. In this subsection, these two discussed by viewing their contexts, similarities and differenc
the process and activities of Crystal Orange.
Crystal Clear is designed for very small projects (D6 project c
comprising up to six developers. However, with som
communication and testing it can be applied also to E8/D10
using Crystal Clear should be located in a shared office-
limitations in its communication structure (Cockburn 2002a).
Crystal Orange is designed for medium-sized projects, with a
project members (D40 category), and with a project duration o
Also E50 category projects may be applicable within Cry
additions to its verification-testing processes. (Cockburn 2
Orange, the project is split up for several teams with cross-func
3 3 2) using the Holistic Diversity strategy (see 3 3 3) Still thi
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
41/112
In the following, the differences and similarities between the
Orange methods are discussed regarding the different elementCrystal family for each of its members. The roles are further
section 3.3.2.
Policy standards
Policy standards are the practices that need to be applied during
process. Both the Crystal Clear as well as Crystal Orange sug
policy standards (Cockburn 2002a):
! Incremental delivery on a regular basis
! Progress tracking by milestones based on software del
decisions rather than written documents
! Direct user involvement
! Automated regression testing of functionality
! Two user viewings per release
! Workshops for product- and methodology-tuning at the
the middle of each increment
The only difference between the policy standards of these twothat Crystal Clear suggests incremental delivery within a tw
time frame whereas in Crystal Orange the increments can be
months at the maximum.
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
42/112
Clear and Orange include the following items: release sequenc
models, user manual, test cases, and migration code.
In addition, Crystal Clear includes annotated use cases/fea
whereas in Crystal Orange the requirements document is req
Clear, the schedule is documented only on user viewings and
comparable work product in Orange that Cockburn lists is (2
indicating a need for more extensive scheduling of the plightweight nature of the work products in Crystal Clear emer
documentation: while Orange demands UI design documen
specifications, in Clear only screen drafts and design sketch
suggested if needed. In addition to these work products, Crysta
status reports.
Local matters
Local matters are the procedures of Crystal that have to be
realization is left up to the project itself. The local matters of
Crystal Orange do not largely differ from each other. Bo
suggest that templates for the work products as well as coding,and user interface standards should be set and maintained b
(Cockburn 2002a). For example, project documentation is r
content and form remains a local matter. Above this, also the
used by the individual roles in the project are not defined by
Crystal Orange.
Tools
The tools that the Crystal Clear methodology requires are com
and configuration-management tool and printing whiteb
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
43/112
performance measuring. In addition, screen drivers are need
GUI tests. (Cockburn 1998).
Standards
Crystal Orange proposes selecting the notation standards, de
formatting standards and quality standards (Cockburn 1998)
project.
Activities
The activities of Crystal Orange are discussed in more detai
However, they are included in the Figure 7 as a part of the i
increment of Crystal process.
ConstructionDemonstration
RequirementsDocument
Policy standards,Standards,
Roles,Local matters,
Tools,
Work products,Activities
Several
IterationsEvery
month
ONE INCREMENT
STAGING
Planning ofnext release
Scheduling
Monitoring ofprogress
Parallelism and
flux
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
44/112
3.3.2. Roles and responsibilities
In this section, the roles of Crystal Clear and Crystal Oran
according to Cockburn (2002a). The basic difference between
Orange is that in the former there is only one team in a p
Orange there are multiple teams to follow though the
methodologies, one job assignment may include multiple roles
In Crystal Clear the main roles requiring separate persons are (
sponsor, senior designer-programmer, designer-programmer
roles embody multiple sub-roles. For example, the des
consists of business class designer, programmer, software doc
tester (Cockburn 1998). The sub-roles that can be assigned
coordinator, business expert and requirements gatherer (Cockbusiness expert represents a business view in the project, poss
about the specific business context. He should be able to
business plan, paying attention to what is stable and what is ch
1998).
In addition to the roles introduced in Crystal Clear, Crystal wide range of main roles needed in the project. The roles
several teams, such as system planning, project mentor
technology, functions, infrastructure and external test teams (
The teams are further divided into cross-functional groups co
roles. (Cockburn 2002a).
Crystal Orange introduces several new roles (Cockburn 1998;
such as UI designer, database designer, usage expert, tec
business analyst/designer architect design mentor reuse p
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
45/112
(Cockburn 1998). The Business analyst-designer communicat
with the users in order to specify the requirements and interfacthe design.
Each group consists of at least a business analyst designer, a U
three designer-programmers, a database designer and possibly
technical facilitators may be needed in a group. The reason
functional groups is to reduce deliverables and to enhance loca(Cockburn 2002a)
3.3.3. Practices
All Crystal methodologies involve a number of practices, sudevelopment. In the description of Crystal Orange (Cock
increment includes activities such as staging, monitoring, revi
parallelism and flux (Figure 7). Also other activities and
identified. These are included in the following descriptions.
Staging
Staging includes the planning of the next increment of the sy
scheduled to produce a working release in every three or four m
1998) at the maximum. A schedule of one to three mo
(Cockburn 2002a). The team selects the requirements to be im
increment and schedules what they feel they are able to d
1998).
Revision and review
Each increment includes several iterations Each iteration inclu
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
46/112
deliver) and stability stages (wildly fluctuating, fluctuating and
review). Monitoring is required in both Crystal Clear and Cryst
Parallelism and flux
Once the monitoring of stability gives the result "stable enou
the deliverables the next task can start. In Crystal Orange, th
multiple teams can proceed with maximum parallelism succe
this, the monitoring and architecture teams review their work psynchronization. (Cockburn 1998)
Holistic diversity strategy
Crystal Orange includes a method called holistic diversity str
large functional teams into cross-functional groups. The centra
include multiple specialties in a single team (Cockburn 1holistic diversity strategy also allows forming small teams w
special know-how, and also considers issues such as loc
communication and documentation and coordination of
(Cockburn 1998)
Methodology-tuning technique
The methodology-tuning technique is one of the basic tech
Clear and Orange. It uses project interviews and team works
out a specific Crystal methodology for each individual p
2002a). One of the central ideas of incremental development is
improving the development process (Cockburn 1998). In eve
project can learn and use the knowledge it has gained for deve
for the next increment.
User viewings
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
47/112
Crystal Clear and Crystal Orange do not define any spec
techniques to be used by the project members in their softwtasks. The adoption of practices from other methodologies
Scrum is allowed in Crystal to replace some of its own p
reflection workshops, for instance.
3.3.4. Adoption and experiences
At least one experience report (Cockburn 1998) can be fo
adopting, evolving and using practices that currently form th
methodology (Cockburn 2002b). The two-year 'project Winifr
sized project with 20 to 40 staff members, with an increme
strategy, an object-oriented approach and a goal of delivering mainframe system.
According to Cockburn (1998) the project Winifred run into pr
increment of the project. Problems with the communication
teams, a long requirements phase that prevented designing an
several months, high turnover of technical leaders and uncleagave rise to the evolvement of software development process
now called Crystal Orange. One solution was the adoption of a
for each increment. This provided the teams with a chance to
weaknesses and to reorganize themselves. Also, the ite
functional viewings with the users for defining the final requir
the users consistently involved in the project. Furthermore, th
on the first increment encouraged those involved to focus on is
job assignments, planning the lines of communication, defin
deliverables and management support
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
48/112
In conclusion, the key success factors of the Winifred
increments enabling the fixing of the process, certain key inorganization of the team into a habit of delivering (Cockburn 1
3.3.5. Scope of use
At present, the Crystal family of methodologies does not projects shown in Figure 6 (Cockburn 2002a). Another restric
Cockburn (2002a) is that only co-located teams can be ad
methodologies.
Cockburn (2002a) has also identified limitations concernin
methodologies used in the Crystal family. For example, Crrelatively restricted communication structure and is thus su
single team located in a single office space. Furthermore, C
system validation elements and is thus not suitable for life
Crystal Orange also requires its teams to be located in a sing
and is capable of delivering only a system maximum of discre
the level of criticality. It also lacks sub-team structures and, afor projects involving up to 40 persons. It is also not very com
design- and code-verification activities and thus not suitab
systems.
3.3.6. Current research
While only two of the four proposed Crystal methodolog
Cockburn9 continues the development of his Crystal family of
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
49/112
3.4. Feature Driven Developmen
Feature Driven Development (FDD) is an agile and adapt
developing systems. The FDD approach does not cover th
development process, but rather focuses on the design and
(Palmer and Felsing 2002). However, it has been designed
other activities of a software development project (Palmer and
does not require any specific process model to be used. Thembodies iterative development with the best practices found
industry. It emphases quality aspects throughout the proc
frequent and tangible deliveries, along with accurate monitorin
of the project.
FDD consists of five sequential processes and provides the meand guidelines needed by the project stakeholders to del
Furthermore, FDD includes the roles, artifacts, goals, and tim
project. (Palmer and Felsing 2002). Unlike some other agi
FDD claims to be suitable for the development of critical sys
Felsing 2002).
FDD was first reported in (Coad et al. 2000). It was then furt
the basis of a work done for a large software development pro
Peter Coad and Stephen Palmer.
3.4.1. Process
As mentioned earlier, FDD consists of five sequential proces
the designing and building of the system is carried out (Figur
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
50/112
Develop
an Overall
Model
Build a
Features
List
Plan byFeature
Design byFeature
Figure 8.
Processes of FDD (Palmer and Felsing 2
In the following, each of the five processes is described acc
(2002).
Develop an Overall Model
When the development of an overall model begins, the dom
3.4.2) are already aware of the scope, context and requirement
be built (Palmer and Felsing 2002). Documented requirements
or functional specifications are likely to exist at this stage. Honot explicitly address the issue of gathering and managing the r
domain experts present a so called "walkthrough" in which t
and the chief architect are informed of the high-level descriptio
The overall domain is further divided into different domain
detailed walkthrough is held for each of them by the domaieach walkthrough, a development team works in small gr
produce object models for the domain area at hand. The devel
discusses and decides upon the appropriate object models for e
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
51/112
domain areas and these function groups consist of so-called m
In addition, the major feature sets are further divided into ferepresent different activities within specific domain areas. T
reviewed by the users and sponsors of the system for t
completeness.
Plan by Feature
Planning by feature includes the creation of a high-level plfeature sets are sequenced according to their priority and
assigned to Chief Programmers (see 3.4.2). Furthermore, the cl
the "developing of an overall model" process are assign
developers, i.e. class owners (see 3.4.2). Also schedule and
may be set for the feature sets.
Design by Feature and Build by Feature
A small group of features is selected from the feature set(s)
needed for developing the selected features are formed by the
design by feature and build by feature processes are iterative p
which the selected features are produced. One iteration should
days to a maximum of two weeks. There can be multiple f3.4.2) concurrently designing and building their own set
iterative process includes such tasks as design inspection, co
integration and code inspection. After a successful iteratio
features are promoted to the main build while the iteration
building begins with a new group of features taken from th
Figure 9).
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
52/112
Group of
Features
Design by
Feature/Build
by Feature
Iteration of 2days - 2 weeks
Design
inspectionDesign
ins
Main build
Feature
Set
Figure 9.The Design by feature and Build by feature proc
3.4.2. Roles and responsibilities
The FDD classifies its roles into three categories: key roles, sup
additional roles (Palmer and Felsing 2002). The six key roles
are: project manager, chief architect, development manager, c
class owner and domain experts. The five supporting roles
manager, language lawyer/language guru, build engineer, tool
d i i t t Th th f th l th t d d i
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
53/112
Project Manager
Project manager is the administrative and financial leader of thhis tasks is to protect the project team from outside distractions
team to work along with providing it with appropriate work
FDD, the project manager has the ultimate say on the scop
staffing of the project.
Chief ArchitectThe chief designer is responsible for the overall design o
running the workshop design sessions held with the team (Pa
2002). The chief architect also makes the final decisions on al
necessary, this role can be divided into the roles of dom
technical architect.
Development Manager
The development manager leads daily development activitie
conflicts that may occur within the team. In addition, this
responsibility of solving resourcing problems. The tasks of
combined with those of the chief architect or project manager.
Chief Programmer
The chief programmer is an experienced developer, who p
requirements analysis and design of the projects. The chie
responsible for leading small teams in the analysis, design an
new features. Selecting features from the feature set(s) to be
next iteration of the "design by feature and build by featur
identifying the classes and class owners that are needed in th
the iteration also belong to the responsibilities of the chief p
with cooperation with other chief programmers in solvin
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
54/112
Domain Expert
The domain expert may be a user, a client, a sponsor, a busmixture of these. His task is to possess the knowledge of h
requirements for the system under development should perform
pass this knowledge to the developers in order to ensure th
deliver a competent system.
Domain ManagerDomain manager leads the domain experts and resolves th
opinion concerning the requirements for the system.
Release Manager
Release manager controls the progress of the process by revie
reports of chief programmers and holding short progress meetinreports the progress to the project manager.
Language Lawyer/Language Guru
A team member responsible for possessing a thorough k
example, a specific programming language or technolog
particularly important when the project team is dealing technology.
Build Engineer
A person responsible for setting up, maintaining and running
including the tasks of managing the version control system
documentation.
Toolsmith
Toolsmith is a role for building small tools for developme
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
55/112
Tester
Testers verify that the system being produced will meet the recustomer. May be an independent team or a part of the project t
Deployer
Deployers work is concerned with converting existing da
required by the new system and participating in the deploymen
May be an independent team or a part of the project team.
Technical Writer
The user documentation is prepared by technical writers, w
independent team or be a part of the project team.
3.4.3. Practices
FDD consists of set of best practices and the developers of
that even though the selected practices are not new, the speci
ingredients make the five FDD processes unique for each
Felsing also advocate that all the practices available should b
most benefit of the method as no single practice dominates t(2002). FDD involves the following practices:
! Domain Object Modeling: Exploration and explanation
the problem. Results in a framework where the features
! Developing by Feature: Developing and tracking the plist of small functionally decomposed and client-valued
! Individual Class (Code) Ownership: Each class has
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
56/112
! Regular Builds: Refers to ensuring that there is a
demonstrable system available. Regular builds formwhich new features are added.
! Configuration Management: Enables the identificati
tracking of the latest versions of each completed source
!
Progress reporting: Progress is reported based on comnecessary organizational levels.
The project team must put all the above practices into use in
with the FDD development rules. However, the team is allow
according to their experience level.
3.4.4. Adoption and experiences
FDD was used for the first time in the development work of a l
banking application project in the late 90s. According to Pa
(2002), FDD is suitable for new projects starting out, projecupgrading existing code, and projects tasked with the crea
version of an existing application. The authors also suggest
should adopt the method gradually in small pieces and finally
the development project proceeds.
3.4.5. Scope of use
The authors further state that FDD is worthy of serious con
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
57/112
3.4.6. Current research
As there are no reliable success stories or, on the other hand,
using FDD, any research, discussions and comparisons of this
utmost interest for academics and practitioners alike, enablin
implement FDD in each specific case, to decide when to use F
other agile method, and when not to use the FDD approac
research still remains to be done. As the method is relativeevolving, and more and more supporting tools will be available
3.5. The Rational Unified Proces
The Rational Unified Process or RUP for short was deveKruchten, Ivar Jacobsen and others at Rational Corporation to c
(Unified Modelling Language), an industry-standard software m
RUP is an iterative approach for object-oriented systems
embraces use cases for modeling requirements and building th
system. RUP is inclined towards object-oriented developmimplicitly rule out other methods, although the proposed m
UML, is particularly suited for OO development (Jacobsen et a
3.5.1. Process
The lifespan of a RUP project is divided into four phases
Elaboration, Construction and Transition (see Figure 10). The
into iterations each having the purpose of producing a demo
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
58/112
Figure 10.
RUP phases.
In the following, the RUP phases are introduced, as descri
2000):
In the inception phase, the life-cycle objectives of the projectthe needs of every stakeholder (e.g. end user, purchaser, o
considered. This entails establishing, e.g., the scope and bou
and acceptance criteria of the project. Critical use cases are ide
that will drive the functionality of the system. Candidate arc
system are devised, and the schedule and cost are estimat
project. In addition, estimates are made for the following elabo
The elaboration phase is where the foundation of software a
The problem domain is analyzed, bearing in mind the entire sy
built. The project plan is defined in this phase if the de
proceed to the next phases at all. In order to be able to make t
assumes that the elaboration phase will yield a sufficiently along with sufficiently stable requirements and plans. The proc
and development environment are described in detail. As RUP
automation the support for it is also established in the elabor
Inception Elaboration Construction
Iteratio
ns
Iteratio
ns
Iteratio
ns
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
59/112
In the construction phase, all remaining components and ap
are developed and integrated into the product, and tested. R
construction phase a manufacturing process, where emphasis is
resources and controlling costs, schedules, and quality. Th
construction phase (alpha, beta, and other test releases) are cre
possible, while still achieving adequate quality. One or more
during the construction phase, before proceeding to the final, tr
The transition phase is entered, when the software product
(determined, for example, by monitoring the rate of system ch
be released to the user community. Based on user response, su
are made to correct any outstanding problems, or to finis
features. The transition phase consists of beta testing, piloting,
and maintainers of the system, and rolling the product odistribution, and sales teams. Several iterations are often ma
general availability releases. User documentation (manuals, c
also produced.
Throughout the phases, nine workflows (Kruchten 2000), ar
parallel. Each iteration, more or less extensively, addresworkflows. The workflows are Business Modelling, Requir
& Design, Implementation, Test, Configuration & Chan
Project Management, and Environment.Most of these are
of them, however, are less commonly seen in other
descriptions, which is why they are described in more detail in
Business Modellingis used for ensuring that the customers b
catered for. By analyzing the customers organization and bus
better understanding of the structures and dynamics of the b
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
60/112
itself, selecting and acquiring required tools, developing
providing software and hardware maintenance, and training.
work in the environment workflow is done during the inception
3.5.2. Roles and responsibilities
The way roles are assigned in RUP is activity driven, so that
each activity. RUP defines thirty roles, called workers. The
conventional (e.g. Architect, Designer, Design Reviewe
Manager), with the exception of the roles defined in the Busin
Environment workflows.
In continuous co-operation with members of the busines
Business-Process Analystleads and coordinates the defining o
cases, which describe the important processes and actors (e.g.,
organization's business. He thus forms a high-level abstractio
that is being modeled, in the form of a business use-case mode
the business object model, which describes how the proc
interact, and creates a glossary listing the important terms used
The business use-case model is split into parts, each of which i
business use case by a Business Designer. While doing so,
documents the roles and entities within the organization.
A Business-Model Reviewer reviews all of the artifacts
Business-Process Analyst and the Business Designer.
The Environment workflow has two interesting roles: a C
d i l ( lid i l l ) f
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
61/112
3.5.3. Practices
The cornerstones of RUP can be listed in six practices that lie b
workflow structure and the roles of RUP. The practices are liste
Table 3.RUP practices (Kruchten 2000).
RUP practice Description
Develop software
iteratively
Software is developed in small increments a
which allows identifying risks and proble
reacting to them adequately.
Manage requirements Identifying the requirements of a software
over time, and those requirements that have ththe project goals is a continuous process. A d
for managing requirements is required, where t
be prioritized, filtered and traced. Inconsist
more easily spotted. Communication has
succeeding when based on clearly defined req
Use component-basedarchitectures
Software architecture can be made more flecomponents those parts of the system tha
change can be isolated and more easily ma
building reusable components can potentiall
amount of future development effort.
Visually model software Models are built, because complex system
understand in their entirety. By using a commethod (such as UML) among the develop
architecture and design can be captured u
communicated to all parties concerned.
3 5 4 Ad ti d i
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
62/112
3.5.4. Adoption and experiences
(Kruchten 2000) claims that RUP can often be adopted, in who
of the box. In many cases, however, a thorough configuration
of RUP, is suggested before implementing it. The config
development case, which lists all deviations that have to be ma
a complete RUP.
The adoption process itself is an iterative six-step program, w
until the new process has been completely implemented whic
plan-do-check-act cycle. Each increment brings in new practi
and adjusts the previously added practices. Based on feedback
cycle, the development case is updated if needed. Piloting the
suitable project is suggested.
Despite the need for extensive tailoring, however, RUP has bee
many organizations. The success of RUP may also be, to some
fact that Rational Software sells popular tools to support the
example, Rational Rose, a UML modeling tool, and Clear
configuration management tool.
3.5.5. Scope of use
RUP is not generally considered particularly agile. The meth
developed to cater for the entire software production procecontains extensive guidelines for process phases that are next
environment that is likely to call for an agile approach. Rece
1998; Smith 2001) have however examined the potential of R
i RUP l th t il i t th ti l hi h i
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
63/112
size. RUP leaves the tailoring to the user entirely, which raises
much of the RUP can be left out, with the resulting process stil
3.5.6. Current research
dX, by Robert Martin, is a minimal version of RUP, in whi
development viewpoints are taken into consideration, stractivities down to their bare essentials (Martin 1998). In orde
malleability of RUP, dX deliberately mimics the principles of X
RUP activities (apart from meaning a small change, dX
down).
Agile modeling (Ambler 2002a) is a new approach (see detailin RUP can be used for Business modeling, defining requirem
and design phases.
3.6. Dynamic Systems Development M
Since its origin in 1994, DSDM, the Dynamic Systems Deve
has gradually become the number one framework for
development (RAD) in the UK (Stapleton 1997). DSDM is a n
proprietary framework for RAD development, maintained
Consortium10. The developers of the method maintain that in a
as a method in the generally accepted sense DSDM also provof controls for RAD, supplemented with guidance on how
those controls.
3 6 1 Process
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
64/112
3.6.1. Process
DSDM consists of five phases: feasibility study, business
model iteration, design and build iteration, and implementation
first two phases are sequential, and done only once. The last th
which the actual development work is done, are iterative
DSDM approaches iterations as timeboxes. A timebox lasts
period of time, and the iteration has to end within the timebox.for each iteration to take is planned beforehand, along wit
iteration is guaranteed to produce. In DSDM, a typical timebox
a few days to a few weeks.
Feasibility
Business study
Agree schedule
Createfunctional
prototyp e
Review prototype
Identifyfunctional
prototyp e
Functional
model
iteration
Identify design prototype
Agreeschedule
Create design prototype
Reviewdesign
prototyp e
Design
and build
iteration
Reviewbu sine ss
Usus
Im
Figure 11.
DSDM process diagram (Stapleton 1997
In the following, the phases are introduced, with their
Optionally a fast prototype can also be made if the business
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
65/112
Optionally, a fast prototype can also be made if the business
not known well enough to be able to decide whether to proceed
or not. The feasibility study phase is not expected to take
weeks.
The business studyis a phase where the essential characteristi
and technology are analyzed. The recommended approac
workshops, where a sufficient number of the customers experbe able to consider all relevant facets of the system, and to b
development priorities. The affected business processes and
described in a Business Area Definition. The identification of
classes helps involving the customer, as the key people i
organization can be recognized and involved at an early
descriptions of the processes are presented in the Business Aresuitable format (ER diagrams, business object models, etc.).
Another two outputs are done in the business study phase.
Architecture Definition, and the other an Outline Protot
architecture definition is the first system architecture sketch, an
change during the course of the DSDM project. The prototystate the prototyping strategy for the following stages,
configuration management.
The functional model iteration phase is the first iterative
phase. In every iteration, the contents and approach for the iter
the iteration gone through, and the results analyzed for furtheanalysis and coding are done; prototypes are built, and the e
from them are used in improving the analysis models. The pro
be entirely discarded but gradually steered towards such qualit
iterations Non-functional requirements are listed mainly to
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
66/112
iterations. Non-functional requirements are listed, mainly to
the next phase. Risk analysis of further developmentis an im
in the functional model iteration phase, because from the next
build iteration) onwards, encountered problems will be more di
The design and build iterationis where the system is mainly
is a Tested System that fulfils at least the minimum agreed se
Design and build are iterative, and the design and functionreviewed by the users, and further development is based on the
The final implementation phase is where the system is tra
development environment into the actual production environ
given to users, and the system handed over to them. If the ro
wide number of users, and done over a period of time, the impmay also be iterated. Apart from the delivered system, th
implementation phase also includes a User Manual, and a
Report. The latter summarizes the outcome of the project,
results, the course of further development is set. DSDM defi
courses of development. If the system fulfils all requirements,
needed. On the other hand, if a substantial amount of requireleft aside (for example, if they were not discovered until th
development), the process may be run through again, from
some less-critical functionality has to be omitted, the process
from the functional model iteration phase onwards. Lastly,
issues can not be addressed due to time constraints, they may
iterating again, starting from the design and build iteration phas
3 6 2 Roles and responsibilities
developer roles cover all development staff, be it ana
7/25/2019 VTT Publications Agile Software Development Methods, Review and Analysis (2002)
67/112
developer roles cover all development staff, be it ana
programmers or testers.
A Technical coordinatordefines the system architecture and
technical quality in the project. He is also responsible for
control, such as the use of software configuration management
Of the user roles, the most important one is the Ambasrespective duties are to bring the knowledge of the user com
p