Agile Programming9 OCTOBER 2013

History

1960’s

60’s “Cowboys” wrote software anyway that they couldDifference between best programmers and worst as high as 28:1

(many sources)Start of the “software crisis”

1968Edsger Dijkstra, “GOTO Statement Considered Harmful” (CACM)Recognition that rules can improve the average programmer

Structuring Software Development

Few rules helped immenselyGood rules and practices developed over the 70’s

and 80’sIf 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 practicesLarge documents and people to manage them

Rise of the project manager

“Honored in the breach”More large projects and more late or failed

projects1995 Standish Group StudyJerry Saltzer SOSP 1999

Agile Methodologies: Backlash

Agile Methodologies

Keep only those rules and processes that helpAntidote to bureaucracyLicense to hack

Key characteristicsAdaptivePeople-oriented

Agile Manifesto

February 2001 Representatives from

Extreme Programming SCRUM

DSDMAdaptive Software Development

Crystal Feature-Driven Development

Pragmatic Programming

SCRUMWITH ACKNOWLEDGEMENT TO MIKE COHN FROM MOUNTAIN GOAT SOFTWARE, LLC

We’re losing the relay race

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.

“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 requirements.”

•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 in 100 words

Characteristics

Self-organizing teamsProduct progresses in a series of month-long

“sprints”Requirements captured in “product backlog”No specific engineering practices prescribedUses 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 duration is 2–4 weeks or a calendar month at most

A constant duration leads to a better rhythmProduct is designed, coded, and tested during

the sprint

Sequential vs. overlapping development

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Rather than doing all of one thing at a time... ...Scrum teams do a

little of everything all the time

Requirements

Design Code Test

No changes during a sprint

Plan sprint durations around how long you can commit to keeping change out of the sprint

Change

Scrum framework

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

The teamTypically 5-9 peopleCross-functional:

Programmers, testers, user experience designers, …

Members should be full-timeMay be exceptions (e.g., database administrator)

Sprint planning meeting

Sprint prioritization• Analyze and evaluate

product backlog• Select sprint goal

Sprint planning

• Decide how to achieve sprint goal (design)

• Create sprint backlog (tasks) from product backlog items (user stories / features)

• Estimate sprint backlog in hours

Sprintgoal

Sprintbacklog

Business conditions

Team capacity

Product backlog

Technology

Current product

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 scrumDaily15-minutesStand-up

Not for problem solvingWhole world is invitedOnly team members, Scrum Master, product owner talkHelps avoid other unnecessary meetings

Everyone answers 3 questions

not status for the ScrumMastercommitments in front of peers

What did you do yesterday?1

What will you do today?2

Is anything in your way?3

A sample product backlog

Backlog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room)

8

Improve exception handling 8

... 30

... 50

Hours

40

30

20

10

0Mon Tue Wed Thu Fri

TasksCode the user interfaceCode the middle tier

Test the middle tier

Write online help

Mon8

16

8

12

Tues Wed Thur Fri4

12

16

7

11

8

10

16 8

50

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 has a right toClear requirements and prioritiesDetermine how long a requirement will

takeRevise estimatesAlways produce quality code

XP Bills of Rights

Customer has a right toAn overall planSee progress in a running systemChange requirements and prioritiesBe informed of changes to schedule

and have input as to how to adaptCancel in the middle and still have

something to show for the investment

XP Value System

Communication Focus on people, not documentation

Simplicity Of 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 estimate by story Stories basis for iteration

Used to build acceptance tests Remember that correctness equals meeting

requirements

System Metaphor

Initial system design

Spikes

Technology explorationsFocus on high risk itemsTypically considered throw-away code

If 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 and training Code 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 of projectsHigh riskPoorly understood requirements

TeamSmall size: 2 to 12Needs to include customer

Automated testingTiming issue

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