Introduction to Agile/Extreme

Programming
Matt Ganis, Senior Technical Staff Member
(Certified Scrum Master)
IBM – Hawthorne, New York
[email protected]
August 2007
Session 8061
Current slides at: http://webpage.pace.edu/mganis
 Agenda

• Overview of Agile
• What are some of the components/practices
• How is this different from what we do today
• Some hints/tips/suggestions

2
Definition of Agile1

Agile is an iterative and incremental (evolutionary) approach

to software development which is performed in a highly
collaborative manner with "just enough" ceremony that
produces high quality software which meets the changing
needs of its stakeholders.

1 http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
3
What is Agile ?

• XP, SCRUM, DSDM, Adaptive Software Development, Crystal, FDD

• February 2001 (Snowbird, UT)
• Agile Alliance

• Started as 17 methodology authors and practitioners

• Agile Manifesto Values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

http://www.agilemanifesto.org/

4
The “promise” of Agile

Iteration n
Iteration 1 Iteration 2

Within an iteration, stories Releases are composed of

At some point, there exists a
are created a number of iterations, as
deliverable, that delivers
the iterations progress,
In a planning game, stories enough value that the
stories are completed, and
are selected by the customer says “stop” since
new ones are introduced
customer based on value the remaining stories don’t
contribute sufficient value

Agile allows for faster deliverables at a lower cost (assuming the customer
decides, based on what they see, that a set of stories aren’t needed)
5
Why is Iterative development “good”?

Iteration 1 Iteration 2 Iteration 3

Further iterations

100%
d
la nne
’vep
w e
when
t h
Pa

6
What is Agile

• Agile Software methodologies and practices emphasize:

¾ Empirical process control

¾ Emergence
¾ Self-organization

• Agile methodologies span the spectrum between“hacking” and

“milestone plan-driven” development

• They are VERY disciplined

• VERY flexible
(like a gun, they can be quite effective and dangerous at the same time)

7
What is Agile?
(Incremental, Iterative, Adaptive)

• Incremental
• Build a system gradually
• See the system grow
• Demonstrating progress
• Iterative
• Multiple releases or check points during a project, each closer to the target
• Iterations include requirements development and testing
• Typical iterations are two weeks long
• Plan as you go
• Adaptive
• Goals change based on lessons from prior iterations, feedback and business
opportunities

8
Agile Methods

• Agile methods tend to fall into two categories:

¾ Engineering (the “how to do it”)

¾ Project Management (the “how to manage it”)

• Both operate in an iterative manner

9
Why Agile?

Organizations are interested in Agile development

• Forrester Research indicates that 2/3 of their clients are interested in

Agile capabilities to deliver more value to the business faster

• Clients are asking for it

• It has become even more popular in recent years due to easy-to-

follow publications and internet buzz

10
The demand for Agile development (cont)

• Many clients are struggling with application delivery issues

• Poor I/T relationship with the business

• Track record of poor project delivery
• Inability to deliver on-time, on-budget
• Inability to delivery solutions that meet the needs of the business
• Poor results with offshore delivery or seek to avoid offshore delivery
• Large project backlog

• Internal and external IBM delivery projects are interested in Agile

techniques to help address delivery excellence challenges

• Requirements often are not well-defined

• Speed time to deliver critical business functionality
• Reduce technical risk for first of a kind solutions

11
 Agile Survey2

2 Results of an Industry survey by Scott Ambler: http://www.ddj.com/dept/architect/191800169?pgno=1

12
How has Agile affected your productivity?
Survey says:

How has Agile affected your productivity?

13
How has Agile affected your quality of deployed systems?
Survey says:

How has Agile affected your quality of deployed systems?

14
How has Agile affected the stakeholders satisfaction?
Survey says:

How has Agile affected the stakeholders satisfaction?

15
Scrum (Project Management)

16
Scrum overview

Scrum is an iterative, incremental process for developing

any product or managing any work. It produces a
potentially shippable set of functionality at the end of every
iteration. It's attributes are:
¾An agile process to manage and control development work.
9A team-based approach to iteratively, incrementally develop systems and
products when requirements are rapidly changing
9 a way to detect and cause the removal of anything that gets in the way of
developing and delivering products.
9 Scrum is scalable from single projects to entire organizations. Scrum has
controlled and organized development and implementation for multiple
interrelated products and projects with over a thousand developers and
implementers.
17
Scrum (project management)

18
What is Extreme Programming
(engineering)

19
What is XP

• Extreme Programming (or XP) is a set of values, principles and

practices for rapidly developing high-quality software that
provides the highest value for the customer in the fastest way
possible

• It’s an “engineering” method in that it prescribes “HOW” to

create the code unlike SCRUM that talks about “how to manage
an agile project”

20
Some “Infrastructure”
definitions

21
Stories

• User requirements come to the development team in what we

call “Stories”

• These are short descriptions of what the customers would like to

see done – not specified in any technical language – but
represented as a “thought” or as an “idea”

22
What makes a “good” story
(from Bill Wake: http://www.xp123.com/xplor/xp0308/index.shtml)

Independent. If they are independent we can schedule and build them in any order. This allows
us to select stories with the highest value without worrying about all the expensive, low value
I dependent stories.
Negotiable - Remember that agile methods are typically variable in scope. That is the time line is
fixed (iteration length) and the quality and scope are varied. A story is a placeholder for a
N discussion. We need to be able to split, combine, tweak, clarify, etc stories at any time.
Value. Stories need to have real business value to the stakeholders. Typically this is the
customer although there are other stakeholders (including the development organization). They
V should be expressed in ways that the primary stakeholder can understand the value provided by
the story.
Estimate. If a story can't be estimated then the customer can't derive value or assign a priority to
it. We don't need a precise estimate or a guarantee that the estimate will never change.
E
Small. Having small stories is a result of estimable and negotiable. The larger the story the
harder it is to estimate, the less flexibility in negotiation.
S

Testable. Stories need to be testable, otherwise how do you know the story is complete?
T
23
“How fast can you go ?” - Your Velocity

• A project velocity is used to determine if the iteration is over booked or not.

• Total up the time estimates in ideal programming days of the tasks, this must not exceed the
project velocity from the previous iteration.

If the iteration has too

much then the
customer must choose
user stories to be put
off until a later iteration

24
XP Practices
XP is extreme in the sense that it
takes 12 well-known software
development "best practices" to an
extreme

• Planning Game • Pair Programming

• Small Releases • Collective code ownership
• Simple Design • Continuous Integration
• Continuous Testing • On-Site customer
• Refactoring • Coding standards
• 40-hour work week

25
Key Ideas

•Practices are synergistic and support each other

The more holes you “poke in the bucket” the less Agile you become

Two things remain “true”:

•Distance is expensive Agil

e
•Drives the need for a high degree of communication

•Schedules never slip

•Stories fall out, only to be done later

26
What is missing from traditional waterfall
methods ?

•Upfront requirements gathering and sign-off

(no need to commit early
•Upfront design documents (easy to retarget)
•Early costs amortized over life of project
•Intimidation: schedule, cost, or value

27
 What’s different ?

Requirements

Analysis

Architecture

Design

Code

Waterfall
Test

Deploy

Time

VS.

Start • Arch • Arch

Finish
• Arch
•User Design •User Design •User Design
•Development •Development •Development
•Customer •Customer •Customer
•DBA •DBA •DBA
•Deploy •Deploy •Deploy

Iterative
28
 What’s different ?
today we use Plan-driven methods

• Waterfall assumes requirements are understood up front and

are relatively stable
• Assumes software can be “manufactured”
• Emphasizes Big-Design Up Front (BDUF)
• Step-by-step execution
• Decouple architecture and design from coding and testing
• Different teams for
different aspects

29
“A day in the life of an XP team…”

• XP teams work in a series of fixed iteration cycles.

• Iterations typically last 1, 2 or 3 weeks each depending on the team. (A given team
will almost always use same the iteration size for every iteration.)
• At the beginning of each iteration, the team gets together with the
customer for a planning meeting. In that meeting, they go over the
features the customer wants done in that iteration, breaking each
feature down into individual engineering tasks.
• Individual developers then sign up for specific tasks, and estimate those tasks. No
developer is allowed to sign up for more work in the coming iteration than he
completed in the previous iteration.

30
“A day in the life of an XP team…” (cont)

• During the rest of the iteration, the team will implement the features
they signed up for, pair programming on all production code.

• All code is written test-first -- that is, the developers don't write any code until they
have a failing test case. The developers write unit tests to test individual classes
and subsystems. The customer provides functional or acceptance tests to validate
the features that the programmers are developing.

• At the end of the iteration (usually on a Friday), the programmers

deliver a working system to the customer. The system may not be
complete, but all functionality that is implemented works completely,
without bugs. The customer accepts delivery, and the team goes
home early. The next Monday everyone meets again to plan the next
iteration, and the cycle repeats itself.

31
 XP flow

Retrospective
Release
Plan New Velocity
St
or Unfinished
ie s
Work
New
Function
Iteration Latest
Velocity Development
Planning Version
Bug
Customer Fixes
Interaction
Bugs
Iteration
Plan Refactoring

32
 •

Using these techniques, the experience has shown that a better

quality of code is produced

why ?

33
Continuous Testing

Teams using agile methods work in short iterations to “grow” a

system. These methods require the whole team to focus on quality
throughout each of these iterations, ensuring that the system is built
on a sound foundation.
The system must be kept in a high-quality,
working condition at all times. With
software builds and integration taking
place on an hourly basis in some cases,
there simply is no time to perform
extensive manual tests. To accomplish this, the team must commit to
automating as much of the testing process as possible.

(Collective code ownership, Coding standards , Integration)

34
What is pair programming3?

Two programmers working side-by-side, collaborating on the same

design, algorithm, code or test. One programmer, the driver, has
control of the keyboard & mouse and actively implements the
program. The other programmer, the observer, continuously
observes the work of the driver to identify tactical
(syntactic, spelling, etc.) defects and
also thinks strategically about the
direction of the work.
3 Laurie Williams

(Collective code ownership, Small Releases, Simple Design, Small Release)

35
On-site customer

On-Site Customer describes the need to have on-site access to people,

typically users or their representatives, who have the authority
and ability to provide
information pertaining
to the system being built
and to make pertinent
and timely decisions
regarding the requirements,
and prioritization

(Continuous Integration, Small Releases, Pair Programming)

36
 In Summary

XP the practice of all of these ideas continuously:

• "If code reviews are good, we'll review code all the time
(pair programming)
• If testing is good, everybody will test all the time (unit testing), even the
customers
• If design is good, we'll make it part of everybody's daily business
(refactoring)
• If simplicity is good, we'll always leave the system with the simplest design
that supports its current functionality
(the simplest thing that could possibly work)
• If architecture is important, everybody will work defining and refining the
architecture all the time
• If integration testing is important, then we'll integrate and test several times
a day (continuous integration)
• If short iterations are good, we'll make the iterations really, really short ...
(the Planning Game)." 37
Thank you !

If you have any questions, please feel

free to contact me at:
[email protected]
(914) 784-5759
Or find these slides online at:

http://webpage.pace.edu/mganis

38