Agile Approaches

Rapid Application Development

Rapid Application Development (RAD) is also a generic term for a range of

evolutionary prototyping approaches. Many of the approaches have been
developed over the years and are used within organizations and by consulting
firms to produce software results on a more rapid basis than the structured linear
methods. RAD is now in vogue due to the increasing demand for web-based
software to be developed at high speed.

Most RAD approaches nowadays are object-oriented because of the rapidity

object-oriented languages and tools provide. However, RAD approaches have
been successfully applied to speed up structured analysis, design and
programming efforts.

DSDM

The Dynamic Systems Development Method is a framework of controls for the

development of IT systems to tight timescales. It is independent of any particular
set of tools and techniques. It can be used with object-oriented and structured
analysis and design approaches in environments ranging from the individual PC
to global distributed systems. DSDM has been used successfully by
organizations in both the public and private sectors.

DSDM provides a generic process which must be tailored for use in a particular
organization dependent on the business and technical constraints. DSDM
outlines a five phase process:

- Feasibility Study
The feasibility study assesses the suitability of the application for a RAD
approach and checks that certain technical and managerial conditions are likely
to be met. The feasibility study typically lasts a matter of weeks

- Business study
The business study scopes the overall activity of the project and provides a
sound business and technical basis for all future work. The high-level functional
and non-functional requirements are baselined, a high-level model of the
business functionality and information requirements is produced, the system
architecture is outlined and the maintainability objectives are agreed

- Functional model iteration

The bulk of development work is in the two iteration phases where prototypes are
incrementally built towards the tested system which is placed in the user
environment during the implementation phase
- Design and build iteration
During the design and build iteration, the focus is on ensuring that the prototypes
are sufficiently well engineered for use in the operational environment

- Implementation
Implementation consists of putting the latest increment into the operational
environment and training the users. The final step in implementation is a review
of what has been achieved

Principles of DSDM:
- Active user involvement is imperative
- DSDM teams 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
A collaborative and co-operative approach between all stakeholders is essential

DSDM:
process Feasibility
overview Business
study

Functional
model Implementation
iteration
Design and
build
iteration
Example of DSDM process (from Stapleton, Jennifer. DSDM: The Method in
Practice. Addison-Wesley)
Extreme Programming

Extreme Programming (XP) is the poster child for the agile approaches. The
process was developed by Kent Beck, Ward Cunningham and Ron Jeffries.
When people think of agile they usually think in terms of XP. Extreme
Programming (XP) is a software development methodology that represents a
throwback to the very earliest and purest days of software development when
technicians ran the show. Then, software engineers enjoyed greater autonomy
largely because there were few in the management ranks who understood the
task at hand.
XP is the highest risk approach and requires the greatest skill, knowledge and
experience to run it successfully. According to the founders, all the principles of
XP must be adhered to in order to be successful; adapting several of the
principles and trying to do XP will not work.

Example XP Process

The XP process as shown above starts with a project's requirements which are
laid out as individual stories typically written on 3x5 cards. These stories have
test cases which are written by the customer and developer working as a team. A
test case includes the test and the desired results which, if met, indicate that that
story is complete.
The project is done in iterations. At the end of an iteration, the next iteration is
planned out in an iteration planning meeting called the Planning Game. The
customer (with the developers' guidance, of course) decides what stories are to
be implemented in the next iteration, based on what is most important to them,
and what is most practical to implement next.
It is important that all iterations take the same amount of time. This is so that
metrics can be retained that let the XP team know what their velocity (speed of
development) is. The time that it took to complete a given story is recorded so
that the programmers get a good feel for how much effort it takes to do that type
of work.
The stories are broken down into tasks, which are the steps needed to implement
a given user story. Developers then sign up to do those tasks.
On the completion of an iteration, acceptance tests are done to ensure that the
test cases defined in that story have been met. The acceptance tests include
both automated unit testing, and customer testing. This makes sure that all
requirements are reached because the development is based around those
requirements and there are definite indicators that tell whether a given
requirement is met. It also breaks down the project into reachable goals rather
than having programmers work away forever on an ever-expanding scope.

Some XP Precepts:

- XP calls for short release cycles, a few months at most, so the scope of any slip
is limited. Within a release, XP uses one- to four-week iterations of customer
requested features for fine-grained feedback about progress. Within an iteration,
XP plans with one- to three-day tasks, so the team can solve problems even
during an iteration

- XP asks the customer to choose the smallest release that makes the most
business sense, so there is less to go wrong before going into production and the
value of the software is greatest

- XP creates and maintains a comprehensive suite of tests, which are run and re-
run after every change (several times a day), to ensure a quality baseline

- XP calls for the customer to be an integral part of the team. The specification of
the project is continuously refined during development, so learning by the
customer and the team can be reflected in the software

- XP asks programmers to accept responsibility for estimating and completing

their own work, gives them feedback about the actual time taken so their
estimates can improve, and respects those estimates
[Kent Beck, Extreme Programming Explained, Addison-Wesley, 2000]

XP Principles
The following principles from Kent Becks book Extreme Programming Explained
constitute the essence of XP. Many are the same as principles already
described for other agile processes or in general. Some were initiated by XP and
some were adopted by XP.

1. The Planning Game: Business and development cooperate to produce the

maximum business value as rapidly as possible. The planning game happens at
various scales, but the basic rules are the same:

Business comes up with a list of desired features for the system. Each feature
is written out as a User Story, which gives the feature a name, and describes in
broad strokes what is required. User stories are typically written on 4x6 cards.
Development estimates how much effort each story will take, and how much
effort the team can produce in a given time interval.
Business then decides which stories to implement in what order, as well as
when and how often to produce a production release of the system

2. Small Releases: XP teams practice small releases in two important ways:

First, the team releases running, tested software, delivering business value
chosen by the Customer, every iteration. The Customer can use this software for
any purpose, whether evaluation or even release to end users. The most
important aspect is that the software is visible, and given to the customer, at the
end of every iteration. Second, XP teams release to their end users frequently as
well. XP Web projects release as often as daily, in house projects monthly or
more frequently.

3. Simple Design: XP uses the simplest possible design that gets the job done.
The requirements will change tomorrow, so only do what's needed to meet
today's requirements. Design in XP is not a one-time thing but an all-the-time
thing. There are design steps in release planning and iteration planning, plus
teams engage in quick design sessions and design revisions through refactoring,
through the course of the entire project.

4. Metaphor: Extreme Programming teams develop a common vision of how the

program works, which we call the "metaphor". At its best, the metaphor is a
simple evocative description of how the program works. XP teams use a
common system of names to be sure that everyone understands how the system
works and where to look to find the functionality you're looking for, or to find the
right place to put the functionality you're about to add.

5. Continuous Testing: XP teams focus on validation of the software at all times.

Programmers develop software by writing tests first, and then code that fulfills the
requirements reflected in the tests. Customers provide acceptance tests that
enable them to be certain that the features they need are provided.

6. Refactoring: XP Team Refactor out any duplicate code generated in a coding

session. Refactoring is simplified due to extensive use of automated test cases.

7. Pair Programming: All production code is written by two programmers sitting at

one machine. This practice ensures that all code is reviewed as it is written and
results in better design,testing, and code.
Some programmers object to pair programming without ever trying it. It does take
some practice to do well, and you need to do it well for a few weeks to see the
results. Ninety percent of programmers who learn pair programming prefer it, so
it is recommended to all teams. Pairing, in addition to providing better code and
tests, also serves to communicate knowledge throughout the team.

8. Collective Code Ownership: No single person "owns" a module. Any developer

is expected to be able to work on any part of the codebase at any time.

9. Continuous Integration: All changes are integrated into the codebase at least
daily. The unit tests have to run 100% both before and after integration.
Infrequent integration leads to serious problems on a software project. First of all,
although integration is critical to shipping good working code, the team is not
practiced at it, and often it is delegated to people who are not familiar with the
whole system. Problems creep in at integration time that are not detected by any
of the testing that takes place on an unintegrated system. Also weak integration
process leads to long code freezes. Code freezes mean that you have long time
periods when the programmers could be working on important shippable
features, but that those features must be held back.

10. 40-Hour Work Week: Programmers go home on time. In crunch mode, up to

one week of overtime is allowed. But multiple consecutive weeks of overtime are
treated as a sign that something is very wrong with the process and/or schedule.

11. On-site Customer: Development team has continuous access to the

customer who will actually be using the system. For initiatives with lots of
customers, a customer representative(i.e Product Manager) will be designated
for Development team access.

12. Coding Standards: Everyone codes to the same standards. The specifics of
the standard are not important: what is important is that all the code looks
familiar, in support of collective ownership.