Chapter 3

 Agile Development
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1
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.”
Kent Beck et al

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3
 What is “Agility”?
 Effective (rapid and adaptive) response to
change
 Organizing a team so that it is in control of the
work performed
 Effortless communication among all stakeholder
 Rapid delivery of operational s/w
 De-emphasizes work products
 Drawing the customer onto the team-eliminates
“us and them” attitude
Yielding …
 Rapid, incremental delivery of software

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4
An Agile Process
 For many s/w projects
 It is difficult to Predict requirements, customer priorities in advance
 Design and construction interleave
 Many framework activities cannot be predictably planned

 Unpredictability managed by adaptability i.e. Agile process must be

adaptable!
 An Agile process must not just adapt but move forward too i.e. incrementally
adapt!
 An agile process
 Is driven by customer descriptions/feedback of what is required
(scenarios)
 Recognizes that plans are short-lived

 Develops software iteratively with a heavy emphasis on construction

activities
 Delivers multiple ‘software increments

 Adapts as changes occur

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5
 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.
Chapter 3 Agile
software
development
6
Agility 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.
Agile processes harness change for the customer's competitive
advantage.
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.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7
Agility Principles
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 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8
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. Chapter 3 Agile
software
development
9
Plan-driven and agile
specification

Chapter 3 Agile
software
development
10
Agility and the Cost of Change

Increases
nonlinearly

Flat curve

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11
Extreme programming
 The most widely used agile process, originally
proposed by Kent Beck
 Perhaps the best-known and most widely used
agile method.
 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.

Chapter 3 Agile
software
development
12
XP and agile principles
 Incremental development is supported through
small, frequent system releases.
 Customer involvement means full-time
customer engagement with the team.
 People not process through pair programming,
collective ownership and a process that avoids
long working hours.
 Change supported through regular system
releases.
 Maintaining simplicity through constant
refactoring of code.
Chapter 3 Agile
software
development
13
The extreme programming
release cycle

Chapter 3 Agile
software
development
14
 Extreme programming
practices (a)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Chapter 3 Agile
software
development
15
 Extreme programming
practices (b)
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
Chapter 3 Agile
software
development
16
Requirements scenarios
 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 scenarios
or user stories.
 These are written on cards and the
development team break them down into
implementation tasks. These tasks are the
basis of schedule and cost estimates.
 The customer chooses the stories for inclusion
in the next release based on their priorities and
the schedule estimates. Chapter 3 Agile
software
development
17
XP Process
 XP Planning
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18
XP Process …
 XP Design
 Follows the KIS principle
 For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the internal
program design
 XP Coding
 Recommends the construction of a unit test for a store before
coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 19
Refactoring
 Programming team look for possible software
improvements and make these improvements
even where there is no immediate need for
them.
 This improves the understandability of the
software and so reduces the need for
documentation.
 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.
Chapter 3 Agile
software
development
20
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.

Chapter 3 Agile
software
development
21
Testing in XP
 Testing is central to XP and XP has developed
an approach where the program is tested after
every change has been made.
 XP testing features:
 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated test harnesses are used to run all
component tests each time that a new release is
built.

Chapter 3 Agile
software
development
22
Test-first development
 Writing tests before code clarifies the
requirements to be implemented.
 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.

Chapter 3 Agile
software
development
23
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 Chaptersoftware
3 Agile

enough of a contribution and so may be development 24

Test automation
 Test automation means that tests are written as
executable components before the task is
implemented
 These testing components should be stand-alone,
should simulate the submission of input to be tested
and should check that the result meets the output
specification. An automated test framework (e.g.
Junit) is a system that makes it easy to write
executable tests and submit a set of tests for
execution.
 As testing is automated, there is always a set
of tests that can be quickly and easily executed
 Whenever any functionality is added to the system,
Chapter 3 Agile
software
the tests can be run and problems that the new development
code 25
Pair programming
 In XP, programmers work in pairs, sitting
together to develop code.
 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 1
person.
 It encourages refactoring as the whole team
can benefit from this.
 Measurements suggest that development
productivity with pair programming is similar to
that of two people working independently.
Chapter 3 Agile
software
development
26
Pair programming
 In pair programming, programmers sit together
at the same workstation 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 evidence that a pair working Chaptersoftware
3 Agile

development
27
together is more efficient than 2 programmers
Advantages of pair
programming
 It supports the idea of collective ownership and
responsibility for the system.
 Individuals are not held responsible for problems with
the code. Instead, the team has collective
responsibility for resolving these problems.
 It acts as an informal review process because
each line of code is looked at by at least two
people.
 It helps support refactoring, which is a process
of software improvement.
 Where pair programming and collective ownership
are used, others benefit immediately from the Chapter 3 Agile
refactoring so they are likely to support the process.software
development
28
Key points
 Agile methods are incremental development methods
that focus on rapid development, frequent releases of
the software, reducing process overheads and
producing high-quality code. They involve the customer
directly in the development process.
 The decision on whether to use an agile or a plan-driven
approach to development should depend on the type of
software being developed, the capabilities of the
development team and the culture of the company
developing the system.
 Extreme programming is a well-known agile method that
integrates a range of good programming practices such
as frequent releases of the software, continuous
software improvement and customer participation Chapter
in the 3 Agile
development team. software
development
29
Extreme Programming (XP)
sp ike so lut io ns
simp le d esig n
p ro t ot ypes
CRC card s
user st ories
values
accep t ance t est crit eria
it erat io n p lan

refact o ring

pair
pro g ramming

Release
soft wa re incre m e nt unit t est
proje ct v e locit y com put e d co nt inuous int egrat ion

accep t ance t est ing

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 30
Agile project management
 The principal responsibility of software project
managers is to manage the project so that the
software is delivered on time and within the
planned budget for the project.
 The standard approach to project management
is plan-driven. Managers draw up a plan for the
project showing what should be delivered,
when it should be delivered and who will work
on the development of the project deliverables.
 Agile project management requires a different
approach, which is adapted to incremental
development and the particular strengths of Chapter 3 Agile
software

agile methods. development

31
Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
 Meetings are very short and sometimes conducted
without chairs
 “demos” are delivered to the customer with the time-
box allocated

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 32
Scrum
 The Scrum approach is a general agile method
but its focus is on managing iterative
development rather than specific agile
practices.
 There are three phases in Scrum.
 The initial phase is an outline planning phase where
you establish the general objectives for the project
and design the software architecture.
 This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
 The project closure phase wraps up the project,
completes required documentation such as system
help frames and user manuals and assesses the Chapter 3 Agile
software
lessons learned from the project. development
33
The Scrum process

Chapter 3 Agile
software
development
34
The Sprint cycle
 Sprints are fixed length, normally 2–4 weeks.
They correspond to the development of a
release of the system in XP.
 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 to select the
features and functionality to be developed
during the sprint.

Chapter 3 Agile
software
development
35
The Sprint cycle
 Once these are agreed, the team organize
themselves to develop the software. During this
stage the team is isolated from the customer
and the organization, with all communications
channelled through the so-called ‘Scrum
master’.
 The role of the Scrum master is to protect the
development team from external distractions.
 At the end of the sprint, the work done is
reviewed and presented to stakeholders. The
next sprint cycle then begins.
Chapter 3 Agile
software
development
36
Teamwork in Scrum
 The ‘Scrum master’ is a facilitator who
arranges daily meetings, tracks the backlog of
work to be done, records decisions, measures
progress against the backlog and
communicates with customers and
management outside of the team.
 The whole team attends short daily meetings
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.
 This means that everyone on the team knows what is
Chapter 3 Agile
software
going on and, if problems arise, can re-plan short-
development
37
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
Chapter 3 Agile
which everyone expects the project to succeed. software
development
38
Scaling agile methods
 Agile methods have proved to be successful for
small and medium sized projects that can be
developed by a small co-located team.
 It is sometimes argued that the success of
these methods comes because of improved
communications which is possible when
everyone is working together.
 Scaling up agile methods involves changing
these to cope with larger, longer projects where
there are multiple development teams, perhaps
working in different locations.
Chapter 3 Agile
software
development
39
Large systems development
 Large systems are usually collections of separate,
communicating systems, where separate teams
develop each system. Frequently, these teams are
working in different places, sometimes in different
time zones.
 Large systems are ‘brownfield systems’, that is they
include and interact with a number of existing
systems. Many of the system requirements are
concerned with this interaction and so don’t really
lend themselves to flexibility and incremental
development.
 Where several systems are integrated to create a
system, a significant fraction of the development
Chapteris
3 Agile
software
concerned with system configuration rather than development
40
Large system development
 Large systems and their development
processes are often constrained by external
rules and regulations limiting the way that they
can be developed.
 Large systems have a long procurement and
development time. It is difficult to maintain
coherent teams who know about the system
over that period as, inevitably, people move on
to other jobs and projects.
 Large systems usually have a diverse set of
stakeholders. It is practically impossible to
involve all of these different stakeholders in the
Chapter 3 Agile
software

development process. development

41
Scaling out and scaling up
 ‘Scaling up’ is concerned with using agile
methods for developing large software systems
that cannot be developed by a small team.
 ‘Scaling out’ is concerned with how agile
methods can be introduced across a large
organization with many years of software
development experience.
 When scaling agile methods it is essential to
maintain agile fundamentals
 Flexible planning, frequent system releases,
continuous integration, test-driven development and
good team communications. Chapter 3 Agile
software
development
42
Scaling up to large systems
 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
 Cross-team communication mechanisms have to
be designed and used. This should involve regular
phone and video conferences between team
members and frequent, short electronic meetings
where teams update each other on progress.
 Continuous integration, where the whole system is
built every time any developer checks in a change,
is practically impossible. However, it is essential to
maintain frequent system builds and regular
releases of the system. Chapter 3 Agile
software
development
43
 Scaling out to large
companies
 Project managers who do not have experience of agile
methods may be reluctant to accept the risk of a new approach.
 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.
 There may be cultural resistance to agile methods, especially in
those organizations that have a long history of using
conventional systems engineering processes.
Chapter 3 Agile
software
development
44
Key points
 A particular strength of extreme programming
is the development of automated tests before a
program feature is created. All tests must
successfully execute when an increment is
integrated into a system.
 The Scrum method is an agile method that
provides a project management framework. It
is centred round a set of sprints, which are
fixed time periods when a system increment is
developed.
 Scaling agile methods for large systems is
difficult. Large systems need up-front design
Chapter 3 Agile
software

and some documentation. development

45
Scrum

Scrum Proce ss Flow (use d wit h pe rm ission)

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 46
Summary
 Agile philosophy: Four Key issues: importance of self-
organizing teams, communication, change represents an
opportunity, rapid delivery for customer satisfaction
 XP: Four framework activities: planning, design, coding and
testing. Encourages frequent software releases to deliver
features prioritized by stakeholders
 Scrum: use of software process patterns each of which
defines a set of development tasks and allows the Scrum
team to construct a process that is well adapted to project
needs

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 47