Agile: Agile is a software development methodology to build software incrementally

using short iterations of 1 to 4 weeks so that the development process is aligned with
the changing business needs.
Agile Process: An agile software process is characterized in a manner that addresses
a number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist
and which will change. It is equally difficult to predict how customer priorities
will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That is,
both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
3. Analysis, design, construction and testing are not as predictable.
How does well-designed agile process flatten the cost of change curve?
An agile process reduces the cost of change because software is released in
increments and change can be better controlled within an increment. Agility argue
that a well-designed agile process “flattens” the cost of change curve shown in the
following figure, allowing a software team to accommodate changes late in a
software project without dramatic cost and time impact. When incremental delivery
is coupled with other agile practices such as continuous unit testing and pair
programming, the cost of making a change is attenuated. Although debate about the
degree to which the cost curve flattens is ongoing, there is evidence to suggest that
a significant reduction in the cost of change can be achieved.

Figure: change costs as a function of time in development.

Agile methods:
Extreme Programming: XP, the most widely used approach to agile software
development. XP uses an object-oriented approach as its preferred development
paradigm and encompasses a set of rules and practices that occur within the context
of four key framework activities:
i. Planning: The planning activity (also called planning game) begins with
listening – a requirements gathering activity that enables the technical
members of the XP team to understand the business context for the
software and to get a broad feel for required output and major features and
functionality.
ii. Design: XP design rigorously follows the KIS (keep it simple) principle.
A simple design is always preferred over a more complex representation.
In addition, the design provides implementation guidance for a story as it
is written – nothing less, nothing more. The design of extra functionality
is discouraged.

Spike Solution: If a difficult design problem is encountered as a part of

the design of a story, XP recommends the immediate creation of an
operational prototype of that portion of the design called a spike solution,
the design prototype is implemented and evaluated.

Refactoring: XP encourages refactoring – a construction technique that is

also a design technique. Refactoring is the process of changing a software
system in such a way that it does not alter then external behavior of the
code yet improve the internal structure. It is a disciplined way to clean up
code that minimizes the chances of introducing bugs. In essence, when we
refactor we are improving the design of the code after it has been written.
iii. Coding: After stories are developed and preliminary design work is done,
the team does not move to code, but rather develops a series of unit tests
that will exercise each of the stories that is to be included in the current
release. Once the code is complete, it can be unit-tested immediately,
thereby providing instantaneous feedback to the developers.
 Pair programming: XP recommends that two people work together at one
computer workstation to create code for a story. This provides a
mechanism for real-time problem solving (two heads are often better than
one) and real-time quality assurance (the code is reviewed as it is created).
iv. Testing: The unit tests that are created should be implemented using a
framework that enables them to be automated. This encourages a
regression testing strategy whenever code is modified.
As the individual unit tests are organized into a “universal testing suite”,
integration and validation testing of the system can occur on a daily basis.
This provides the XP team with a continual indication of progress and also
can raise warning flags early if things go awry.
XP acceptance tests, also called customer tests, are specified by the
customer and focus on overall system failures and functionality that are
visible and reviewable by the customer. Acceptance tests are derived from
user stories that have been implemented as part of a software release.

Scrum: Scrum is an agile software development method that was conceived by Jeff
Sutherland and his development team in the early 1990s. Scrum principles are
consistent with the agile manifesto and are used to guide development activities
within a process that incorporates the following framework activities: requirements,
analysis, design, evolution and delivery.
Sprint: Within each framework activity, work tasks occurs within a process pattern
called a sprint. The work conducted within a sprint is adapted to the problem at hand
and is defined and often modified in real time by the Scrum team.

The overall flow of the Scrum process:

Scrum emphasizes the use of a set of software process patterns that have been proven
effective for projects with tight timelines, changing requirements, and business
critically. Each of these process patterns defines a set of development activities:
Backlog – a prioritized list of project requirements or features that provide business
value for the customer. Items can be added to the backlog at any time. The product
manager assesses the backlog and updates priorities as required.
Sprints – consists of work units that are required to achieve a requirement defined
in the backlog that must be fit into a predefined time-box. Changes are not introduced
during the sprint. Hence, the sprint allows team members to work in a short-team,
but stable environment.
Scrum meetings – are short (typically 15 minutes) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team members:
i. What did you do since the last team meeting?
ii. What obstacles are you encountering?
iii. What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses
from each person. The Scrum meeting helps the team to uncover potential problems
as early as possible. These daily meetings lead to “knowledge socialization”.
Demos – deliver the software increment to the customer so that functionality that
has been implemented can be demonstrated and evaluated by the customer. It is
important to note that the demo may not contain all planned functionality, but rather
those functions that can be delivered within the time-box that was established.