Chapter 3

 Agile Development

Slide Set to accompany

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

2
What is
“Agility”?
 Effective (rapid and adaptive) response
to change
 Effective communication among all
stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in
control of the work performed
Yielding …
 Rapid, incremental delivery of software

3
Agility and the Cost of
Change

4
An Agile Process
 Is driven by customer descriptions 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

5
Agility Principles - I
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.
6
Agility Principles - II
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.

7
Human Factors
 the process molds to the needs of the people and
team, not the other way around
 key traits must exist among the people on an
agile team and the team itself:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.

8
Extreme Programming (XP)
 The most widely used agile process,
originally proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories”
by listening
 Customer assigns a value to the story.
 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 9
Extreme Programming
(XP)
 XP Design
 Follows the KIS principle
 Encourage the use of CRC cards (see Chapter 8)
 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
story before coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily (whenever code is
modified)
 “Acceptance tests” are defined by the customer and
executed to assess customer visible functionality

10
Extreme Programming (XP)
sp ike so lut io ns
simp le d esig n
p ro t o t yp es
CRC card s
user st o ries
values
accep t ance t est crit eria
it erat io n p lan

refact o ring

p air
p ro 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 inuo us int eg rat io n

accep t ance t est ing

11
Adaptive Software
Development
 Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements
gathering
 Emphasizes “learning” throughout the
process

12
Adaptive Software
Development
ad ap t ive cycle p lanning Req uirement s g at hering
uses m issio n st at em ent JAD
pro ject co nst raint s m ini-sp ecs
b asic requirem ent s
t ime-b o xed release p lan

Release
soft wa re incre m e nt
adjus t m e nt s f or subs e que nt cy cle s
co mp o nent s imp lement ed / t est ed
fo cus g ro up s fo r feed b ack
fo rm al t echnical reviews
p o st mo rt ems

13
Dynamic Systems Development
Method
 Promoted by the DSDM Consortium (
www.dsdm.org)
 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for
acceptance of deliverables.
• Iterative and incremental development is necessary to converge
on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.

14
Dynamic Systems Development
Method

DSDM Life Cycle (with permission of the DSDM consortium)

15
Scrum
 Originally proposed by Schwaber and
Beedle
 Scrum—distinguishing features
 Development work is partitioned into
“packets”
 Testing and documentation are on-going as
the product is constructed
 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

16
Scru
m

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

17
Crystal
 Proposed by Cockburn and Highsmith
 Crystal—distinguishing features
 Actually a family of process models that
allow “maneuverability” based on problem
characteristics
 Face-to-face communication is
emphasized
 Suggests the use of “reflection
workshops” to review the work habits of
the team

18
Feature Driven
Development
 Originally proposed by Peter Coad et al
 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued function that can
be implemented in two weeks or less.”
 Uses a feature template
• <action> the <result> <by | for | of | to> a(n)
<object>
 A features list is created and “plan by
feature” is conducted
 Design and construction merge in FDD

19
Feature Driven
Development

Reprinted with permission of Peter Coad

20
Agile
Modeling
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling
principles
 Model with a purpose
 Use multiple models
 Travel light
 Content is more important than
representation
 Know the models and the tools you use to
create them
 Adapt locally

21