Agile Programming
9 OCTOBER 2013
History
1960’s
 60’s
 “Cowboys”
wrote software anyway that they could
 Difference
between best programmers and worst as high as 28:1
(many sources)
 Start
of the “software crisis”
 1968
 Edsger
Dijkstra, “GOTO Statement Considered Harmful” (CACM)
 Recognition
that rules can improve the average programmer
Structuring Software Development
 Few
rules helped immensely
 Good rules and practices developed over the 70’s
and 80’s
 If a few rules are good, more are better…
 Late 80’s, major focus on process as a key to quality
 ISO
9000 (first published 1987)
 Malcolm Baldrige National Quality Award (just celebrated 25th
anniversary)
Why not apply to software development?
 Companies
started codifying their practices
 Large documents and people to manage
them
 Rise
of the project manager
 “Honored
in the breach”
 More large projects and more late or failed
projects
 1995
Standish Group Study
 Jerry Saltzer SOSP 1999
Agile Methodologies: Backlash
Agile Methodologies
 Keep
only those rules and processes that help
Antidote
License
 Key
to bureaucracy
to hack
characteristics
Adaptive
People-oriented
Agile Manifesto

February 2001

Representatives from
Extreme Programming
SCRUM
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
SCRUM
WITH ACKNOWLEDGEMENT TO MIKE COHN FROM MOUNTAIN GOAT
SOFTWARE, LLC
We’re losing the relay race
“The… ‘relay race’ approach to product
development…may conflict with the goals
of maximum speed and flexibility. Instead
a holistic or ‘rugby’ approach—where a
team tries to go the distance as a unit,
passing the ball back and forth—may
better serve today’s competitive
Hirotaka Takeuchi and Ikujiro Nonaka, “The
requirements.”
New New Product Development Game”,
Harvard Business Review, January 1986.
Scrum in 100 words
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize
to determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
Characteristics
 Self-organizing
teams
 Product progresses in a series of month-long
“sprints”
 Requirements captured in “product
backlog”
 No specific engineering practices
prescribed
 Uses generative rules to create an agile
environment for delivering projects
The Process
© www.mountaingoatsoftware.com/scrum
Sprints
 Scrum
projects make progress in a series of
“sprints”
 Typical
at most
A
duration is 2–4 weeks or a calendar month
constant duration leads to a better rhythm
 Product
sprint
is designed, coded, and tested during the
Sequential vs. overlapping development
Requirements
Design
Code
Test
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Source: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review, January 1986.
No changes during a sprint
Change
Plan sprint durations around how long you can
commit to keeping change out of the sprint
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
The team
 Typically
5-9 people
 Cross-functional:
Programmers, testers, user experience designers, …
 Members
should be full-time
May be exceptions (e.g., database administrator)
Team
capacity
Sprint planning meeting
Sprint prioritization
Product
backlog
Business
conditions
• Analyze and evaluate product
•
backlog
Select sprint goal
Sprint
goal
Sprint planning
• Decide how to achieve sprint
Current
product
•
Technology
•
goal (design)
Create sprint backlog (tasks)
from product backlog items
(user stories / features)
Estimate sprint backlog in hours
Sprint
backlog
Sprint planning
Team selects items from product backlog they can commit to
 Sprint backlog is created
 Tasks are identified and each is estimated (1-16 hours)
 Collaboratively, not done alone by the ScrumMaster
 High-level design is considered

As a vacation
planner, I want to
see photos of the
hotels.
Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
The daily scrum
Daily
15-minutes
Stand-up
 Not
for problem solving
 Whole world is invited
 Only team members, Scrum Master, product owner talk
 Helps avoid other unnecessary meetings
Everyone answers 3 questions
What did you do yesterday?
What will you do today?
Is anything in your way?
1
2
3
 not status for the ScrumMaster
 commitments in front of peers
A sample product backlog
Backlog item
Allow a guest to make a reservation
As a guest, I want to cancel a
reservation.
As a guest, I want to change the dates of
a reservation.
As a hotel employee, I can run RevPAR
reports (revenue-per-available-room)
Estimate
3
5
3
8
Improve exception handling
8
...
30
...
50
Tasks
Mon Tues Wed Thur Fri
Code the user interface
Code the middle tier
Test the middle tier
Write online help
8
16
8
12
8
10
16
4
12
16
7
11
50
40
30
Hours
20
10
0
Mon
Tue
Wed
Thu
Fri
8
Scaling through the Scrum of
scrums
Extreme Programming
Extreme Programming

Complete development process

First code drop 2-3 weeks after start
(what is the start?)

Customer part of the development
team

Iterative development to the max

Derive requirements with customer
through hands-on experimentation

Agile methodology
XP Bills of Rights
 Developer
Clear
has a right to
requirements and priorities
Determine how long a requirement will take
Revise estimates
Always produce quality code
XP Bills of Rights
 Customer
An
has a right to
overall plan
See progress in a running system
Change requirements and priorities
Be informed of changes to schedule
and have input as to how to adapt
Cancel in the middle and still have
something to show for the investment
XP Value System

Communication
 Focus

Simplicity
 Of

on people, not documentation
process and code
Feedback
 Mechanism

to make useful progress
Courage
 To
trust in people
 (Bollinger:
what you would like to know about
software that your life depended on)
Extreme Programming Flowchart
http://www.extremeprogramming.org/
User Stories

Use cases

Written by customer

Used for planning
 Developers
 Stories

estimate by story
basis for iteration
Used to build acceptance tests
 Remember
that correctness equals meeting requirements
System Metaphor
Initial
system design
Spikes
 Technology
 Focus
on high risk items
 Typically
If
explorations
considered throw-away code
not, needs to be agreed to by the
whole team
Release Planning

Each iteration has its own plan
 Function
OR date (other is adjusted accordingly)
(Recall 4 variables: function, date, resources, quality)

Planning adapts as the project progresses
 Measure
project velocity
Number of user stories and tasks completed
 Next
iteration looks at planned vs. actual time
Allowed to plan last iteration’s number for this iteration
Iteration

Scope: all parts of the system
 Only
add functions needed for current user stories
Recommendation: 3 weeks
 Moving people around

 Backup
 Code
and training
is owned by the whole team
Pair programming
 Re-factoring

Pair Programming




Two people working at a single computer
Built-in backup and inspections
Collaboration builds better code
Mechanical model
One drives, the other talks
 Keyboard slides between the two


Logical model
One tactical, the other strategic
 Both think about the full spectrum but bring different
perspectives

Pair Programming Experiments
Typical numbers show the total manpower consumed not
very different
 Numbers range, but no more than ¼ additional manpower
 Implication: actual time is reduced
 Improved satisfaction also improves productivity
 Williams et al, “Strengthening the Case for Pair-Programming”

Refactoring

Each iteration adds just the function needed

If you continue to add new functions every two weeks,
code can get messy

Refactoring is the cleaning up of the code at the end of
the iteration

Critical to maintaining quality code

(Also applies to the design)

Difference between refactoring & rewriting?
Feedback Loops
The Rules of Extreme Programming
 Planning
 Managing
 Designing
 Coding
 Testing
When to Use XP
 Types
 High
of projects
risk
 Poorly
understood requirements
 Team
 Small
size: 2 to 12
 Needs
to include customer
 Automated
 Timing
issue
testing
What Makes a Project XP

Paradigm
see change as the norm, not the exception
 optimize for change


Values
communication, simplicity, feedback, and courage
 honor in actions


Power sharing
business makes business decisions
 development makes technical decisions


Distributed responsibility and authority


people make commitments for which they are accountable
Optimizing process
aware of process and whether it is working
 experiment to fix
 acculturate new team members

Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck
NOT everyone loves XP