Introduction to Agile Software Development Methods

Wolfgang Richter
(Technische Universität Graz, Österreich
wrichter@sbox.tugraz.at)

Abstract: Software development methods are a field of research where already a variety of dif-
ferent approaches evolved over the years. Ranging from traditional methods emphasizing the
planning phase and with sequentially ordered phases, over slight variations of them to itera-
tive and adaptive approaches. Each of these methods have been created to minimize risk and to
overcome obstacles encountered in many software development projects. Some of the more tra-
ditional methods are almost obsolete or only applicable under very certain circumstances. Others
have been enhanced and taken as basis for new approaches. A result of an improved traditional
method, the Spiral Model, is the family of Agile Software Development Methods. Agile methods
are iteratively structured and have been developed to react on change rather to predict.
Key Words: Software, Development, eXtreme Programming, Scrum, DSDM, ASD, Crystal Clear,
FDD, Dynamic Systems Development Method, Adaptive Software Development, Feature Driven
Development, Agile Software Development

Table of Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Traditional Software Development Methods in brief . . . . . . . . . . . 3
2.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Shortcomings of Non-Agile Development Methods . . . . . . . . . . . 6
3 Agile Software Development Methods . . . . . . . . . . . . . . . . . . . 7
3.1 The Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Manifesto for Agile Software Development . . . . . . . . . . . . . . . 9
3.3 The Different Approaches . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Dynamic Systems Development Method - DSDM . . . . . . . . . 13
3.3.3 Crystal Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Feature Driven Development (FDD) . . . . . . . . . . . . . . . . 18
3.3.5 Lean Development (LD) . . . . . . . . . . . . . . . . . . . . . . 23
3.3.6 eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . 24
3.3.7 Adaptive Software Development (ASD) . . . . . . . . . . . . . . 28

1
 4 Other Agile Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Agile Database Techniques (AD) . . . . . . . . . . . . . . . . . . . . 30
4.2 Agile Modelling (AM) . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Test-Driven Development (TDD) . . . . . . . . . . . . . . . . . . . . 32
4.4 Pragmatic Programming . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 XBreed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
References (printed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
References (online) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

List of Figures

1 The Waterfall Model, all phases are ordered in a sequence [Als et al. 2003],
©Adrian Als and Charles Greenidge . . . . . . . . . . . . . . . . . . . 4
2 The V-Model, downhill path for development, uphill path for testing
[Goldsmith et al. 2002], ©Robin F. Goldsmith and Dorothy Graham . . 5
3 The Spiral Model, the first iterative approach [Spiral Lifecycle 1998],
©[Spiral Lifecycle 1998] . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 The Sashimi Model [Acidaes Solutions 2004], ©Acidaes Solutions . . . 11
5 The 5 phases in DSDM [Abrahamsson et al. 2002], ©VTT Publications 14
6 The colors of Crystal methods [Abrahamsson et al. 2002], ©VTT Pub-
lications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 The FDD processes [Morrison 2003], ©Kevin Morrison . . . . . . . . . 19
8 The XP Lifecycle [Abrahamsson et al. 2002], ©VTT Publications . . . 27
9 The ASD Lifecycle [Abrahamsson et al. 2002], ©VTT Publications . . 28

List of Tables

1 Project Challenged Factors[Standishgroup 1994] . . . . . . . . . . . . 7

2 FDD-Develop an overall model Tasks [De Luca 2002] . . . . . . . . . 20
3 FDD-Build a feature list Tasks [De Luca 2002] . . . . . . . . . . . . . 21
4 FDD-Plan by feature Tasks [De Luca 2002] . . . . . . . . . . . . . . . 21
5 FDD-Design by feature Tasks [De Luca 2002] . . . . . . . . . . . . . . 22
6 FDD-Build by feature Tasks [De Luca 2002] . . . . . . . . . . . . . . . 22
7 ASD-Characteristics [Abrahamsson et al. 2002] . . . . . . . . . . . . . 29

2
1 Introduction

Software-development in recent years changed from a very often unstructured ’code

and fix’ exercise to a high sophisticated and scientifically comprehensive analyzed dis-
cipline. This change was due to more and more unsuccessful canceled projects or, even
worse, projects ending without a usable result. Statistically seen in 2000 only 28% of
all software-projects were completed successfully [Standishgroup 2000]. To overcome
this high number of unsuccessful and challenged projects various approaches of differ-
ent kinds of software development methods have been created, reaching from traditional
methods to the family of Agile Software Development Methods.

Agile Software Development Methods are a family of methods providing an adap-

tive rather than a predictive approach for developing software systems [Fowler 2003].
Some of them provide a comprehensive recommendation how to manage projects from
the beginning to the end. Others provide recommendations only for parts of the project
lifecycle. All of them are based on well-known methods for developing software like
the ’Waterfall Model’, the ’Spiral Model’, ’Fountain’ and others. Agile methods are an
enhancement to these ideas of structured and organized software-development. All of
them are in some points identic or similar, but not equal. They are all based on the ex-
perience of people working in real-world projects with many obstacles outside of ideal
environments only found in laboratories.

Those obstacles are very often not only technical difficulties, but also social, eco-
nomical, political, psychological challenges. To overcome all of them all Agile Soft-
ware Development Methods are not only providing recommendations of how to write
code, but also of how to identify requirements. Additionaly how to guarantee the ac-
curacy of code, how to set up the roles of people in a project-environment and many
other factors more human- than technic-related. But the main goal remains to complete
a project within its constraints, as they are on-budget, on-time, on-quality and providing
expected features defined during a requirements analysis at the beginning of the project.

2 Traditional Software Development Methods in brief

Many different models and methods have been created for software development and
many of them even more than twenty years old are still in use. Some of them may be
under certain circumstances still appropriate but most of them can easily and should be
replaced by others. The following chapter describes three well-known and still taught
traditional methods in brief.

2.1 Waterfall Model

The Waterfall Model was introduced the first time by Winston Royce in [Royce 1970]
in 1970. Its essence is that software can be developed sequentially, divided into sev-

3
eral phases. First comes the requirements gathering phase, then the design phase, the
development phase and at the end the roll-out of the system. It does not allow devel-
opers to go back to a previous phase, as shown in [Figure 1]. Every phase can only be
accessed from the top of the phase or from its successor. It is not possible e.g. to go
back from the implementation phase directly to the requirements phase. [Royce 1970]
[Als et al. 2003]

Figure 1: The Waterfall Model, all phases are ordered in a sequence [Als et al. 2003],
© Adrian Als and Charles Greenidge

The disadvantage of this sequential approach to software development is that all

4
requirements once defined cannot be changed throughout the rest of the development
lifecycle any more. It requires to have a plan established at the beginning of a project
which is almost impossible to be changed later in the project. It is very inflexible and
should only be used in well-known environments where all definitions and decisions
can be made at the beginning of the project.

2.2 V-Model

The V-Model was defined by Paul Rook in the late 1980s and is an enhanced software
development model directing the focus to the testing phase(s) giving it the same impor-
tance as the other phases. By using the V-Model as basis for a project the developers are
encouraged to create test-cases and link them to another phase. [Goldsmith et al. 2002]

Figure 2: The V-Model, downhill path for development, uphill path for testing
[Goldsmith et al. 2002], © Robin F. Goldsmith and Dorothy Graham

2.3 Spiral Model

The Spiral Model combines the basic ideas of the Waterfall Model and adds a compo-
nent called ’risk-analysis’ to it. The model consists of four phases, the planning phase,
the risk-analysis phase, the engineering phase and the customer evaluation phase. Un-
like in the Waterfall and the V-Model the phases of the Spiral Model are continously
run through in a loop. The Spiral Model was developed for large and complex systems.

5
It provides a chance to make modifications to already existing design or code. The
progress of the project can be measured by looking how far the current phase is from
the middle of a schematic spiral representing the project stages as shown in [Figure 2].
[Goldsmith et al. 2002]

Figure 3: The Spiral Model, the first iterative approach [Spiral Lifecycle 1998], ©
[Spiral Lifecycle 1998]

Many other development methods have been derived from those traditional methods
like ’Sashimi’ from the Waterfall Model, ’X-Model’ and ’W-Model’ from the V-Model,
etc. Agile Software Development Methods are derived from the Spiral Model, which
was the first software lifecycle model emphasizing iterative development.

2.4 Shortcomings of Non-Agile Development Methods

Legacy non-agile development methods, like the Waterfall Model, are sequentially
structured. In 1994 the standish group reported in its Chaos Report that only 16,2%
of all software development projects were successfully completed. Successfully com-
pleted indicates a project was completed on-time, on-budget and providing all features
and functions as initially defined [Standishgroup 1994]. Another 52,7% were reported
as challenged, what was defined as completed over-budget, over the time estimated and

6
offering fewer features or functionality as originally defined. The remaining 31,1% of
the projects were reported as impaired, what means they were cancelled at some point
during the development-cycle. In 1994 not very many software development projects
were setup as agile projects. The leading methods were still those traditional non-agile
methods. [Table 1] shows the result of an evaluation about factors being mostly the
reason for projects becoming challenged projects:

Project Challenged Factors % of Responses

1. Lack of User Input 12.8%
2. Incomplete Requirements and Specifications 12.3%
3. Changing Requirements and Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

Table 1: Project Challenged Factors[Standishgroup 1994]

By looking at point 1, 2 and 3 of [Table 1] it seems to be impossible to develop sys-

tems without permanent communication between the client and the developers. Another
assumption is that it is almost impossible to identify all requirements at the beginning
of a project. Even if they are identified they may change during the project lifecycle.
Reasons for a change may be changes in business requirements or are caused by in-
stable political situations, etc. It is nearly impossible to consider all parameters when
creating an initial project-plan. Changes during the project lifecycle are most-likely un-
preventable.

3 Agile Software Development Methods

Agile methods exist in a variety of occurrences, but all of them are based on the same
idea. Some of them are more focused on producing code, others are providing rec-
ommendations in a broader way. Agile methods are an answer to a lot of difficulties

7
encountered during project lifecycles. They are not the only answer, but they are pro-
viding good solutions for those difficulties. Sometimes they need to be adapted due
to projects existing within constraints not matching the pre-requisites of some of the
methods. For a better understanding of the underlying idea and why it was necessary to
create something like an ’agile’ approach the following chapters provide an overview
of the principles and practices.

3.1 The Principles

In the 1990s several methods emphasizing an iterative approach to software develop-

ment have been created. Over the years they became more and more structured and
popular. All of them are based on the same idea as a result of challenges during a
project lifecycle, but distinguishable in some of the details. They have been adapted to
be applicable in different environments and for projects having different constraints on
their setup. Their basic ideas of how to overcome obstacles in software development
have not been something completely new, but rather a combination of already existing
principles and the modification of some of the proven strategies in software develop-
ment. The result were methods and a methodology emphasizing the four fundamental
principles of Agile Software Development:

– ’Individuals and interactions over processes and tools.’

– ’Working software over comprehensive documentation.’

– ’Customer collaboration over contract negotiation.’

– ’Responding to change over following a plan.’ [Smits 2005]

These four principles make visible that agile methods are suggesting a more respon-
dent to changing environments way of managing projects rather than strictly following
a plan established at the beginning of a project. They may sound like recommending
going away from a well organized management strategy to a chaotic kind of software
development, but in fact under certain circumstances they are much more effective than
the traditional non-agile methods. The lack of already known and planable tasks, which
can be estimated and taken into account for the project-plan and the project-estimates,
can be compensated by having briefer turn-around times if a change in the project en-
vironment or the requirements occurs. Since a software development project is very
often heavily changing in its requirements or in other factors, it is more important to be
able to react on such changes quickly and without long delays. This is the fundamental
principle of Agile Software Development Methods.

Even though from the beginning, when the first ideas about agile development
arised, many different approaches have been created. All of them are similar. They
are building the family of Agile Software Development Methods. The term ’agile’ and

8
the methodology of Agile Software Development were defined in 2001 at a meeting in
Snowbird, Utah/USA. In this meetings several representatives of the different methods
now being called agile came together to find out what might be common among those
methods. They did not try to merge the different methods together, but they wanted to
find a common ground on which in future those methods can be brought together and
improved [Cockburn 2002]. The outcome of this meeting was the ’Manifesto for Agile
Software Development’ [Agile Manifesto 2001].

3.2 Manifesto for Agile Software Development

Before the term ’Agile Software Development’ was created the various methods have
been called ’Lightweight Methods’. At the meeting in Utah in early 2001, where 17
advocates of different lightweight methods came together to dicuss their similarities
and differences, they decided that ’lightweight’ is not sufficient for describing what the
basic idea of those methods was. They agreed on using ’agile’ and ’agility’ as their
umbrella-terms [Cockburn 2002].

The participants were [Cockburn 2002]:

– Kent Beck, Ward Cunningham, Ron Jeffries, James Grenning and Robert Martin
for eXtreme Programming (XP).

– Martin Fowler for XP and methodology evaluation in general.

– Jim Highsmith for Adaptive Software Development (ASD).

– Alistair Cockburn for methodology-per-project and just-in-time methodology con-

struction.

– Jeff Sutherland, Ken Schwaber and Michael Beedle for Scrum.

– John Kern for Feature Driven Development (FDD).

– Arie van Bennekum for Dynamic Systems Development Method (DSDM).

– Andy Hunt and Dave Thomas, authors of ’The Pragmatic Programmer’.

– Brian Marick for everything related to software testing.

– Steven J. Mellor for model-driven development.

The final outcome of the meeting was the ’Manifesto for Agile Software Develop-
ment’:

9
 ’Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping

others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the
left more.’ [Agile Manifesto 2001]

The four principles of agile software development are contained in the manifesto.
Additionaly it states implicitly that improvement is only possible by doing software
development and gaining experience. Additionally it emphasizes that following formal-
ism contained in contracts, written documentation, defined processes and project plans
should not be of higher priority than aiming at the goal of providing a qualitatively well
developed system. Its meaning is that people and people’s peculiarities are being of
more interest. People are writing code to get a project done, people have to deal with
people. If during a project lifecycle communication between the client and the devel-
opers only take place at the beginning and at the end of the project, the system might
never be completed. A change in a requirement can only happen if somebody, a person,
defines it. Permanent interaction between people is one of the key-facts of a successful
software development project.

3.3 The Different Approaches

Currently (June 2005) there are seven methods defined as Agile Software Development
Methods and another four methods related to software development or defined only
for parts of the project lifecycle covered under the umbrella-term ’agile’ [Smits 2005]
[Highsmith 2002]. All of them are based on the idea of using an iterative approach to
resolve difficulties during a project lifecycle. They vary in some of the details.

3.3.1 Scrum

Scrum is not an acronym. The term itself was taken from rugby. A Scrum is a forma-
tion used to restart a game after the ball was out-of-play [Hickok 2002]. Scrum was
initially developed by Ken Schwaber and Jeff Sutherland, later on assisted by Mike
Beedle. All three were co-authors of the ’Manifesto for Agile Software Development’
(see [Chapter 3.2]). Scrum uses 30 days cycles for the iterative development and daily

10
15 minute meetings for coordination and integration. It was defined as a project man-
agement framework rather than a software development method [Highsmith 2002].

Today’s agile method known as Scrum was derived from a method called ’Sashimi’,
which is japanese and means ’slices’. Sashimi is based on the Waterfall Model and was
initially used by Fuji-Xerox® for hardware-development. It refers to the japanese style
of presenting raw fish in overlapping slices. It uses the same phases as described in the
Waterfall Model but instead of having them in a sequential order completely isolated it
suggests to overlap each other succeeding phases as shown in [Figure 4]. In Sashimi it
is possible e.g. to begin with development before design is fully completed. It suggests
personnel continuity between the phases [Acidaes Solutions 2004].

Figure 4: The Sashimi Model [Acidaes Solutions 2004], © Acidaes Solutions

The first occurence of Scrum was in [Takeuchi et al. 1986] written by Hirotaka
Takeuchi and Ikujiro Nonaka in 1986. They introduced the new way of software de-
velopment in Japan. They envisioned based on the Waterfall Model a more idealistic
way of software development, where all phases were overlapping as an enhancement
Sashimi. Scrum is also called an ’all-at-once’-approach of software development, where

11
all team-members play together - like the Scrum in rugby - and all phases are combined
to one [ADM 2005a].

The key-facts of Scrum are [ADM 2005a] [ADM 2005b] [Rising et al. 2000]:

– Using of 30 days or less cycles called ’sprints’.

– Maintaining a so-called ’backlog’ where all foreseeable requirements are stored.

– Maintaining a ’sprint-backlog’ where all well enough defined work doable during
the sprint is stored.

– Daily meetings of 15 minutes where progress and challenges are discussed in brief.

– Team-members are not dedicated to one role but doing ’all-at-once’, meaning they
can be writing code, defining requirements, creating a design, etc. during a sprint.

– The role of the project-manager changes from an authoritarian to a more reporting

and supporting role.

– A flip from ’the team works for the management’ to ’the management works for
the team’.

– Being productive instead of justifying your work by creating various reports.

– Learn as you go.

– Applicable for small teams, not for large teams and complex team-structures.

– Deliver usable, testable pieces of the system incrementally.

– The ’Scrum-Master’ leads the meetings and identifies the initial backlog to be com-
pleted in the sprint.

The Scrum-Master has some kind of authority over the rest of the team, because he
identifies the work to be done and assigns priorities to the tasks. He is also engaged to
keep meetings short and focused, record decisions made and track deliverable backlog-
items to minimize risk [Rising et al. 2000].

At the end of a sprint all project teams meet with the stakeholders. The deliverables
of the last sprint are reviewed together and anything can be changed, from the require-
ments over all decisions to the estimates. If due to some circumstances a new plan and
estimate have to be created the whole team together with the stakeholders goes back
to the point before the already delivered piece of the system was defined. Scrum em-
phasizes the visibility of planning and development to everybody involved in a project
[Rising et al. 2000].

12
3.3.2 Dynamic Systems Development Method - DSDM

DSDM was developed in Great Britain by a consortium of UK-based companies in

the 1990s. DSDM arised from Rapid Application Development (RAD) and provides a
framework of controls and best practices for RAD. Like all other agile methods DSDM
is emphasizing iterative and incremental development [Stapleton 1995]. The basic idea
of DSDM is rather to fix time and resources and then adjust the initially defined func-
tionality than to fix the amount of functionality and afterwards adjusting time and re-
sources [Abrahamsson et al. 2002].

RAD had a certain disadvantage, it grew unstructured and many different vendors
and consulters came up with their own interpretation of RAD. For each client the
method was adapted. Out of this recognition DSDM was created to provide a framework
for RAD. Originally DSDM was founded by 16 members of the DSDM consortium.
They first met in January 1994 and in March 1994 they provided the first set of basic
concepts for DSDM which remained unchanged since then. [DSDM Consortium 2005a]

The underlying principles of DSDM are:

– ’Active user involvement is imperative.’

– ’The team must be empowered to make decisions.’

– ’The focus is on frequent delivery of products.’

– ’Fitness for business purpose is the essential criterion for acceptance of

deliverables.’

– ’Iterative and incremental development is necessary to converge on an

accurate business solution.’

– ’All changes during development are reversible.’

– ’Requirements are baselined at a high level.’

– ’Testing is integrated throughout the life-cycle.’

– ’Collaboration and cooperation between all stakeholders is essential .’

[DSDM Consortium 2005b]

DSDM defines five phases: Feasibility study, business study, functional model iter-
ation, design and build iteration, implementation. [Figure 5] shows how the five phases
are interacting and the information flow between the phases.
The first two phases, the feasibility study and the business study are only executed
once prior to the beginning of a project. In terms of project management these phases
are part of the product lifecycle but not part of the project lifecycle. The feasibility

13
 Figure 5: The 5 phases in DSDM [Abrahamsson et al. 2002], © VTT Publications

study is used to determine if DSDM is suitable for the project under the given con-
straints as they are company structure, resources, technical factors and the risk related
to those. The output of the feasibility study is a feasibility report and an outline-plan for
the development. Optional a rapid prototype can be developed if the technology is too
uncertain to be evaluated without an empirical basis. [Abrahamsson et al. 2002]

The business study is used to determine the requirements for the system from a
business perspective and from a high-level technical perspective as well. This phase
emphasizes holding of workshops together with key-players and domain-experts of the
client to create ’Business Areas’ and ’Business Area Definitions’. At a high level the
Business Area Definitions can contain technical designs like ER1 -diagrams, business
object models, process descriptions, workflows, etc. This phase is very important to
identify the major areas of interest for further design and to recognize the people who
are holding the required knowledge. [Abrahamsson et al. 2002]

The functional model iteration phase is the first iterative and incremental phase. In
this phase and its iterations prototypes and analysis models are the output of each itera-
1
ER ... Entity Relationship

14
tion. Prototypes are supposed to build the basis for the next iteration and the growth of
a prototype should be incremental from iteration to iteration, unless it is not satisfying
the requirements defined and revised in the analysis model. The output of this phase is a
functional, testable model. Testing is done continuously. Additionaly to the prototypes
and the analysis models there are four more outputs considered to be created in this
phase: A list of prioritized functions, functional prototyping review documents contain-
ing the comments of the client, a list of non-functional requirements to be considered in
the next phase and a risk analysis of further development. [Abrahamsson et al. 2002]

The design and build iteration is the phase where the system itself is mainly built
in iterations. [Abrahamsson et al. 2002]

The implementation phase is the phase where the roll-out of the system takes place.
The system is transferred from the development environment to the production environ-
ment. Trainings for the users are held, a manual and a project review report are provided.
Depending on the result of the report DSDM considers four possible courses for further
development: No further development, if the system fullfilles all requirements, con-
tinuing the development as done prior to the roll-out if an unneglectable number of
requirements have been left aside due to some unforeseeable circumstances during the
development lifecycle, a smaller iterative on-going development if less-critical func-
tions have been omitted and finally also a smaller iterative development continuing to
finalize due to time-constraints omitted requirements. [Abrahamsson et al. 2002]

3.3.3 Crystal Methods

The Crystal family of methods comprises several different methods for so-called ’Just-
in-Time’-development, all marked with a color indicating the ’heaviness’ of the method.
The darker the color, the heavier the method. The author was Alistair Cockburn. Only
three of them have been used so far2 in live-projects. They are namely Crystal Clear,
Crystal Orange and Crystal Orange Web. Which Crystal method to use depends on
the size and the criticality of the project. The larger a project is the more coordina-
tion is necessary and the darker is the color of the method to use [Cockburn 2002]
[Abrahamsson et al. 2002]. The main idea of Crystal is to have an appropriate method
for each project. Cockburn describes the two different approaches for method-per-
project:

1. ’Create a kit of methodology parts that the project team assembles for its
project.’

2. ’Create a copy-and-alter family of specific methodologies that can be tai-

lored on each project.’ [Cockburn 2002]
2
Status May, 2005

15
 The kit approach was used by the Rational Corporation in the first version of the
’Rational Unified Process (RUP)’. For Crystal methods Alistair Cockburn, supported
by Jim Highsmith uses the tailoring approach. They are collecting sets of concrete and
sample agile methods of successfully completed projects to provide a starting-point
for new projects. They called the family of methods ’Crystal’ because it provides a
metaphor that supports the first two degrees of the grid in [Figure 6]. [Cockburn 2002]

Figure 6: The colors of Crystal methods [Abrahamsson et al. 2002], © VTT Publica-
tions

Moving to the right in the grid means to have more people involved in the project
and more effort for coordination. Moving up in the grid corresponds to more poten-
tial damage from the system. According to the mineral hardness scale this defines the
project as ’harder’. The harder a project is, the more critical is the output and the needed
accuracy of the system. The grid continues to the right with Magenta, Blue, and so on.
[Cockburn 2002]

16
 The character symbols in [Figure 6] indicate a potential loss by a system failure.
’C’ stands for ’Comfort’, ’D’ for ’Discretionary money’, ’E’ for ’Essential money’ and
’L’ for ’Life’. The L boxes are dotted because at the time of creation of this paper no
life-critical project has been executed using a Crystal method so far. [Cockburn 2002]
[Abrahamsson et al. 2002]

A restriction to Crystal methods is that they only address colocated teams. For dis-
tributed and offshore development projects Crystal methods are not applicable. An-
other restriction is that they are not upward or downward compatible. If a project e.g.
grows from a four person project to a twenty person project it needs to be re-organized
to fit into the Crystal family of methods rather than continued with the initial setup.
[Cockburn 2002]

Members of the Crystal family share:

– ’Values and principles.’

– ’On-the-fly tuning.’ [Cockburn 2002]

Two values are Crystal methods intrinsic:

– ’People- and communication-centric.’

– ’Highly tolerant.’ [Cockburn 2002]

Crystal Clear is applicable for non-critical systems. The team is supposed to be lo-
cated in one office or at least in adjoining offices. Roles defined are a sponsor, a senior
designer-programmer, designer-programmers and users. One of them acts as a coordi-
nator. Software is developed and delivered incrementally (every two to three months),
the project is tracked by milestones, testing is done automatically for parts of the sys-
tem, direct user involvement is mandatory, two user viewings per release, workshops
for product- and methodology-tuning are held at the start and the middle of each incre-
ment. Crystal Clear does require project documentation to be created. Other outputs are
a release sequence, use cases, test cases, running code, migration code, an user manual
and drafts for screens, designs, etc., including notes. [Cockburn 2002]

Crystal Orange is a method applicable for D40 projects - up to fourty people sit-
ting in the same building. Main characteristics of such a project are ten to fourty people,
one to two years in duration, a need to keep time and costs down and time to market
is important. The roles defined are a sponsor, business expert, usage expert, technical
facilitator, business analyst/designer, project manager, architect, design mentor, lead
designer-programmer, other designer-programmers, User Interface (UI) designer, reuse
point, writer and tester. They are arranged in several teams. The outputs are a require-
ments document, a release sequence, a schedule, status reports, a UI design document,

17
a common object model, inter-team specifications, an user manual, source code, test
cases and migration code. [Cockburn 2002]

Crystal Orange Web differs from Crystal Orange that not a single project has to be
completed, but it provides a continual stream of initiatives which have to be merged
with the existing code-base. Its main characteristics are development-cycles of two
weeks, post-cycle workshops to review the work done, no concurrent development,
use cases, business cases, establishing of a SWAT3 team for bugfixing. Others are still
to be derived from ongoing projects since Crystal Orange Web is still in a trial state4 .
[Cockburn 2002]

3.3.4 Feature Driven Development (FDD)

FDD was created by Jeff Luca, Peter Coad and supportingly by Stephen Palmer begin-
ning in 2000. FDD does not cover the entire development process but emphasizes on
the design and building phases. FDD has been designed to work together with other
software development activites considered as best practices taken from projects. It em-
phasizes frequent deliveries, progress montoring and focussing on quality aspects. FDD
does not require a process model. [Abrahamsson et al. 2002]

In opposite to other agile methods FDD claims to be suitable for critical systems.
FDD defines five different sequential processes, as shown in [Figure 7]. Additionaly
FDD defines roles, guidelines, timelines, artifacts goals and techniques necessary for
stakeholders to deliver a system. [Abrahamsson et al. 2002]

3
SWAT ... Special Weapons and Tactics, often used to describe specialized teams
4
Status, May 2005

18
 19

Figure 7: The FDD processes [Morrison 2003], © Kevin Morrison

 Like all other agile methods FDD uses iterations, typically one to three weeks for a
feature. The five processes in FDD are ’Develop an overall model’, ’Build a feature list’,
’Plan by feature’, ’Design by feature’, ’Build by feature’. For each are specific roles, en-
try criterias, tasks and exit criterias defined. [De Luca 2002] [Abrahamsson et al. 2002]

In develop an overall model the entry criteria is that domain experts, chief pro-
grammers and the chief architect have been selected. The exit criteria is the result of the
process in form of an object model which contains class diagrams focusing on model
shape. Focusing on model shape means what classes are in the domain, how are they
connected to one another and under what constraints, methods and attributes identified
are placed in the classes. Additionaly sequence diagram(s), if any, model notes to cap-
ture why a particular model shape was chosen and/or what alternatives were considered.
The terms can be replaced depending on the programming-language and environment
used [De Luca 2002]. The required tasks are shown in [Table 2].

Task Team-Member(s)
Form the Modelling Team Project Manager
Domain Walk-through Modelling Team
Study Documents Modelling Team
Develop the Model Modelling Team in Small Groups
Refine the Overall Object Model Chief Architect, Modelling Team
Refine the Overall Object Model Chief Architect, Modelling Team

Table 2: FDD-Develop an overall model Tasks [De Luca 2002]

In build a feature list the entry criteria is that domain experts, chief programmers
and the chief architect have been selected. The exit critera is the result of the process
in form of a feature list, which contains a list of subject areas. For each subject area a
list of business activities needs to be included and within that subject area and for each
business activity step the feature to satisfy the step. The required tasks are shown in
[Table 3].

In plan by feature the entry criteria is that the building of a feature list, the exit
criteria of the predecessor process, was completed. The exit criteria is a development
plan containing business activities with completion dates (month and year). Resources
like chief programmers assigned to business activities, subject areas with completion
dates (month and year) derived from the last completion date of their respective busi-
ness activities and the list of classes and the developers that own them (the class owner

20
 Task Team-Member(s)
Form the Features List Team Project Manger, Development Man-
ager
Build Features List Features List Team
Internal and External Assessment Features List Team, Business

Table 3: FDD-Build a feature list Tasks [De Luca 2002]

list) need to be included. The last exit criteria can be altered if there are no classes to
be developed or rather objects, procedures, functions, etc. are the main interest depend-
ing on the programming-language and environment used [De Luca 2002]. The required
tasks are shown in [Table 4].

Task Team-Member(s)
Form the Planning Team Project Manger, Development Man-
ager
Determine the Development Se- Planning Team
quence
Assign Business Activities to Chief Planning Team
Programmers
Self Assessment Planning Team

Table 4: FDD-Plan by feature Tasks [De Luca 2002]

In design by feature the entry criteria is that the planning process was completed.
The exit criteria is the result of the process in form of a successfully inspected design
package. The design package contains a covering memo, or paper, that integrates and
describes the design package such that it stands on its own for reviewers. Additionaly
the referenced requirements, if any, in form of documents and all related confirma-
tion memos and supporting documentation need to included as well as the sequence
diagram(s). This implicitly requires design alternatives, if any, the object model with
new/updated classes, methods and attributes, the tool5 -generated output for the classes
and methods prologues created or modified by this design and the calendar/to-do task-
list entries for action items on affected classes for each team member [De Luca 2002].
The required tasks are shown in [Table 5].
5
which tool to use depends on the environment

21
 Task Team-Member(s)
Form Feature Team Chief Programmer
Domain Walk-through Domain Expert
Study the Referenced Documents Feature Team
Develop the Sequence Diagram(s) Planning Team
Refine the Object Model Chief Programmer
Write Class and Method Prologues Feature Team
Design Inspection Feature Team

Table 5: FDD-Design by feature Tasks [De Luca 2002]

In build by feature the entry criteria is that the design by feature process was com-
pleted. That is, the design package has successfully been inspected. The exit criteria is
the result of the process in form of class(es) and/or method(s) that have been success-
fully code inspected, class(es) that have been promoted to the build and the completion
of a client-valued function (feature) [De Luca 2002]. The required tasks are shown in
[Table 6].

Task Team-Member(s)
Implement Classes and Methods Feature Team
Code Inspection Feature Team
Unit Test Feature Team
Promote to the Build Chief Programmer, Feature Team
Code Inspection and Unit Test Chief Programmer, Feature Team

Table 6: FDD-Build by feature Tasks [De Luca 2002]

FDD is still hard to value since there are only a few success stories available and
its use was limited to a very small amount of projects. The first time the basic concept of
FDD was used was in a banking application project in the late 1990s [Abrahamsson et al. 2002].
Since then only a few applications have been built using FDD, but even among those
the number of available reports is very low.

22
3.3.5 Lean Development (LD)

LD6 was derived from Lean Production. Lean Production was the restructuring of the
japanese automobile manufacturing industry in the 1980s. LD was created by Bob
Charette as an extension of traditional methodology’s view of change from a risk of
loss to a view of change as producing opportunities to be pursued. [Highsmith 2002]
LD was also inspired by ’Total Quality Management (TQM)’ taught and empha-
sized by W. Edward Deming. The principle of TQM is to empower workers to inves-
tigate problems and based on their insights to constantly improve business processes
and stressing teamwork. It emphasizes a continuous improvement of processes and the
product itself. LD is more a way of thinking than a comprehensively specified method.
[Poppendieck 2001]

The ideas of Lean production together with TQM constitute the practices of LD:

– ’Eliminate waste.’

– ’Minimize inventory.’

– ’Maximize flow.’

– ’Pull from demand.’

– ’Meet customer requirements.’

– ’Do it right the first time.’

– ’Empower workers.’

– ’Ban local optimization.’

– ’Partner with suppliers.’

– ’Create a culture of continuous improvement.’ [Poppendieck 2001]

The term ’lean’ describes best what the ideas behind the practices are. Only do what
needs to be done and what will be valued. Do not do it when it cannot be done in quality
[Poppendieck 2001].

In detail eliminate waste means find the most efficient way to produce the same
value. Minimize inventory is a way of describing to only produce documentation
of any kind if it is really needed for the product. This includes manuals, reports, de-
sign documents, requirement documents, etc. If a document is only needed to satisfy
a manager or another stakeholder, just do not do it. Maximize flow reflects the main
6
Also found in literature as Lean Software Development (LSD)

23
idea of agile development, to produce only small pieces iteratively to reduce work-
in-progress and improve the ’flow’ of your work. All agile methods are using this
practice to speed-up the development itself and to produce visible and tangible results.
[Poppendieck 2001]

Pull from demand means not to potentially plan everything from the beginning to
the end, but rather to react on change when it happens. Iterative and incremental devel-
opment is the application of this practice. Meet customer requirements is probably
the most critical rule. If in a project the requirements are constituted at the beginning of
the project and the client needs to sign-off it will take a lot of time to get them done. The
better way is, if a system can evolve over time. The client needs to be involved in the
design and development, which reflects another basic principle of agile development.
[Poppendieck 2001]

Do it right the first time emphasizes permanent testing througout the whole devel-
opment lifecycle. In early stages of design and development the costs for finding and
fixing a bug are significantly lower than later or after delivery. This rule needs to be read
as ’to be able to react on changes, but do it right as far as you know’ instead of ’once it is
done, it is done’. Otherwise this rule would violate one of the principles of agile devel-
opment. Empower workers implies to give people more responsibility. If a worker is
supposed to evaluate his own performance and his co-workers are supposed to help im-
proving processes together, the result will be more sufficient than having experts from
outside the team analyzing the grievances. It emphasizes team-work, collaboration of
team-members and decision-making where the actual work happens instead of guidance
by others. Ban local optimization is a description of ’scope will take care of itself’. If
the focus is on local optimization and limiting the project to its original scope it will
impair the system’s quality. The rule suggests to concentrate on time and feedback and
decide together with the client what the result of a cycle and of the final release will be.
[Poppendieck 2001]

Partner with suppliers recommends to consider the ideas of Supply Chain Man-
agement. The basic ideas are that to minimize paperwork it is mandatory to create a
trust-relationship to suppliers to improve company-to-company (B2B7 ) trades. Create
a culture of continuous improvement recommends to analyze established processes
frequently and alter them according to modified needs. [Poppendieck 2001]

3.3.6 eXtreme Programming (XP)

XP is the most analyzed, evaluated and described agile method in software develop-
ment. For none of the others such a variety of case-studies and reports are available. XP
was initially created by Kent Beck and later improved by Ward Cunningham and Ron
7
B2B ... Business to business

24
Jeffries. XP has four core values as they are communication, simplicity, feedback and
courage [Beck 2000].

Communication is very often a reason for a project to become challenged or to be

cancelled. XP aims at having a steady flow of communication in using many practices
requiring a lot of communication. Simplicity requires discipline of the people in the
project. It is often easier to think two months ahead and to see the whole picture and
all its complex structures than breaking the work down into simple pieces. Feedback
emphasizes cooperation between the different teams and the client as well. Feedback
can be gathered from different kinds of tests, from training-sessions, etc. It is important
to collect the feedback and react on it in an appropriate manner. Courage requires
people in a team to report everything without hiding information. If a code needs to
be dropped or refactored it is mandatory to do it if there is no other way. If the error
remains hidden and needs to be fixed in later state or after the roll-out, the costs for it are
significantly higher and can cause serious damage to the project. This is an important
value since due to very restricive company-structures or hierarchies within the company
people rather try to mask errors than to uncover them and move forward to a solution.
[Beck 2000]

Beside its values XP emphasizes and describes core practices as they are:

– ’Whole Team.’

– ’Planning Game.’

– ’Customer Tests.’

– ’Small Releases.’

– ’Simple Design.’

– ’Do it right the first time.’

– ’Pair Programming.’

– ’Test-Driven Development.’

– ’Design Improvement.’

– ’Continuous Integration.’

– ’Collective Code Ownership.’

– ’Coding Standard.’

– ’Metaphor.’

– ’Sustainable Pace.’ [Jeffries 2001]

25
 Whole Team means that all team-members including a representative of the client
are sitting and working together to get the work done. The client representative steers
the project by making decisions and assigning priorities to tasks. Planning Game is
a synonym for prediciting what can be established by the due date and determining
what can be done next. The client representative decides based on the estimates of the
other team-members what is of most value and will be scheduled for the next iteration.
Customer Tests emphasizes building of automated tests, built by the client represen-
tative and developed and used by the developers to proof themselves. Small Releases
give the client the opportunity to get a look-and-feel of the end-result and/or react on
design-mistakes immediately. After every iteration the team is supposed to provide a
new release. [Jeffries 2001] [Beck 2000]

Simple Design suggests to incrementally build the system in manageable pieces.

The design can be enhanced or improved step-by-step in iterations to finally result in
the requested system. Pair Programming defines a practice, where two developers are
sitting, designing and developing side-by-side. It is important to consider social and
private factors when creating pairs. If a developer has private resentments against his
partner it is obvious that the performance of the pair will be impacted and lower than
having a pair of people who like each other [Lippert et al. 2002]. Pair Programming pro-
vides some advantages like implicit training for less-experienced developers, backups
for all developers, etc. Test-Driven Development requires for every piece of code and
its required functionality a test to be written and, more important, to be ran. Design Im-
provement means some kind of refactoring process focused on removal of duplication
and on increasing the ’cohesion’ of the code. [Jeffries 2001] [Beck 2000]

Continuous Integration suggests more than one build a day to keep the system
fully integrated all the time. Collective Code Ownership is a practice where every
pair can improve any code at any time. Coding Standard recommends guidelines for
the implementation and the code-structure to give the impression that the whole code
was written by a single person. Metaphor stands for ’a common vision of how the
code works’. Sustainable Pace recommends to allow people to work at an acceptable
speed and pressure and to minimize overtime or only request overtime if it is effective.
[Jeffries 2001] [Beck 2000]

The XP lifecycle, as shown in [Figure 8], consists of five phases: The ’exploration
phase’, the ’planning phase’, the ’iterations to release phase’, the ’productionizing
phase’, the ’maintenance phase’ and the ’death phase’. In the exploration phase the
story cards, which describe functionality, for the first release are written by the client.
The team familiarizes itself with tools, techniques, environments, etc. A first prototype
will be built to see if something needs to be changed or everything is working as ex-
pected. In the planning phase the priorities for the stories written on the story cards
are assigned. Effort estimations by the developers are discussed and agreed upon, if

26
appropriate. The iterations to release phase consists of several iterations where agreed
upon tasks are processed and pieces of the system are developed. The productioniz-
ing phase requires extra testing and analysis of the performance before the system will
be released to the client. The maintenance phase mainly focuses on keeping the pro-
ductionized system up and running and on identifying tasks for further iterations. The
death phase is reached when the system satisfies the client’s needs in any matter and no
more stories need to be implemented. In this phase the final documentation is written.
[Abrahamsson et al. 2002]

Figure 8: The XP Lifecycle [Abrahamsson et al. 2002], © VTT Publications

27
3.3.7 Adaptive Software Development (ASD)
ASD8 was developed by Jim Highsmith and published for the first time in 2000. ASD
is a successor of Rapid Application Development (RAD) which was developed by Jim
Highsmith and Sam Bayer. ASD counts on having adaptable practices and adaptive
teams to be able to react on change in turbulent environments. The practices of ASD
are driven by a believe in continuous adaption. The static plan-design-build lifecy-
cle of other methods is replaced by a dynamic speculate-collaborate-learn lifecycle.
It is oriented to change, dedicated to continuous learning, re-evaluation, peering into
an uncertain future and intense collaboration between developers, managers and the
customer. ASD focuses mainly on the issues in developing large, complex systems.
[Highsmith 2002a]

Figure 9: The ASD Lifecycle [Abrahamsson et al. 2002], © VTT Publications

Speculation , the first concept of ASD, encourages short delivery iterations and
gives room to explore and, if necessary, to deviate from established plans. It does not
abandon planning, but it acknowledges the uncertainty of planning. The second concept
of ASD, collaboration is based on the idea of systems are rather evolving than being
built and that a large volume of information needs to be analyzed, processed and stored
as well as communicated. This is more information than a single individual can hold.
Collaboration between all participants of a project and a steady information flow is a
fundamental concept of ASD. Learning is the third concept of ASD. It emphasizes
frequent reviews and constant testing of existing knowledge. The three concepts are the
8
ASD can also be found as ADP

28
basis for the six fundamental characteristics of ASD: Mission focused, feature based,
iterative, time boxed, risk driven and change tolerant. The ASD lifecycle focuses on
results rather than on tasks, since tasks can be cancelled or changed to provide a result.
This implies to be focused on quality rather than on dead-lines [Highsmith 2002a]. In
[Table 7] the characteristics of ASD are described more in detail.

Characteristic Description
Mission-Driven The activities in each development cycle must be justified
against the overall project mission. The mission may be ad-
justed, as the development proceeds.
Component-Based Development activities should not be task-oriented, but rather
focus on developing software, i.e. building the system a small
piece at a time.
Iterative A serial waterfall method works only in well-understood and
well-defied environments. Most development is turbulent, and
the development effort should therefore be focused on ’redo-
ing’ instead of ’doing it right the first time’.
Time-Boxed Ambiguity in complex software projects can be alleviated by
fixing tangible deadlines on a regular basis. Time-boxed project
management forces the project participants to make the in-
evitable, hard trade-off decisions early in the project.
Change-Tolerant Changes are frequent in software development. Therefore, it is
more important to be able to adapt to them, than it is to control
them. To build a change-tolerant system, the developers must
constantly evaluate whether the components they are building
are likeliy to change.
Risk-Driven The development of high-risk items (e.g., least well known, or
most critical if changed) should begin as early as possible.

Table 7: ASD-Characteristics [Abrahamsson et al. 2002]

Roles in ASD are only vaguely defined. It only gives a description of the roles in
JAD9 -sessions which are a part of the overall ASD concept and especially of collabora-
tion. [Abrahamsson et al. 2002] [Highsmith 2002a]

9
JAD ... Joint Application Development

29
4 Other Agile Methods

Besides the Agile Software Development Methods there are four agile or agile related
methods defined, based on or fitting in the principles of agile software development.
They have been created for either parts of the development lifecycle or are focusing on
specific technical areas.

4.1 Agile Database Techniques (AD)

AD10 was developed by Scott W. Ambler and is a collection of principles and philoso-
phies taken from other agile methods or based on experience gathered throughout soft-
ware development projects [Ambler 2004]. The philosophies of AD in detail are:

– ’Data. Data is one of several important aspects of software-based systems.’

– ’Enterprise issues. Development teams must consider and act appropriately

regarding enterprise issues.’

– ’Enterprise Groups. Enterprise groups exist to nurture enterprise assets and

to support other groups, such as development teams, within your organi-
zation. These enterprise groups should act in an agile manner that reflects
the expectations of their customers and the ways in which their customers
work.’

– ’Unique situation. Each development project is unique, requiring a flexible

approach tailored to its needs. One software process does not fit all and
therefore the relative importance of data varies based on the nature of the
problem being addressed.’

– ’Work together. IT professionals must work together effectively, actively

striving to overcome the challenges that make it difficult to do so.’

– ’Sweet spot. You should actively strive to find the sweet spot for any issue,
avoiding the black and white extremes to find the gray that works best for
your overall situation.’ [Ambler 2004]

AD describes roles and processes for different kind of projects. It is based on the
concept of adapting processes according to the nature of a project, i.e. different results
require different steps. E.g. a database design requires different techniques and tools
than an application design. Regarding people AD states that different people have dif-
ferent kinds of expertise and therefore it is necessary to treat individuals as individuals.
[Ambler 2004]

10
Agile Database Technique is also called Agile Data Method

30
4.2 Agile Modelling (AM)

AM is closely related to AD and was also created by Scott W. Ambler. AM defines a list
of core and supplementary principles which are based on several other agile methods.
Four of the core principles are the same as in XP and therefore AM faces the same
issues as XP [Abrahamsson et al. 2002]. The following list shows the core principles of
AM:

– ’Assume Simplicity.’

– ’Embrace Change.’

– ’Enabling the Next Effort is Your Secondary Goal.’

– ’Incremental Change.’

– ’Model With a Purpose.’

– ’Multiple Models.’

– ’Maximize Stakeholder Investment.’

– ’Quality Work.’

– ’Rapid Feedback.’

– ’Software Is Your Primary Goal.’

– ’Travel Light.’ [Ambler 2004]

The supplementary principles of AM are:

– ’Content is More Important Than Representation.’

– ’Everyone Can Learn From Everyone Else.’

– ’Know Your Models.’

– ’Know Your Tools.’

– ’Local Adaptation.’

– ’Open and Honest Communication.’

– ’Work With People’s Instincts.’ [Ambler 2004]

31
4.3 Test-Driven Development (TDD)

TDD has been developed in 2002. It emphasizes writing tests before writing code. It
emphasizes also developing only very small chunks of functionality and test it right
away. Writing tests, writing code and testing code are following each other in cycles
measured in minutes. Tests during development in TDD are always automated tests,
what makes the big difference to many testing-processes. TDD is an essential part of
XP, but can be used stand-alone or together with other agile methods as well. TDD is
not only a framework for testing, it is a development method, but focused on testing.
[Testdriven.com 2005]

The steps, the rules and the benfits of TDD are:

– The Steps
• ’Write a test that specifies a tiny bit of functionality.’

• ’Ensure the test fails (you haven’t built the functionality yet!).’

• ’Write only the code necessary to make the test pass.’

• ’Refactor the code, ensuring that it has the simplest design possible for
the functionality built to date.’ [Object Mentor 2005]

– The Rules
• ’Test everything that can possibly break.’

• ’Tests come first.’

• ’All tests run at 100% all the time.’ [Object Mentor 2005]

– The Benefits
• ’Code is written so that modules are testable in isolation. Code written
without tests in mind is often highly coupled, a big hint that you have
a poor object-oriented design. If you have to write tests first, you’ll
devise ways of minimizing dependencies in your system in order to
write your tests.’

• ’The tests act as system-level documentation. They are the first client
of your classes; they show how the developer intended for the class to
be used.’

• ’The system has automated tests by definition. As your system grows,

running full regression tests manually will ultimately take outrageous
amounts of time.’

32
 • ’Development is paced. We specify tiny bits of functionality in our
tests, then write a small amount of code to fulfill that specification.
Rinse, repeat. Tiny means seconds to a few minutes.’

• ’The code base progresses forward at a relatively constant rate in terms

of the functionality supported.’ [Object Mentor 2005]

4.4 Pragmatic Programming

Pragmatic Programming is a set of programming practices instead of a method. Prag-

matic Programming does not define a process, phases, distinct roles or work products.
Instead of creating a method, it covers development practicalities. Pragmatic Program-
ming gives recommendations for a variety of concerned areas regarding technical and
social subtleties possibly occuring during a software development project. Similar to
principles of agile methods it emphasizes communication, providing solutions rather
than excuses, fixing of bugs in early states, quality over speed, constant improvement of
knowledge and processes, etc. [Hunt et al. 1999]. Pragmatic Programming can be seen
as a supporting set of recommendations and techniques for participants in a project, and
especially for developers.

4.5 XBreed

XBreed is a mixture of XP, Scrum and Alexanderian11 ideas. The founder of XBreed
is Mike Beedle, one of the creators of Scrum. One of the main goals of XBreed is
to accomplish reusability [Agile Alliance 2003]. Unfortunately there is only very little
literature about XBreed available. The interested reader is referred to the principles and
practices of XP and Scrum.

5 Summary

Agile Software Development Methods do have certain advantages over traditional soft-
ware development methods. Agile methods often consider not only the technical ap-
proach of a software development project but rather provide a framework for other
aspects as well. Traditional methods and models may be still appropriate under certain
circumstances, but mostly agile methods are the better choice. Agile methods are get-
ting enhanced by new experiences and are relying heavily on empirical data gathered
throughout various projects. Some of the methods are emphasizing being adapted per
project, others are defined to be usable as they are for any kind of project. Which agile
method to use depends often on the criticality and the complexity of a system since
not all of the agile methods are designed for complex environments and large teams.
11
Alexanderian ideas are ideas mentioned by Christoph Alexander, the author of ’The Timeless
Way of Building’ , ISBN: 0195024028

33
Offshore-development and reusability are other aspects which need to be considered
when deciding which method to use. The transition from traditional principles to agile
principles for a company can be a difficult process since this transition requires dis-
cipline of everybody involved. Communication, one of the main criterias for projects
becoming challenged projects or being cancelled, and a steady information flow be-
tween everybody involved in a project relies on people having the right social skills.
If individuals are not capable of communicating accordingly to project constraints and
activities agile methods may provide inappropriate results. Social skills, infrastructure,
political situations and similar factory are also important to be considered when choos-
ing a method for a project.

The family of agile methods is continuously growing. Agile methods can either be
used isolated or very often as combination, since there are differences in the definitions
of the different sub-disciplines. Some of them are more focused on project management,
others are providing more information of how to produce accurate code. Combinations
of agile methods are a newer creation and there is still place for improvements. Beside
the technical aspects of a project also social skills of people involved are changing as
well as political, infrastructural, economical situations. The world itself is a changing
environment and so it sounds feasible to create and use methods which are based on the
assumption of rather needing to react on change than to plan everything from beginning
to the end.

References
[Cockburn 2002] Cockburn, Alistair: ”Agile Software Develop-
ment”; Addison-Wesley, Boston/San Francisco/New
York/Toronto/Montreal/London/Munich/Paris/Madrid/Capetown/Sydney/
Tokyo/ingapore/Mexiko City (2002), 2nd print
[Royce 1970] Royce, Winston: ”Managing the Development of Large Software Sys-
tems: Concepts and Techniques” , WestCon (Technical Papers of West-
ern Electronic Show and Convention), IEEE CS Press, (August 1970),
328-339, Los Angeles,
[Standishgroup 1994] Standishgroup: ”The Chaos Report”, Stan-
dishgroup (1994), can also be found at
http://www1.standishgroup.com//sample research/PDFpages/chaos1994.pdf
[Highsmith 2002] Highsmith, Jim: ”Agile Software Development Ecosys-
tems” , Addison-Wesley, Boston/San Francisco/New
York/Toronto/Montreal/London/Munich/Paris/Madrid/Capetown/Sydney/
Tokyo/ingapore/Mexiko City (2002)
[Takeuchi et al. 1986] Takeuchi, Hirotaka; Nonaka, Ikujiro: ”The New New
Product Development Game”; Harvard Business Re-
view, (January-February 1986); can be ordered at
http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item detail.jhtml?id=86116
[Rising et al. 2000] Rising, Linda; Janoff, Norman S.: ”The Scrum Software
Development Process for Small Teams” , IEEE Soft-
ware, 17, 4, (2000), 26-32; the article can be found at
http://members.cox.net/risingl1/articles/IEEEScrum.pdf

34
[Stapleton 1995] Stapleton, Jennifer: ”DSDM Dynamic Systems Develop-
ment Method” , Addison-Wesley, Boston/San Francisco/New
York/Toronto/Montreal/London/Munich/Paris/Madrid/Capetown/Sydney/
Tokyo/ingapore/Mexiko City (1997)
[Abrahamsson et al. 2002] Abrahamsson, Pekka; Salo, Outi; Ronkainen, Jussi; Warsta, Juhani:
”Agile Software Development Methods - Review and Analysis” ,
VTT Publications, 478 (2002), Espoo; the document can be found at
http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf
[Beck 2000] Beck, Kent: ”Extreme Programmming - Das Man-
ifest” , Addison-Wesley, Boston/San Francisco/New
York/Toronto/Montreal/London/Munich/Paris/Madrid/Capetown/Sydney/
Tokyo/ingapore/Mexiko City (2000); English original title: ”Extreme
Programming Explained. Embrace Change”
[Lippert et al. 2002] Lippert, Martin; Roock, Stefan; Wolf, Martin: ”Software entwickeln mit
eXtreme Programming” , dpunkt.verlag, Heidelberg (2002)
[Highsmith 2002a] Highsmith, Jim: ”What Is Agile Software Development?”
, CrossTalk - The Journal of Defense Software Engineer-
ing, 15, 10 (2002), 4-9; the article can be downloaded at
http://www.jimhighsmith.com/articles/cross oct02.pdf
[Hunt et al. 1999] Hunt, Andrew; Thomas, David: ”The Pragmatic Pro-
grammer” , Addison-Wesley, Boston/San Francisco/New
York/Toronto/Montreal/London/Munich/Paris/Madrid/Capetown/Sydney/
Tokyo/ingapore/Mexiko City (1999);
[Standishgroup 2000] Standishgroup: ”The Chaos Report”, Standishgroup (2000); can be or-
dered at http://www.standishgroup.com by registered members

References
[Ambler 2004] Ambler, Scott W.: ”Agile Database Techniques” , Borland-Conference
(September 11-15 2004), San Jose/USA; the proceeding can be down-
loaded from http://bdn.borland.com/article/images/32436/3046.pdf
[Fowler 2003] Fowler, Martin: ”The New Methodology”,
http://martinfowler.com/articles/newMethodology.html, (May 1st,
2005)
[Smits 2005] Smits, Hubert: ”Roadmap to Agile methods and tools”,
http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm,
(May 1st, 2005)
[Agile Manifesto 2001] http://www.agilemanifesto.org/ , ”Manifesto for Agile Software Dvelop-
ment” , (May, 1st 2005)
[Hickok 2002] Hickok, Ralph: ”Rugby Glossary”,
http://www.hickoksports.com/glossary/grugby.shtml#stop , (May,
26th 2005)
[Acidaes Solutions 2004] http://www.acidaes.com/SWM.htm, (May, 26th 2005, Sashimi Model)
[ADM 2005a] Advanced Development Methods, Inc. (ADM): ”Scrum Explanation”
, http://www.controlchaos.com/download/Scrum%20Explanation.pdf,
(May, 26th 2005)
[ADM 2005b] Advanced Development Methods, Inc. (ADM): ”Scrum Library” ,
http://www.controlchaos.com/resources/index.php, (May, 26th 2005)
[DSDM Consortium 2005a] DSDM Consortium: ”The History of the DSDM Consortium” ,
http://www.dsdm.com/en/about/history.asp, (May, 26th 2005)
[DSDM Consortium 2005b] DSDM Consortium: ”Principles” ,
http://www.dsdm.org/tour/principles.asp, (May, 26th 2005)

35
[Morrison 2003] Morrison, Kevin: ”FDD Process Diagram - Visio version”,
http://www.featuredrivendevelopment.com/downloads, (May, 29th
2005)
[De Luca 2002] De Luca, Jeff: ”Feature Driven Development Processes”, ,
http://www.featuredrivendevelopment.com/files/fddprocessesA4.pdf,
(May, 29th 2005)
[Poppendieck 2001] Poppendieck, Mary: ”Lean Programming” , Software Develop-
ment Magazine, (May-June 2001), the article can be found at
http://www.agilealliance.com/articles/articles/LeanProgramming.htm,
(June 1st, 2005)
[Jeffries 2001] Jeffries, Ron: ”What is Extreme Programming?” ,
http://www.xprogramming.com/xpmag/whatisxp.htm, (June 1st, 2005)
[Testdriven.com 2005] http://www.testdriven.com, (June 2005, )
[Object Mentor 2005] Object Mentor, Inc.: ”Test Driven Development” ,
http://www.objectmentor.com/writeUps/TestDrivenDevelopment,
(June 4th,2005)
[Agile Alliance 2003] Agile Alliance: ”XBreed” ,
http://www.agilealliance.org/programs/roadmaps/Roadmap/xbreed/xbreed index.htm,
(June, 4th 2005)
[Als et al. 2003] Als, Adrian; Greenidge, Charles: ”The Waterfall Model” ,
http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall model.htm;
(June, 4th 2005)
[Goldsmith et al. 2002] Goldsmith, Robin F.; Graham, Dorothy.: it ”The Forgotten Phase” ,
http://www.sdbestpractices.com/documents/s=8815/sdm0207e/0207e.htm,
(June, 4th 2005)
[Spiral Lifecycle 1998] http://cctr.umkc.edu/ kennethjuwng/spiral.htm; (June, 7th 2005, Spiral
Lifecycle)

36