Agile Software Development

• Agile methods
• Extreme programming
• Disadvantages of Agile methods
• Plan-driven and agile development

1
Rapid software development

• 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.
• Rapid software development
• Specification, design and implementation are inter-leaved
• System is developed as a series of versions with stakeholders
involved in version evaluation

2
Agile methods

• Dissatisfaction with the overheads involved in software

design methods of the 1980s and 1990s led to the
creation of agile methods. These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
• The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and
to be able to respond quickly to changing requirements
without excessive rework.

3
Agile manifesto

vIndividuals and interactions over processes and tools

vWorking software over comprehensive documentation
vCustomer collaboration over contract negotiation
vResponding 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.
• There have been cases in which design documentation
was done only as a requirement of the contract. As a
result, it was poorly done and almost unreadable.

4
The principles of agile methods

Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.

5
Agile method applicability

• Product development where a software company is

developing a small or medium-sized product for sale.
• Custom system development within an organization,
where there is a clear commitment from the customer
to become involved in the development process and
where there are not a lot of external rules and
regulations that affect the software.
• Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.

6
Agile Methodologies Example: XP (Extreme
Programming)
• XP is an agile software methodology
• Higher priority on adaptability (“empirical process control
model”) than on predictability (“defined process control model”)
• Change in the requirements is normal during software
development
• Software developer must be able react to changing
requirements at any point during the project
• XP prescribes a set of day-to-day practices for managers and
developers to address this problem.

7
XP Day-to-Day Practices

1. Rapid feedback
• Confronting issues early results in more time for
resolving issues. This applies both to client feedback
and feedback from testing
2. Simplicity
• The design should focus on the current requirements
• Simple designs are easier to understand and change
than complex ones
3. Incremental change
• One change at a time instead of many concurrent
changes
• One change at a time should be integrated with the
current baseline.

8
XP day-to-day (continued)

4. Embracing change
• Change is inevitable and frequent in XP projects
• Change is normal and not an exception that needs to
be avoided
5. Quality work
• Focus on rapid projects where progress is
demonstrated frequently
• Each change should be implemented carefully and
completely.

9
How much planning in XP?

• Planning is driven by requirements and their

relative priorities
• Requirements are elicited by writing stories with the
client (called user stories)
• User stories are high-level scenarios or use cases
that encompass a set of coherent features
• Developers decompose each user story in terms of
development tasks that are needed to realize the
features required by the story
• Developers estimate the duration of each task in terms
of days
• If a task is planned for more than a couple of weeks, it
is further decomposed into smaller tasks.

10
How much planning in XP?
• Ideal weeks
• Number of weeks estimated by a developer to
implement the story if all work time was dedicated for
this single purpose
• Fudge Factor
• Factor to reflect overhead activities ( meetings,
holidays, sick days... )
• Also takes into account uncertainties associated with
planning
• Project velocity
• Inverse of ideal weeks
• i.e., how many ideal weeks can be accomplished in
fixed time.
• Velocity is a metric that predicts how much work an
Agile software development team can successfully
complete within a two-week sprint (or similar time- 11
boxed period).
How much planning in XP?

• Stacks
• The user stories are organized into stacks of related
functionality
• Prioritization of stacks
• The client prioritizes the stacks so that essential
requirements can be addressed early and optional
requirements last
• Release Plan
• Specifies which story will be implemented for which
release and when it will be deployed to the end user
• Schedule
• Releases are scheduled frequently (e.g., every 1–2
months) to ensure rapid feedback from the end users.

12
Team Organization in XP

• Production code is written in pairs (pair

programming)
• Individual developers may write prototypes for
experiments or proof of concepts, but not
production code
• Moreover, pairs are rotated often to enable a
better distribution of knowledge throughout the
project.

13
How much reuse in XP?

• Simple design
• Developers are encouraged to select the most simple
solution that addresses the user story being currently
implemented
• No design reusability
• The software architecture can be refined and
discovered one story at the time, as the prototype
evolves towards the complete system
• Focus on Refactoring
• Design patterns might be introduced as a result of
refactoring, when changes are actually implemented
• Reuse discovery only during implementation.

14
How much modeling in XP?

• No explicit analysis/design models

• Minimize the amount of documentation
• Fewer deliverables reduce the duplication of issues
• Models are only communicated among
participants
• The client is the “walking specification”
• Source Code is the only external model
• The system design is made visible in the source code
by using descriptive naming schemes
• Refactoring is used to improve the source code
• Coding standards are used to help developers
communicate using only the source code.

15
How much process in XP?

• Iterative life cycle model with 5 activities:

planning, design, coding, testing and integration
• Planning occurs at the beginning of each iteration
• Design, coding, and testing are done incrementally
• Source code is continuously integrated into the main
branch, one contribution at the time
• Unit tests for all integrated units; regression testing
• Constraints on these activities
• Test first. Unit tests are written before units. They are
written by the developer
• When defects are discovered, a unit test is created to
reproduce the defect
• Refactor before extending the source code.

16
How much control in XP?

• Reduced number of formal meetings

• Daily stand up meeting for status communication
• No discussions to keep the meeting short
• No inspections and no peer reviews
• Pair programming is used instead
• Production code is written in pairs, review during
coding.
• Self-organizing system with a leader:
• The Leader communicates the vision of the system
• The leader does not plan, schedule or budget
• The leader establishes an environment based on
collaboration, shared information, and mutual trust
• The leader ensures that a product is shipped.

17
Summary of the XP Methodology
Planning Collocate the project with the client,write user stories
with the client, frequent small releases (1-2 months),
create schedule with release planning, kick off an
iteration with iteration planning, create programmer
pairs, allow rotation of pairs
Modeling Select the simplest design that addresses the current
story; Use a system metaphor to model difficult
concepts; Use CRC cards for the initial object
identification; Write code that adheres to standards;
Refactor whenever possible
Process Code unit test first, do not release before all unit tests
pass, write a unit test for each uncovered bug, integrate
one pair at the time
Control Code is owned collectively. Adjust schedule, Rotate
pairs, Daily status stand-up meeting, Run acceptance
tests often and publish the results.
18
Summary…

• XP is an agile software development

methodologies with focus on
• Empirical process control model
• Changing requirements are the norm
• Controlling conflicting interests and needs
• Very simple processes with clearly defined rules
• Self-organizing teams, where each team
member carries a lot of responsibility
• No extensive documentation
• Possibility for “undisciplined hacking”.

19
Problems with agile methods

• It can be difficult to keep the interest of customers who

are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritising 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.

20
Agile methods and software maintenance

• Most organizations spend more on maintaining existing

software than they do on new software development.
So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
• Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process
of minimizing formal documentation?
• Can agile methods be used effectively for evolving a system in
response to customer change requests?
• Problems may arise if original development team
cannot be maintained.

21
Plan-driven and agile development

• Plan-driven development
• A plan-driven approach to software engineering is based
around separate development stages with the outputs to be
produced at each of these stages planned in advance.
• Not necessarily waterfall model – plan-driven, incremental
development is possible
• Iteration occurs within activities.
• Agile development
• Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.

22
Plan-driven and agile specification

23
Technical, human, organizational issues

• Most projects include elements of plan-driven and agile

processes. Deciding on the balance depends on:
• Is it important to have a very detailed specification and design
before moving to implementation? If so, you probably need to use
a plan-driven approach.
• Is an incremental delivery strategy, where you deliver the software
to customers and get rapid feedback from them, realistic? If so,
consider using agile methods.
• How large is the system that is being developed? Agile methods
are most effective when the system can be developed with a small
co-located team who can communicate informally. This may not be
possible for large systems that require larger development teams
so a plan-driven approach may have to be used.

24
Technical, human, organizational issues
• What type of system is being developed?
• Plan-driven approaches may be required for systems that
require a lot of analysis before implementation (e.g. real-time
system with complex timing requirements).
• What is the expected system lifetime?
• Long-lifetime systems may require more design documentation
to communicate the original intentions of the system
developers to the support team.
• What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving
design
• How is the development team organized?
• If the development team is distributed or if part of the
development is being outsourced, then you may need to
develop design documents to communicate across the
development teams.
25
Technical, human, organizational issues

• Are there cultural or organizational issues that may affect the

system development?
• Traditional engineering organizations have a culture of
plan-based development, as this is the norm in
engineering.
• How good are the designers and programmers in the
development team?
• It is sometimes argued that agile methods require higher
skill levels than plan-based approaches in which
programmers simply translate a detailed design into code
• Is the system subject to external regulation?
• If a system has to be approved by an external regulator
(e.g. the FAA approve software that is critical to the
operation of an aircraft) then you will probably be required
to produce detailed documentation as part of the system
safety case.
26