Agile Programming

Simple

ComplexAnarchy

Complicated

Technology

Requirements

Far fromAgreement

Close toAgreement

Close to

Certainty

Far from

Certainty

Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

Project noise level

History: Quick Review

1960’s60’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 DevelopmentFew 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 MethodologiesKeep only those rules and processes that

helpAntidote to bureaucracyLicense to hack

Key characteristicsAdaptivePeople-oriented

Agile Manifesto

February 2001 Representatives from

Extreme Programming SCRUMDSDMAdaptive Software Development Crystal Feature-Driven DevelopmentPragmatic 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

• 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

Scrum origins

CharacteristicsSelf-organizing teamsProduct progresses in a series of 2-week to

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

Unified (Software Development) ProcessIterations within phases4 phases and core workflows for each

Requirements

Analysis

Design

Implementation

Test

ElaborationInception Construction Transition

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

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 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 consideredAs 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

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 retrospectivePeriodically look at what is and is not workingTypically 15–30 minutesDone after every sprintWhole team participates

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

takeRevise estimatesAlways produce quality code

XP Bills of RightsCustomer has a right to

An 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

SpikesTechnology 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

PlanningManaging

Designing Coding

Testing

When to Use XPTypes of projects

High 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