Extreme Programming and Scrum - Getting Started With Agile Software Development

Extreme Programming and
Scrum - Getting Started

with Agile Software
Development
Kyle R. Larson
[email protected]
Advanced Technologies Integration, Inc.

www.atico.com
Agenda
The Development Problem

Successful Models and Methods
Agile Project Management
Scrum
Extreme Programming
How to Get Started
The Problem: The Chaos Report
Started in 1994, studied over 35,000

application development projects
In 2000:
Source: Standish “ Chaos” Report, Jim Johnson lecture at XP2002 conference,

http://www.xp2003.org/xp2002/talksinfo/johnson.pdf
What is Needed: DuPont Study
25% of features are needed

75% of features are “ nice to have”
Source: Jim Johnson lecture at XP2003 conference,

http://www.xp2003.org/xp2002/talksinfo/johnson.pdf
Lifecycle Costs
Up to 80% of software lifecycle cost, the total

cost of ownership (TCO), is in maintenance,
not first development
Focusing on “ abilities” is critical to ROI:
maintainability, extensibility, adaptability,
scalability, and most importantly
understandability (usability, readability,
testability)
Agenda

Scrum
Extreme Programming
How to Get Started
Agile Methods
Extreme Programming (XP) (Kent Beck,
Ward Cunningham, Ron Jeffries)
Scrum (Jeff Sutherland, Mike Beedle, Ken
Schwaber)
DSDM – Dynamic Systems Development
Method (Community owned)
Crystal (Alistair Cockburn)
ASD – Adaptive Software Development (Jim
Highsmith)
XBreed (Mike Beedle)
All Agile Methods
Maximize value by minimizing anything that

does not directly contribute to product
development and delivery of customer value
Respond to change by inspecting and
adapting
Stress evolutionary, incremental
development
Build on success, not hope
We’ve Seen It Before
Lean Manufacturing (1990, Toyota)

Agile Manufacturing
Just-in-time JIT
Common goals include:
Reduce Cycle Time
Maximize Quality
Reduce Costs
Lean
Lean means prioritize and optimize everything

to deliver value to the customer
One common technique: Postpone decisions
until the last responsible moment. Live with
uncertainty but define, communicate, and
manage it
Lean Manufacturing and the Toyota Production System, SAE International
Lean Software Development: An Agile Toolkit,

Mary & Tom Poppendieck, 2003
Scrum
Term in rugby to get an out-of-

play ball back into play
Term used in Japan in 1987 to
describe hyper-productive
development
Used by Ken Schwaber and
Mike Beedle to describe their
Agile methodology
Extreme Programming
A collection of best practices –

each done to the “ extreme”
Sounds extreme, but very
disciplined
Created by Kent Beck, Ward
Cunningham, Ron Jeffries
Scrum with Extreme Programming
SCRUM
Project Management
Best Practices
Scrum works
EXTREME
well as a
PROGRAMMING
Mostly Technical
wrapper around
Best Practices
Extreme
Programming
Agile Independence
Not created by any single company, but by a
group of software industry experts to find
“ better ways of developing software by doing
it and helping others do it.” *
Agile Principles:
highest priority is customer satisfaction
welcomes changing requirements
frequently deliver working software
advocates close collaboration and rapid feedback
reinforces “ inspect and adapt”
* www.agilealliance.org
Key PM Difference
Defined Project Management

vs.
Empirical Project Management
Defined PM
Assumes we can predict how the project will
unfold – assumes very little uncertainty
Time to complete and costs predictable
Uses work breakdown structure
Manages to a static plan
Primary participants: development team
Success; On Time & On Budget
Empirical PM
Software and systems construction is a
discovery process – manages uncertainty
Focuses on value/cost tradeoffs
Plan is volatile; use discoveries to
reprioritize and adjust
Primary participants: project steering team
Success; Delivering good value in
reasonable time
PM End-Game
Almost all projects eventually revert to empirical PM

Both Are Needed
Defined PM works because many things in a
project are deterministic.
Defined model provides constraints:
“ deliver not the best solution, but the best we can
afford”
Entire Project
Defined Empirical
Empirical PM Strategy
Early estimates of cost and value, tied to

business processes
Deliver subsets of functionality prioritized
by business value
Reassess and re-plan to fit resources,
schedule, and discoveries
Agile PM Concepts
Software construction is a discovery

process
Not the best solution; the affordable
solution
Invent successful outcomes
Agenda

Scrum
Extreme Programming
How to Get Started
Scrum Overview
Empirical management and control process

for projects and products
Widely used since 1990’ s
Wraps existing engineering practices
Manages noise, allows overhead to wither
Simple, common sense
Delivers business functionality in 30 days
Scalable
Scrum Scheduling and Tracking
Scrum Roles
Product Owner
Team
Scrum Master
Scrum Roles – Product Owner
Single person who owns, maintains,

prioritizes Product Backlog
Empowered to make decisions for customers
and users
Responsible for vision, ROI, and releases of
product
Attends Sprint planning and Sprint review
meetings
Scrum Roles - Team
Self-organizing, cross-functional, no formal

roles
Seven plus or minus two people
Best experts available
Cost and commit to work, and responsible for
delivering
Full autonomy and authority to deliver during
Sprint
Scrum Roles – Scrum Master
Project manager, Coach, and/or Player-Coach

Responsible for process and maximizing team
productivity
Sets up and conducts meetings
Sprint Planning
Daily “ Scrum”
Sprint Release
Agenda

Scrum
Extreme Programming
How to Get Started
XP Definitions
Kent Beck’ s idea of turning the knobs on all the

best practices up to 10.
Optimizing the “ Circle of Life” by hitting the
sweet-spot of practices that self-reinforce and
become more than the sum of the parts (synergize).
XP Circle of Life
Customer Defines Value
1
Developers Developers
Build Value 4
2 Estimate Cost
Customer Chooses Value

Cost-of-Change Curves
Flattening cost of change curve is both enabled

by and exploited by Extreme Programming (XP)
The Four XP Values
Simplicity  Feedback
 Simplest thing that could  Testing
possibly work  Experimenting
 YAGNI: you aren’ t going to need it  Delivering
 Communication  Courage
 Developers  Trust
 Users  History
 Customers
 Testers
 Code
The Four XP Variables
 Quality  Schedule
 Internal high, fixed  Fixed-length,
short iterations
 Cost
 People-Time
 Scope
 Mythical Man-
 Negotiable
Month (F. Brooks)
Twelve XP Practices
1. Planning Game 7. Collective Ownership

2. Short Releases 8. Continuous Integration
3. Simple Design 9. On-site Customer
4. Testing 10. Sustainable Pace
5. Refactoring 11. Metaphor
6. Pair Programming 12. Coding Standards
1. Planning Game
 Release Planning: Define and estimate higher-

level features down to about 5-10 days effort
each. Customer lays features in fixed-length
iteration schedule.
 Iteration Planning: Same, but to 3 or less days
effort & detailed story cards within next
iteration.
 Simple to steer project towards success.
2. Short Releases
 Deliver business value early and often

 Do not slip iteration release dates
 adjust scope within an iteration, never time or
quality
 Small, stable teams are predictable in short
time-frames
3. Simple Design
 XP Mantra: “ The simplest thing that could

possibly work” .
 Meet current, minimum business
requirements only. Avoid anticipatory
design.
 YAGNI – You Aren’ t Going to Need It
4. Testing
 Automated unit tests for every entity.

 Automated acceptance tests for every story /
requirement.
 All unit tests pass 100% before checking in a
feature.
 Test-First, in small increments:
1. Write the test
2. Prove it fails (red-bar)
3. Code until it passes (green-bar)
5. Refactoring
 Refactoring: changing internal structure

without changing external behavior
 Remove duplication. “ Once and Only
Once” , “ Three strikes and your out” .
 Leaves code in simplest form.
 When change is hard, refactor to allow
change to be easy, testing as you go, then add
change.
6. Pair Programming
 Two heads are better than one, especially in

an open lab environment (colocation)
 Earliest possible code inspections
 Earliest possible brainstorming
 Better quality at lower cost
 Driver/Navigator
 Peer pressure reinforces discipline
7. Collective Ownership
 Interchangeable programmers
 Team can go at full speed
 Can change anything, anytime, without
delay
8. Continuous Integration
 Avoids “ versionitis” by keeping all the
programmers on the same page
 Integration problems smaller, taken one
at a time
 Eliminates traditional, high-risk
integration phase
9. On-site Customer
 Customer/User liaisons are team-members

 Available for priorities, clarifications, to
answer detailed questions
 Reduces programmer assumptions about
business value
 Shows stakeholders what they pay for, and
why
10. Sustainable Pace
 Tired programmers make more mistakes

 Better to stay fresh, healthy, positive, and
effective
 XP is for the average programmer, for the
long run
11. Metaphor
 Use a “ system of names”

 Use a common system description
 Helps communicate with customers, users,
stakeholders, and programmers
12. Coding Standards
 All programmers write the same way

 Rules for how things communicate with
each other
 Guidelines for what and how to document
XP Practices Support Each Other
On-site Customer Planning game
40 Hour Week
Metaphor
Simple Design
Refactoring
Short Releases
Pair Programming Testing
Coding Standards
Collective Ownership Continuous Integration
Source: Beck, Extreme Programming Explained: Embrace Change, 1999

Agenda
 The Development Problem

 Successful Models and Methods
 Agile Project Management
 Scrum
 Extreme Programming
 How to Get Started
Practices to Start With
 Talking to, instead of about, people, in their

language, considering their perspective
 Customer, developer, mgmt., Q/A, user, finance,
marketing, sponsor
 Frequent Integration (Config. Mgmt., Check-in >
daily)
 Testing (Unit, Integration, System, Feature)
 Release Management (build-box, sandboxes,
labeled releases, migrations)
See www.balancedagility.com
How to Explore
Web
 Agile Alliance:
www.agilealliance.org
 Scrum:
www.controlchaos.com
 Don Well’ s XP Introduction:
Extreme Programming: A Gentle Introduction
www.extremeprogramming.org
How Not to Get Started
1. Read some
2. Discuss some
3. Start an approach without advice from those with
previous experience
4. Draw conclusions from experience
 Can work this way, but its risky
 Often fails to define and leverage success
criteria. Often unrealistic expectations.
 Inexperience decreases chances of success
How Best to Get Started
 Get help from experienced people for:
 Readiness assessments
 Approach selection
 Pilot / skunkworks vs. changing existing process
 Mission-critical vs. stand-alone
 Selective best practices vs. complementary set vs. all
best practices
 Measurement and success criteria
 Identifying and delivering targeted training, mentoring,
coaching, project management / stewardship
Agile Best Practice
Adaptations
 How long should iterations and releases be?
 How does development work with QA?
 How do our stakeholders work with multiple
customers?
 How should our teams be structured?
 How do we work with regulatory agencies?
 How does this work with legacy systems?
 How does this work with Use Cases and RUP?
 How do we ensure architectural vision and usage.
Agile Summary
 Agile = try, inspect, adapt, repeat

 Highly focused, empowered teams
 Collaborate with all stakeholders
 Optimize and automate feedback
 Deliver real value early and often
 Use feedback to evaluate, ruthlessly prioritize,
and re-plan
 Delivers high quality, ensures flexibility
 Evaluate business value of everything
Agile Future
 Agile in most dev. orgs, in few IT orgs.

 Agile is here to stay, past early adopters, into
early majority
 “ Agile” is loosing meaning
 XP is developer-focused, now Q/A friendly,
needs to become customer/user friendly
 Scrum is still “ pure” , but there are now
tools… CMM and RUP were “ pure” to
start…
 All camps need to sell business value, in

Extreme Programming and Scrum - Getting Started With Agile Software Development

Uploaded by

Copyright:

Available Formats

Extreme Programming and Scrum - Getting Started With Agile Software Development

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extreme Programming and Scrum - Getting Started With Agile Software Development

Uploaded by

Copyright:

Available Formats

Extreme Programming and

Scrum - Getting Started

Advanced Technologies Integration, Inc.

The Development Problem

Started in 1994, studied over 35,000

Source: Standish “ Chaos” Report, Jim Johnson lecture at XP2002 conference,

25% of features are needed

Source: Jim Johnson lecture at XP2003 conference,

Up to 80% of software lifecycle cost, the total

The Development Problem

Maximize value by minimizing anything that

Lean Manufacturing (1990, Toyota)

Lean means prioritize and optimize everything

Lean Software Development: An Agile Toolkit,

Term in rugby to get an out-of-

A collection of best practices –

Defined Project Management

Almost all projects eventually revert to empirical PM

Early estimates of cost and value, tied to

Software construction is a discovery

The Development Problem

Empirical management and control process

Single person who owns, maintains,

Self-organizing, cross-functional, no formal

Project manager, Coach, and/or Player-Coach

The Development Problem

Kent Beck’ s idea of turning the knobs on all the

Customer Chooses Value

Flattening cost of change curve is both enabled

1. Planning Game 7. Collective Ownership

 Release Planning: Define and estimate higher-

 Deliver business value early and often

 XP Mantra: “ The simplest thing that could

 Automated unit tests for every entity.

 Refactoring: changing internal structure

 Two heads are better than one, especially in

 Customer/User liaisons are team-members

 Tired programmers make more mistakes

 Use a “ system of names”

 All programmers write the same way

On-site Customer Planning game

Pair Programming Testing

Source: Beck, Extreme Programming Explained: Embrace Change, 1999

 The Development Problem

 Talking to, instead of about, people, in their

 Agile = try, inspect, adapt, repeat

 Agile in most dev. orgs, in few IT orgs.

You might also like