Selecting An Agile Process - Mountain Goat Software...Selecting an Agile Process: Choosing Among the...

1

Selecting an Agile Process:Choosing Among the Leading Alternatives

Mike CohnSeptember 21, 2004

Slides copyright 2000-2004, Michael W. CohnAll slides copyright 2000-2004, Michael W. Cohn

My backgroundProgramming for 20 years

Author of User Stories AppliedAnd four programming books

Past consulting to Viacom, Fidelity Investments, Procter & Gamble, NBC, United Nations, Citibank, other smaller companiesFounding member and director of the Agile Alliance

2


Today’s agenda

Extreme ProgrammingScrumDSDMCrystal ClearFeature-Driven DevelopmentOvercoming common objections to agile


Extreme Programming (XP)The Three Extremos

Kent BeckWard CunninghamRon Jeffries

C3 Project

3


Characteristics“Turning all the dials up to 10”1-4 week iterationsUser storiesOn-site customerHeavy, heavy emphasis on testingDo the simplest thing possibleYou Aren’t Gonna Need It (YAGNI)


The Cost of change

Project Duration

Cos

t of C

hang

e

XP

Traditional Process

“The error [is] typically 100 times more expensive to correct in the maintenance phase than in the requirements phase.”

Software Engineering Economics, Barry Boehm, 1981, p. 40.

4


Customer practices

On-site customer

Small releases


Quality practicesMetaphor

Testing

Simple design

Refactoring

Pair programming

5


Project management practicesThe Planning Game

Sustainable pace

Collective ownership

Coding standards

Continuous integration


User storiesXP’s approach to requirementsShort statement of what’s needed

Card, Conversation and Confirmation

A user can cancel a reservation.

Users can see photos of the hotels.

A user can make a hotel reservation.

6


Planning in XP

Technical People

Business People

The Planning Game

Scope

Priority

Releas

e date

s

Releas

e com

posit

ion

Estimate

sCon

sequ

ence

s

Detaile

d sch

eduli

ng

Proces

s

Iteration 1 Iteration 2 Iteration 3


Choose XP if……you have loosely-defined or volatile requirements…you have or can develop strong engineering skills and practices…customers can be involved on a daily (hourly) basis

7


Scrum originsKen Schwaber

Main advocateOriginated with Jeff Sutherland

800 Certified ScrumMasters worldwideHarvard Business Review, 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.”


Characteristics30-day iterations called “sprints”Self-organizing teamsNo specific engineering practices prescribed

But many Scrum teams are adopting much of XP

Uses generative rules to create an agile environment for delivering projects

8


Scrum roles5-10 full-time individualsSelf-organizingChange composition only at end of sprint

Scrum team

Customer or user of the projectMakes prioritization decisionsProduct Owner

ScrumMasterNot quite the project managerRemoves impedimentsEnforces Scrum values


Overview

30 days“Sprint”

24 hours

Product BacklogAs prioritized by Product Owner

Sprint Backlog

Backlog tasksexpandedby team

Potentially shippableproduct increment

Daily ScrumMeeting

Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

No changes allowed during

the sprint

Designed, coded, and

tested during the sprint

9


Product backlogA list of all desired work on the project

Can be stories or engineering tasks

Prioritized by the Product Owner


Sprint BacklogTeam takes top items from Product Backlog

Creates engineering tasks

Team members sign upOnly the team can add items during the sprintWork is re-estimated as needed

10


Scrum meetingsFirst half includes Product Owner who explains high priority needsSecond half is team onlyCreate sprint backlog

Sprint planning

What did you do yesterday?What will you do today?What’s in your way?

Daily scrum

Sprint reviewTeam demos what was accomplished2-hour prep time ruleNo PowerPoint!Anyone can attend


Sprint Burndown ChartProgress

752 762664 619

304 264180

104200

100200300400500600700800900

5/3/200

2

5/5/200

2

5/7/2002

5/9/2002

5/11/200

2

5/13/200

2

5/15/2002

5/17/2002

5/19/2

002

5/21/200

2

5/23/200

2

5/25/2

002

5/27/2002

5/29/2002

5/31/2002

Date

Rem

aini

ng E

ffort

in H

ours

11


Scaling ScrumJeff Sutherland used Scrum at IDX with > 600 developersI’ve used it with > 100Scale with “MetaScrums” or “Scrum of Scrums”


Choose Scrum if…

Simple

Complicated

Anarchy

Complex

Close toCertainty

Far fromCertainty

Technology

Close toAgreement

Far fromAgreement

Req

uire

men

ts

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

…requirements are changing or emergent…you’re willing to let the team self-organize…you need a management framework more than a set of engineering practices…you need a proven, scalable agile process

12


DSDM

DynamicSystems Development Method


CharacteristicsHighly iterativeStrong emphasis on prototypingUses timeboxes to control scopeStrong focus on business value

13


Principles1. Active user involvement is imperative.

2. Teams must be empowered to make decisions.

3. The focus is on frequent delivery of products.

4. Fitness for business purpose is the essential criterion for acceptance of deliverables.

5. All changes during development are reversible.


Principles, continued6. Iterative and incremental development is

necessary to converge on an accurate business solution.

7. Requirements are baselined at a high level.

8. Testing is integrated throughout the lifecycle.

9. A collaborative and cooperative approach between all stakeholders is essential.

14


AgreeSchedule

Create Functional Prototype

ReviewPrototype

Identify Functional Prototype

FunctionalModel

Iteration

Implement

ReviewBusiness

User Approval &User Guidelines

TrainUsersImplementation

IdentifyDesign Prototype

AgreeSchedule

Create DesignPrototype

ReviewDesign

Prototype

Design & Build

Iteration

FeasibilityStudy

BusinessStudy

Three pizzas and a cheese


Iden

tify

& P

lan

An idealized timebox

Rev

iew

Iden

tify

& P

lan

Rev

iew

Iden

tify

& P

lan

Investigate

Rev

iew

ConsolidateRefine

Kick

off m

eetin

g

Kick

off m

eetin

g

15% 15%70%

15


Timeboxing requires prioritizationMoSCoW Rules

Must havefundamental to the system

Should haveimportant requirement with short-term workaround, would normally be mandatory on a less time-constrained project

Could havecan be left out of this increment

Want to have but won’t have this timeWould like to have this increment but can wait for a future increment


Choose DSDM if……the project has tight time constraints…the application is interactive or UI-intensive…you have clearly identifiable users…the project is small or can be made small by decomposing it…requirements can be prioritized…requirements are not clear or change frequently

16


Crystal ClearAlistair Cockburn

Project anthropologistInterviews project teams around the world

“Software development is a cooperative game of invention and communication.”

—Alistair Cockburn


The Crystal family

Essential Money(E)

Life(L)

Discretionary Money(D)

Comfort(C) C20

D20

E20

L40

C40

D40 D80

E80

C6

D6

E6

L6 L20

E40

C80

L80

Clear Yellow Orange Red

17


PropertiesDelivery to customers, not just iteratingDeliver to full user base every months

User viewings during interimFrequent delivery

Periodically think about your process:What works?What doesn’t?

Reflective improvement

Osmotic communication

Communication happens without thinkingPeople need to close to eachKeep an expert in earshot


PropertiesAbility to speak without fear of reprisal

Ignorance, inability or a mistakeA first step toward trust

Personal safety

Knowing what’s importantMinimizing (eliminating) other distractions

Focus

A place to deploy the frequent deliveriesRapid feedback on

delivered softwaredecisions

Up to date requirements

Easy access to expert users

18


Properties

Three technical requirements1. Automated testing2. Configuration management3. Frequent integrationBest teams combine all three into:

Continuous-integration-with-tests

Technical environment


Choose Crystal Clear if……you want to do a lot of the process definition yourself…you have a small, collocated team…requirements are mostly known or knowable in advance…project involves loss of Comfort of Discretionary Money, not Essential Money or Life

19


Feature-Driven DevelopmentOriginates in Java Modeling in Color with UML by Coad, Lefebvre and De Luca in 1999Jeff DeLuca

Main advocatePalmer and Felsing book in 2002


FeaturesServe as primary unit of work

Similar to XP stories or Scrum backlog itemsSmall enough to do in two weeks

Feature SetCollection of featuresAssigned to a Chief Programmer and her team

Major Feature SetA domain area, one or more Feature Sets

20


Example featuresA short description of an action of value to users of the system

Format<action> the <result> <by|for|of|to> a(n) <object>

Estimate the closing price of a stock.

Change the password for a user.

Calculate the total cost of an order.

Retrieve the room number of a guest.


Five processes

DevelopAn

OverallModel

Build aFeatures

List

Planby

Feature

Designby

Feature

Buildby

Feature

Sequential Iterative

21


Sample Development Plan

……………

Aug 2004AndrewView Internet rates for a hotelRatesReporting

……………

Sept 2004

JamesView future reservations for a competitive set

Future Reservations

Reporting

Sept 2004

TodView future reservations for a hotelFuture Reservations

Reporting

Sept 2004

ChrisUpdate a reservation for a guestReservationsInterfacing

Aug 2004ChrisCancel a reservation for a guestReservationsInterfacing

Aug 2004ChrisMake a reservation for a guestReservationsInterfacing

DateChief Programmer

FeatureFeature SetMajor Feature Set


VisibleProgress

Eight “Best Practices”Need all 8 to be FDD

FeatureTeams

DomainObject

ModelingDeveloping

ByFeature

Inspections

IndividualClass

Ownership

RegularBuilds

ConfigurationManagement

22


Tracking progress

65%

Aug 2002

Reservations(3)

65%

Tod

Work in Progress

Name of Chief Programmer

Completed

Attention

Not Yet Started

Name of Feature Set

Number of Features in Set

Percentage Complete

Target Completion Month


Choose FDD if……you are willing to trade some agility for a well-defined way of scaling…your organization has solid UML skills…most requirements are knowable in advance or somewhat stable…you do not view self-organizing teams as a critical success factor

23


Today’s agenda

Extreme ProgrammingScrumDSDMCrystal ClearFeature-Driven DevelopmentOvercoming common objections to agile


1. It only works with talented people

No, but you do need one “level three” developerCan a project with no level 3 developers work with ANY process?

Person learns to follow precise directions and get predictable results.1

Person learns that there are multiple techniques.2

Skills assimilated and can move between techniques without conscious thought.3

Source: Agile Software Development, Alistair Cockburn, p. 14.

24


2. It only works on trivial projects

IDXScrum with over 600 developersFDA regulated

CaterpillarLarge team, XP, multi-year

Other Scrum projectsISO 9001CMMI Level 3 per Mark Paulk of SEI

We don’t yet know what is possible


3. It’s not appropriate for all projects

OK, use it when you canWe don’t need a single process for all projects within a company

25


4. Agile is hackingMore emphasis on testing in XP than any other process I’ve seen

Most importantly, programmers embrace itPlanning is still part of the process

Scrum with two-week iterations:26 sprints per year;4 hours7 developer + 1 ScrumMaster26*4*8 = 832 hours of planning per year

“Don’t confuse more exact with better.”—Brian Marick


What to learn from agile processes

Communication is keyOn-site customer, programmers in shared spaceCommunicate in person, not via documents

Rapid feedbackCut out bureaucracy“Barely sufficient”Short increments

1 week to 3 months

26


What to learn from agile processes

Measure progress only by working codeCustomize the processAcknowledge the rapidly decreasing precision of plansYou Aren’t Gonna Need It (YAGNI)

Programmers won’t need all the architecture they designCustomers don’t need all the features

Measure success with ROI not KLOC


Where to go next?

www.mountaingoatsoftware.com/[email protected]

Scrum

www.agilealliance.comespecially Articles and Roadmap sections

www.mountaingoatsoftware.comAgile in General

www.mountaingoatsoftware.com/agileplanning groups.yahoo.com/agileplanningAgile Planning

27


Where to go next?

www.featuredrivendevelopment.comFDD

www.dsdm.orgDSDM

www.xprogramming.comc2.com/cgi/wiki?ExtremeProgrammingRoadmapextremeprogramming@yahoogroups.comhttp://www.extremeprogramming.org

XP

http://alistair.cockburn.us/crystalCrystal


For more on user stories

www.userstories.comgroups.yahoo.com/group/userstories

28


My contact information

[email protected]@computer.orgEmail

www.mountaingoatsoftware.comwww.userstories.com Websites

Selecting An Agile Process - Mountain Goat Software...Selecting an Agile Process: Choosing Among the...

Documents

Transcript of Selecting An Agile Process - Mountain Goat Software...Selecting an Agile Process: Choosing Among the...