A PRIMER

1
 By now we are familiar with several process models that
have been in use since the last few decades.
 However, the traditional models have not proved to be
entirely foolproof! They have been often described as
‘highly bureaucratic’ that has led to slowdown of several
projects.
 This in turn has led to time and cost overrun of several
projects.
 Since the 1990’s software researchers and practitioners
have been working on an entirely different paradigm
called as ‘agility’.

2
 Ivar Jacobson, one of the ‘three amigos’ of object-
orientation philosophy, has explained:
◦ An agile team is a nimble team able to appropriately respond to
changes.
◦ Changes are what software development is very much about.
◦ Changes in the software being built, changes to team members,
changes because of new technology, changes of all kinds that
may have an impact on the product they build or the project that
creates the product.
◦ Support for changes should be built-in everything we do in
software, something we embrace because it is the heart and soul
of software.

3
 We can subject any software process to the philosophy
of ‘agility’ and we need to plan the process in such a
manner that would facilitate the software development
team to
◦ alter the work flow and
◦ keep them simple and lean enough,
◦ adopt a planning paradigm that encourages the flexible nature of
an agile development approach,
◦ and adopt a strategy of delivering software to the customer in an
incremental fashion,
◦ wherein each delivery will have new enhancements/functionalities
or modifications to the previous delivery.
 This way we can ensure that the software gets ‘live’ at
the customer end more quickly than what would have
been possible in the traditional process methodologies
4
 In 2001, Kent Beck and 16 other noted software
developers, writers, and consultants (referred to as
the “Agile Alliance”) signed the ‘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.”

5
 An agile process is:
◦ guided by scenarios (customer portrayal of the
requirements in story-board format),
◦ acknowledges that plans are not frozen permanently and
can be changed as and when required,
◦ builds software on an iteration-basis,
◦ and delivers the final software over several ‘software
incremental deliveries’,
◦ and adjusts to the changes that is bound to happen during
the entire duration of the project.
 Agile approaches developed in 1990s as a reaction
to document driven approaches that were
sometimes highly bureaucratic.

6
 Most agile approaches have some common principles:
◦ Working software is used as yardstick for measuring the
progress of software development
◦ The final software need to be delivered in multiple increments,
with each increment quite small
◦ The planning should be so adaptive that even changes desired
during the late stage of the project should also be
accommodated.
◦ Prefer face to face communications as opposed to relying
mostly on documentation
◦ Continuous response and continuous customer commitment
and enthusiasm are essential for an agile project’s success
◦ Prefer simple design which evolves over time
◦ The software development team is authorized to determine the
software delivery dates. This is contrary to traditional methods,
where typically a top-management person may decide on the
delivery dates and the software development team have to then
abide.
7
 Thus, we can generalize and say that it is practically
impossible to predict in advance from a planning
viewpoint all the aspects of analysis, design,
construction, and testing.

 You may have realized by now that we are talking of a

process that can manage unpredictability! We can
achieve this only by being adaptable, and that too
incrementally, rather than being firm.

8
 In traditional software developmental models, it has
been observed that the cost of change does not
increase in a straight line pattern but rather increases
in a non-linear fashion. The cost of change is minimal
at the requirements gathering stage and it is
comparatively easier to accommodate a change here as
it is in the early stage of the project. However, as we
move towards the latter phases of the project we
observe that the cost of change becomes very high

 Proponents of the agile method have established that a

well-designed agile process can reduce the overall
cost of change even in the later phases of the project
without significantly impacting cost and time.

9
 Extreme Programming (XP) is regarded as the most
prevalent agile method.

 It accepts the fact that changes will happen in the

requirements.

 Consequently, XP advocates that instead of belittling

changes as unwanted elements the development
ideology should be evolved around the fact that
changes are inevitable.

 Thus, the development methodology needs to be

flexible with the ability to respond quickly to changes.

10
 Therefore, this method is based on development of
software iteratively, and sidesteps the problem of
having to rely on comprehensive and numerous
documentation that are sometimes difficult to sustain
and maintain.

 This method encourages people-to-people

communication to make sure that the required
changes are incorporated into the programs.

11
 XP Planning commences with the business analyst
constructing “user stories” in consultation with the
customer

 The agile team members analyse each user story and

estimates a cost to it

 Next, the user stories are clustered together for the

first and subsequent incremental deliveries

 The agile team estimates the effort and sets the

deadline for the ‘incremental delivery’

 Post delivery of the first increment, estimates are

worked out and accordingly for other incremental
deliveries, the delivery dates are committed.
12
 An XP project commences with ‘user stories’ that are
brief explanations of the ‘scenarios’ which the
customers and end-users want the software to take
care.

 This form is quite unlike the conventional requirement

specifications mainly in explanation of the details – the
user stories exclude thorough elaboration of the
requirements.

 Such detailing happens only at the time of

construction, thereby granting more time to the users
for eliciting their requirements.

13
 The authorized development team then makes an approximate
calculation of the time required to develop the user story into a
software increment.

 The estimates are expressed in weeks and are often approximate

figures that are imprecise.

 Once these estimates are ready along with the user stories the
next step is to conduct release planning, a step that finalizes
which of the user stories are to be incorporated in which
incremental delivery, and also delivery dates for each of these
deliveries.

 A series of frequent, small deliveries are preferred. The user

stories are also used to create the acceptance tests. Each
incremental delivery has to pass the acceptance test before final
delivery to the customer.

14
 The authorized development team then makes an approximate
calculation of the time required to develop the user story into a
software increment.

 The estimates are expressed in weeks and are often approximate

figures that are imprecise.

 Once these estimates are ready along with the user stories the
next step is to conduct release planning, a step that finalizes
which of the user stories are to be incorporated in which
incremental delivery, and also delivery dates for each of these
deliveries.

 A series of frequent, small deliveries are preferred. The user

stories are also used to create the acceptance tests. Each
incremental delivery has to pass the acceptance test before final
delivery to the customer.

15
THE OVERALL AGILE PROCESS

16
 Development takes place in a series of iterations where each
iteration lasts for about a few weeks.

 The first step in ‘iteration’ is what is called as ‘iteration planning’

where we select the user stories to be incorporated in that
particular iteration.

 Those user stories that are considered by the customer as having

high-value and therefore, high-risk are given more importance
and incorporated during the initial iterations.

 Cases of failed acceptance tests earlier are appropriately handled

in subsequent iterations.

 The nitty-gritty details of the user stories are collected and

analyzed during the iteration for developing the incremental
delivery of the software.

17
 The developmental method adopted in the iterations follows
certain distinctive methods.

 First, development is taken up by pairs of programmers (i.e., two

programmers would be jointly developing code), instead of
individual programmers which is a very unique way of handling
the software project.

 Second, it encourages a ‘reverse methodology’ wherein

automated unit tests are designed first even before writing the
actual code.
◦ The actual program that is written later should clear the first-written
unit tests.
◦ This methodology is called as’ test-driven development’.
◦ As more and more functionality gets added to the unit, the unit tests
are also scaled up to accommodate the new functionalities.
◦ After this step the code is modified so as to be able to clear the newly
created unit tests.

18
 Third, because of the inevitable changes, it is probable that the
design developed earlier may become inappropriate for further
stages in the development.

 XP takes care of this problem by encouraging a step called as

‘refactoring’. Refactoring is employed to modify the design, after
which the refactored program is considered for the next level of
development. While refactoring only the existing functionalities
are considered and no new functionality is added.

19
 The discussion so far has provided us with some
details of XP.

 Other rules for XP have also been framed that consider

matters like software developers and customer’s rights
during the execution of the project, inter-personal
interactions among members of the team, protocols
for conducting meetings, etc.

20