Agile Programming
Project noise level
Far from
Agreement
Requirements
Anarchy
Technology
Far from
Certainty
Source: Strategic Management and Organizational
Dynamics by Ralph Stacey in Agile Software
Development with Scrum by Ken Schwaber and Mike
Beedle.
Simple
Close to
Certainty
Close to
Agreement
Complex
History: Quick Review
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
 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.
Scrum origins
•
•
•
•
Jeff Sutherland
• Initial scrums at Easel Corp in 1993
Ken Schwaber
• Scrum presented at OOPSLA 95 with
Sutherland
Mike Beedle
• Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002
Characteristics
 Self-organizing
teams
 Product progresses in a series of 2-week to
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.
Unified (Software Development) Process
 Iterations
within phases
 4 phases and core workflows for each
Inception
Requirements
Analysis
Design
Implementation
Test
Elaboration
Construction
Transition
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
Product owner

Define the features of the product

Decide on release date and content

Be responsible for the profitability of the product
(ROI)

Prioritize features according to market value

Adjust features and priority every iteration, as
needed

Accept or reject work results
The ScrumMaster
•
Represents management to the project
•
Responsible for enacting Scrum values and practices
•
Removes impediments
•
Ensure that the team is fully functional and productive
•
Enable close cooperation across all roles and functions
•
Shield the team from external interferences
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
The sprint review
•
Team presents what it accomplished during the sprint
•
•
demo of new features or underlying architecture
Informal
•
2-hour prep time rule
•
No slides
Whole team participates
• Invite the world
•
Sprint retrospective
 Periodically
look at what is and is not working
 Typically 15–30 minutes
 Done after every sprint
 Whole team participates
 ScrumMaster
 Product
owner
 Team
 Possibly
customers and others
Product backlog: User Stories
•
•
•
•
•
The requirements
A list of all desired work
on the project
Ideally expressed such
that each item has value
to the users or customers
of the product
Prioritized by the product
owner
Reprioritized at the start
of each sprint
Sprint Backlog: How
Breaks
the user
story down into
tasks
Burn-Down Chart Tracks Remaining
Effort
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