Chapter 3 : Agile Software Development

1
Topics covered

 Agile methods
 Plan-driven and agile development
 Extreme programming
 Agile project management
 Scaling agile methods

2
Agile Software Development

• This methodology was developed to deal with situation where the

waterfall model fails. The biggest drawback of waterfall model is that it
assumes that every requirement of the project can be identified before any
design or coding occurs.
• Agile software development is a conceptual framework for software
engineering that promotes development iterations throughout the life-
cycle of the project.
• Software developed during one unit of time is referred to as an iteration,
which may last from one to four weeks.

3
• The Agile software development methodology is one of the simplest
and effective processes to turn a vision for a business need into software
solutions.
• The agile software development emphasizes on four core values.
– Individual and team interactions over processes and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan

• The word ‘agile’ means −

– Able to move your body quickly and easily.

– Able to think quickly and clearly.

4
Agile manifesto

• 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
 Rapid software development
• Why?
• Need to react to changes more quickly than 2 year long waterfall projects
• 2 years and then you got the design wrong anyway! Small deliveries aren't
abstract
• How?
• Goal - Deliver working software quickly
• Compromise - less functionality in a delivery, not lower quality
• Less documentation
• Focus on the code rather than the design
• Interleave
• Specification, design and implementation are inter-leaved
• Deliver small versions and get user (stakeholder) input 6
• Rapid development and delivery is now often the most important
requirement for software systems.
• Businesses operate in a fast-changing requirement and it is practically
impossible to produce a set of stable software requirements. Software has to
evolve quickly to reflect changing business needs.
• Agile development methods emerged in the late 1990s. All of the agile
methods that have been proposed share a number of common characteristics:

i. The processes of specification, design and implementation are interleaved.

There is no detailed system specification, and design documentation is
minimized or generated automatically by the programming environment used to
implement the system. The user requirements document is an outline definition
of the most important characteristics of the system.
7
ii. The system is developed in a series of increments. End-users and other system
stakeholders are involved in specifying and evaluating each increment.
iii. Extensive tool support is used to support the development process. Tools that
may be used include automated testing tools, tools to support configuration
management, and system integration and tools to automate user interface
production.
• Agile methods are incremental development methods in which the increments
are small, and, typically, new releases of the system are created and made
available to customers every two or three weeks.
• In a plan-driven software development process, iteration occurs within activities,
with formal documents used to communicate between stages of the process. For
example, the requirements will evolve, and, ultimately, a requirements
specification will be produced. This is then an input to the design and
implementation process. 8
• In an agile approach, iteration occurs across activities. Therefore, the
requirements and the design are developed together rather than separately.
• The most widely-used Agile methodologies include:
• Agile Scrum Methodology.
• Lean Software Development.
• Kanban.
• Extreme Programming (XP)
• Crystal.
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)

9
 Plan-driven and agile specification
separate Iteration within stage
development Not
stages with necessarily
the outputs to waterfall
be produced model – plan-
at each of driven,
these stages incremental
planned in development
advance. is possible

User's full
agreement at
end, not before
code
Iteration of stage
Figure 3.1 Plan-driven and agile development
10
 Problems with agile methods
• It can be difficult to keep the interest of customers / users who are involved in
the process.
• Team members may be unsuited to the intense involvement that characterizes
agile methods.
• Prioritizing changes can be difficult where there are multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to iterative development.
• Because of their focus on small, tightly-integrated teams, there are problems in
scaling agile methods to large systems.
• Less emphasis on documentation - harder to maintain when you get a new
team for maintenance.
11
Agile methods: Extreme programming
• A popular form of Agile
• Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
• New versions may be built several times per day;

• Increments are delivered to customers every 2 weeks;

• All tests must be run for every build and the build is only accepted if tests run
successfully.
• Incremental development is supported through small, frequent releases of the system.
Requirements are based on simple customer stories or scenarios that are used as a
basis for deciding what functionality should be included in a system increment.
• Customer involvement means full-time customer engagement with the team. -
Specifications through user stories broken into tasks
• People, not process :pair programming, collective ownership and a process that avoids
long working hours. 12
• Regular system releases test-first development, refactoring to avoid code
degeneration, and continuous integration of new functionality.
• Maintaining simplicity through constant refactoring of code and by using simple
designs
• Extreme Programming is based on the following values −
• Communication: Everyone on a team works jointly at every stage of the
project.
• Simplicity: Developers strive to write simple code bringing more value to a
product, as it saves time and efforts.
• Feedback: Team members deliver software frequently, get feedback about it,
and improve a product according to the new requirements.
• Respect: Every person assigned to a project contributes to a common goal.
• Courage: Programmers objectively evaluate their own results without
making excuses and are always ready to respond to changes. 13
Figure 3.2 The XP release cycle

14
Figure.The Extreme Programming process

15
 Key practices of XP include:

Figure 3.3 “prescribing medication” story

An example of a story card for the Mentcare system is shown in above figure.This is
a short description of a scenario for prescribing medication for a patient. 16
User stories

• To make this easier, the idea of “user stories” was developed where a user story is a
scenario of use that might be experienced by a system user.
• In XP, a customer or user is part of the XP team and is responsible for making
decisions on requirements. User requirements are expressed as user stories or
scenarios.
• Once the story cards have been developed, the development team breaks these down
into tasks (Figure 3.4) and estimates the effort and resources required for
implementing each task. This usually involves discussions with the customer to
refine the requirements. The customer then prioritizes the stories for
implementation, choosing those stories that can be used immediately to deliver
useful business support.
• The intention is to identify Useful functionality that can be implemented in about
two weeks, when the next release of the system is made available to the customer.
17
• User stories can be helpful in getting users involved in suggesting requirements
during an initial predevelopment requirements elicitation activity.
• The idea of user stories is a powerful one—people find it much easier to relate to
these stories than to a conventional requirements document or use cases.

Figure 3.4 Examples of task cards for prescribing medication

18
Refactoring

• Refactoring means that the programming team look for possible

improvements to the software and implements them immediately. When
team members see code that can be improved, they make these
improvements even in situations where there is no immediate need for them.
• Refactoring improves the software structure and readability and so avoids
the structural deterioration that naturally occurs when software is changed.
• In principle, when refactoring is part of the development process, the
software should always be easy to understand and change as new
requirements are proposed.
• Changes are easier to make because the code is well-structured and clear.
• However, some changes requires architecture refactoring and this is much
more expensive. 19
• RISK: -Changes the user does not test -Changes to working software break it

Examples of refactoring
• Re-organization of a class hierarchy to remove duplicate code.
• Tidying up and renaming attributes and methods to make them easier to
understand.
• The replacement of inline code with calls to methods that have been included
in a program library.

20
Test-first development

• Testing is central to XP and XP has developed an approach where the

program is tested after every change has been made.
Test-driven development:
• Extreme Programming developed a new approach to program testing to
address the difficulties of testing without a specification.
• Tests are written as programs rather than data so that they can be
executed automatically.
• The test includes a check that it has executed correctly (usually relies on
a testing framework such as Junit).
• All previous and new tests are run automatically when new functionality
is added, thus checking that the new functionality has not introduced
errors. 21
Customer involvement: 
• The role of the customer in the testing process is to help develop
acceptance tests for the stories that are to be implemented in the next
release of the system.
• The customer who is part of the team writes tests as development
proceeds. All new code is therefore validated to ensure that it is what the
customer needs.
• However, people adopting the customer role have limited time available
and so cannot work full-time with the development team.
• They may feel that providing the requirements was enough of a
contribution and so may be reluctant to get involved in the testing process.

22
Figure 3.5 Test case description for dose checking

23
Pair programming
• Pair programming involves programmers working in pairs, developing code together.

• This helps develop common ownership of code and spreads knowledge across the team.

• It serves as an informal review process as each line of code is looked at by more than

one person. It encourages refactoring as the whole team can benefit from improving the

system code.

• In pair programming, programmers sit together at the same computer to develop the

software. Pairs are created dynamically so that all team members work with each other

during the development process.

• The sharing of knowledge that happens during pair programming is very important as it

reduces the overall risks to a project when team members leave.

• Pair programming is not necessarily inefficient and there is some evidence that suggests

that a pair working together is more efficient than two programmers working separately.
24
Introduction to Agile Project Management

Scrum
• The most popular agile framework is called scrum.
• The Scrum approach is a general agile method but its focus is on
managing iterative development rather than specific agile practices.
• Project Manager's job: - Deliver needed system on time within budget
• There are three phases in Scrum.
• outline planning phase: where you establish the general objectives
for the project and design the software architecture.
• Sprint cycles: where each cycle develops an increment of the system.
• The project closure: wraps up the project, completes required
documentation such as system help frames and user manuals and
assesses the lessons learned from the project. 25
Figure 3.6 Scrum

26
The Sprint cycle
• Sprints are fixed length, normally 2-4 weeks.
• The starting point for planning is the product backlog, which is the list
of work to be done on the project.  The selection phase involves all of the
project team who work with the customer (product owner/idea people)
to select the features and functionality to be developed during the sprint.
• During this stage the team is relatively isolated from the product owner
and the organization, with all communications channeled through
the ScrumMaster.
• The role of the ScrumMaster Master is responsible for setting up the
team, sprint meeting and removes obstacles to progress.  At the end of the
sprint the work done is reviewed and presented to stakeholders (including
the product owner). 27
• Velocity is calculated during the sprint review; it provides an estimate of
how much product backlog the team can cover in a single sprint.
Understanding the team's velocity helps them estimate what can be covered
in a sprint and provides a basis for measuring and improving performance.
The next sprint cycle then begins.

Figure 3.7 The Scrum software sprint cycle

28
• The ScrumMaster is a facilitator who arranges short daily meetings (daily
scrums), tracks the backlog of work to be done, records decisions,
measures progress against the backlog and communicates with the product
owner and management outside of the team.
• The whole team attends daily scrums where all team members share
information, describe their progress since the last meeting, problems that
have arisen and what is planned for the following day.

29
Figure 3.8 Distributed Scrum
30
Scrum benefits
• The product is broken down into a set of manageable and understandable

chunks.

• Unstable requirements do not hold up progress.

• The whole team have visibility of everything and consequently team

communication is improved.

• Customers see on-time delivery of increments and gain feedback on how the

product works.

• Trust between customers and developers is established and a positive culture

is created in which everyone expects the project to succeed.

31
 Scaling agile methods
• Agile methods were developed for use by small programming teams that could
work together in the same room and communicate informally. They were
originally used by for the development of small and medium-sized systems and
software products.
• scaling is about: how do we take the concepts of Agility into different segments
of the organization,
• It is sometimes argued that the success of these methods comes because of
improved communications which is possible when everyone is working together.
• Two perspectives on scaling of agile methods:
• Scaling up these methods to handle the development of large systems that
are too big to be developed by a single small team.
• For large systems development, it is not possible to focus only on the code of
the system; you need to do more up-front design and system documentation.
32
• Cross-team communication mechanisms have to be designed and used,
which should involve regular phone and video conferences between team
members and frequent, short electronic meetings where teams update each
other on progress.
• Scaling out these methods from specialized development teams to more
widespread use in a large company that has many years of software
development experience.
• Large organizations often have quality procedures and standards that all
projects are expected to follow and, because of their bureaucratic nature,
these are likely to be incompatible with agile methods.
• Agile methods seem to work best when team members have a relatively
high skill level. However, within large organizations, there are likely to be a
wide range of skills and abilities.
33
Thank you 34