UNIT 2: AGILE DEVELOPMENT

❖ Agility:

Figure.1 Agility

Agility is more than an effective response to change (Adapts change frequently).

➢ It encourages team structures and attitudes that make communication (among team members, between
technologists and business people, between software engineers and their managers) simpler.
➢ It emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate
work products.
➢ It adopts the customer as a part of the development team.
➢ It recognizes that planning in an uncertain world has its limits and that a project plan mustbe flexible.

Figure.2 Change Costs as a function of time in development

Page | 1
 UNIT 2: AGILE DEVELOPMENT
➢ The conventional belief in software development (supported by decades of experience) is that the cost of
change increases nonlinearly as a project progresses (Figure, solid black curve). It is relatively easy to
accommodate a change when a software team is gathering requirements (early in a project). A usage
scenario might have to be modified, a list of functions may be extended, or a written specification can be
edited. The costs of doing this work are minimal, and the time required will not adversely affect the
outcome of the project.

➢ But what if we fast-forward a number of months? The team is in the middle of validation testing
(something that occurs relatively late in the project), and an important stakeholder is requesting a major
functional change. The change requires a modification to the architectural design of the software, the
design and construction of three new components, modifications to another five components, the design
of new tests, and so on. Costs increases quickly, and the time and cost required to ensure that the change
is made without unintended side effects is nontrivial.

➢ Proponents of agility argue that a well-designed agile process “flattens” the cost of change curve (Figure,
shaded, solid curve), allowing a software team to accommodate changes late in a software project
without dramatic cost and time impact.

❖ Agile Process:
➢ Any 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.

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 (from a planning point of view) as we
might like.

➢ Given these three assumptions, an important question arises: How do we create a process that can
manage unpredictability? An agile process, therefore, must be adaptable. But continual adaptation
without forward progress accomplishes little. Therefore, an agile software process must adapt
incrementally. To accomplish incremental adaptation, an agile team requires customer feedback (so that
the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational
prototype or a portion of an operational system. Hence, an incremental development strategy should be
instituted. Software increments (executable prototypes or portions of an operational system) must be
delivered in short time periods so that adaptation keeps pace with change (unpredictability). This
iterative approach enables the customer to evaluate the software increment regularly, provide necessary
feedback to the software team, and influence the process adaptations that are made to accommodate the
feedback.

❖ Agile Principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.

Page | 2
 UNIT 2: AGILE DEVELOPMENT
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.’
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.

Figure.3 Where Agile Methodology not work

❖ Extreme Programming.
Extreme Programming (XP) is the most widely used approach to agile software development.

• XP Values:
➢ Beck defines a set of five values that establish a foundation for all work performed as part of XP—
communication, simplicity, feedback, courage, and respect. Each of these values is used as a driver for
specific XP activities, actions, and tasks.
➢ In order to achieve effective communication between software engineers and other stakeholders (e.g., to
establish required features and functions for the software), XP emphasizes close, yet informal (verbal)
collaboration between customers and developers.
➢ To achieve simplicity, XP restricts developers to design only for immediate needs, rather than consider
future needs. The intent is to create a simple design that can be easily implemented in code). If the
design must be improved, it can be refactored at a later time.
➢ Feedback is derived from three sources: the implemented software itself, the customer, and other
software team members.
➢ An agile XP team must have the discipline (courage) to design for today, recognizing that future
requirements may change dramatically, thereby demanding substantial rework of the design and
implemented code.

Page | 3
 UNIT 2: AGILE DEVELOPMENT
• XP Process:

Figure.4 XP Process

• XP Activities:
1. Planning. The planning activity 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. Listening leads to the creation of a
set of “stories” (also called user stories) that describe required output, features, and functionality for
software to be built.

Figure.5 XP Process-Planning
➢ The customer assigns a value (i.e., a priority) to the story based on the overall business value of the
feature or function. Members of the XP team then assess each story and assign a cost—measured in
development weeks—to it. If the story is estimated to require more than three development weeks, the
customer is asked to split the story into smaller stories and the assignment of value and cost occurs
again. It is important to note that new stories can be written at any time.
➢ The XP team orders the stories that will be developed in one of three ways:
i). all stories will be implemented immediately (within a few weeks),
ii). the stories with highest value will be moved up in the schedule and implemented first,
iii). the riskiest stories will be moved up in the schedule and implemented first.
➢ After the first project release (also called a software increment) has been delivered, the XP team

Page | 4
 UNIT 2: AGILE DEVELOPMENT
computes project velocity. Stated simply, project velocity is the number of customer stories implemented
during the first release.

2. 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 (because the
developer assumes it will be required later) is discouraged.

Figure.6 XP Process-Design
➢ If a difficult design problem is encountered as 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. The intent is to lower risk when true implementation
starts and to validate the original estimates for the story containing the design problem.
➢ XP encourages refactoring—a construction technique that is also a method for design optimization.

3. 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 (software increment). Once the unit test has been created. Once the code is
complete, it can be unit-tested immediately, thereby providing instantaneous feedback to the developers.
A key concept during the coding activity (and one of the most talked about aspects of XP) is pair
programming. XP recommends that two people work together at one computer workstation to create
code for a story. As pair programmers complete their work, the code they develop is integrated with the
work of others. In some cases, this is performed on a daily basis by an integration team.

Figure.7 XP Process-Coding

4. Testing. The creation of unit tests before coding commences is a key element of the XP approach. The
unit tests that are created should be implemented using a framework that enables them to be automated
(hence, they can be executed easily and repeatedly). This encourages a regression testing strategy
whenever code is modified.

Figure.8 XP Process-Testing

➢ XP acceptance tests, also called customer tests, are specified by the customer and focus on overall
system features 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.

Page | 5
 UNIT 2: AGILE DEVELOPMENT
❖ Scrum Process model:
➢ Scrum emphasizes the use of a set of software process patterns that have proven effective for projects
with tight timelines, changing requirements, and business criticality. Each of these process patterns
defines a set of development actions:

Figure.9 Scrum Framework at a glance

Figure.10 Scrum Process

• 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 (this is how changes are introduced). The
product manager assesses the backlog and updates priorities as required.

Page | 6
 UNIT 2: AGILE DEVELOPMENT
• Sprints—consist of work units that are required to achieve a requirement defined in the backlog that
must be fit into a predefined time-box14 (typically 30 days). Changes (e.g., backlog work items) are not
introduced during the sprint. Hence, the sprint allows team members to work in a short-term, 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:

✓ What did you do since the last team meeting?

✓ What obstacles are you encountering?

✓ 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.

• 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.

Page | 7