xp and agile processes

Extreme Programming and Agile ProcessesGlenn VanderburgDelphi Consultants, [email protected] and Background

Copyright 2001 Delphi Consultants, LLC. ALL RIGHTS RESERVED

OutlineBrief overview of XPXP and traditional software engineeringThe agile process movementRecommended reading

Ill move quickly, but at the end Ill tell you where you can get these slides.


Extreme ProgrammingA software development processDesigned to focus on four things:

Coding, Testing, Listening, DesigningFeedback is built into the development practices, not bolted on.No phases: you do all four of those things all the time.


The Core XP PracticesRapid, fine feedback:Test-driven design (via unit and acceptance tests)On-site customerPair programmingShared Understanding:Planning gameSimple DesignSystem MetaphorCollective Code OwnershipCoding ConventionsContinuous process:Continuous integrationMerciless refactoringSmall, frequent releases

Developer Welfare:Forty-hour week


An Organic ProcessEach practice serves multiple purposes in the process as a whole.The processes are interdependent:

Each practice on its own is flawed and insufficient.Strengths of other practices compensate.


Many Implicit PracticesCaves & commonsFixed iterationsEngineering tasksWrite it on a cardSpike solutionsAll tests all the time

Promiscuous pairingYesterdays weatherTrack velocityTrack progressRegression test


The Most Common ObjectionsDont bother. It has worked, and it is working today. It can still fail for various reasons, but when it works, it works spectacularly well.That cant work!Everyone knows you cant build software that way!


Characteristics of Successful XP ProjectsVery rapid developmentExceptional responsiveness to user and customer change requestsHigh customer satisfactionAmazingly low error ratesSystem begins returning value to customers very early in the process


Common XP MisconceptionsNo written design documentation

Truth: no formal standards for how much or what kind of docs are needed.No design

Truth: minimal explicit, up-front design; design is an explicit part of every activity through every day.XP is easy

Truth: although XP does try to work with the natural tendencies of developers, it requires great discipline and consistency.


More MisconceptionsXP is just legitimized hacking

Truth: XP has extremely high quality standards throughout the processUnfortunate truth: XP is sometimes used as an excuse for sloppy developmentXP is the one, true way to build software

Truth: it seems to be a sweet spot for certain kinds of projects


XP and Software Engineering:Where Software Engineering Went Wrong


Where Im coming from I dont believe in The One True Process.

XP isnt right for every projectClassical SE methods arent wrong for every project, either.Ive never experienced a traditional software engineering process on a project for which it was well suited.

Copyright 2001 Delphi Consultants, LLC. ALL RIGHTS RESERVEDI have experienced SE methods on projects for which they were ill suited.Plus, Im not alone in what Im saying, and many who say the same thing have experienced these things.

Where Im going What we now call Software Engineering was a response to a particular problem in software development.Different responses are possible, and often preferable.Although Software Engineering works well for certain kinds of projects, it is inappropriate for the vast majority of software being developed today.


What I mean bySoftware EngineeringSoftware development processes that emphasize one or more of these things:

Exhaustive requirementsFinding and eliminating errors before they find their way to the codeExpensive process elements for measuring and tracking the process itselfExtensive elaboration, analysis, and verification of modelsCoding as a simple translation of the modelYes, I know this is a straw man.

Copyright 2001 Delphi Consultants, LLC. ALL RIGHTS RESERVEDThis is admittedly something of a straw man. Many in the SE field are more savvy than this, as you can see by looking at any of the journals or conference proceedings. But it is a good characterization of what industry perceives to be the mainstream of software engineering---the things that are taught to undergraduates, pushed by management and process consultants, and supported by tools.

This characterization encompasses well-known processes like TSP, PSP, and Cleanroom.

What I dont (necessarily) mean by Software EngineeringWaterfall lifecycle

The SE mainstream has embraced iterative and incremental development to some degree.


Software EngineeringBlunder #1Avoiding costly situations rather than optimizing.Measures used for avoidance cost more than the original problem points.


Cost of Errors Increases Through a Projects LifetimeProject PhaseCost of Errors


The Software Engineering SolutionTry to push changes as far toward the start of the process as possible:Project PhaseCost of Errors


Secondary EffectsThe measures used increase the cost of everything:Project PhaseCost of Errors


Budget Pressures Resist The budget pushes these costs back down through limits on manpower:Project PhaseCost of Errors


Budget Pressures Resist The budget pushes these costs back down through limits on manpower, which just pushes the schedule out.Project PhaseCost of Errors


The XP AnswerFind ways to make change cheaperFind inexpensive ways of avoiding errorsReduce overall cost of development


Software EngineeringBlunder #2Poor understanding of more mature engineering disciplinesTreats engineering as a methodical, replicable processResult: SE recommends gradual elaboration with limited feedback into earlier stages of development.

In iterative SE processes, this is done for every iteration.


The XP AnswerIn reality, engineering involves creativity, trial and error, iteration, experimentation, prototyping.Work that into the process with multiple tight feedback loops at all scales.


Software EngineeringBlunder #3Faulty analogy with engineering disciplines.Treats coding as analogous to building or manufacturing.Engineers try to avoid building or manufacturing anything until they are confident of their design (because those steps are costly).Result: SE recommends other costly steps including highly detailed models, model analysis, and careful inspection to ferret out errors before coding begins.


The XP AnswerCoding is the detailed (not the only) design activity.Manufacturing = the compilation and build process.

Iterative prototyping and testing are less expensive than all the careful analysis and inspection.Ask some engineers how many prototypes they would build if prototypes were free!


The Agile Process Movement


Other Agile ProcessesThe Crystal Methodology Family: crystalmethodologies.orgScrum: www.controlchaos.comAdaptive Software Development: www.adaptivesd.comDSDM (Dynamic System Development Method): www.dsdm.org


Manifesto forAgile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

Individuals and interactions over processes and tools;Working software over comprehensive documentation;Customer collaboration over contract negotiation;Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Copyright 2001 Delphi Consultants, LLC. ALL RIGHTS RESERVEDThe XP Gang:Scrum:Adaptive:Kent BeckMike BeedleJim HighsmithWard CunninghamKen SchwaberMartin FowlerJeff SutherlandJames GrenningRon JeffriesRobert C. Martin

FDD:DSDM:Crystal and MPP:Jon KernArie van BennekumAlistair Cockburn

Schlaer/Mellor:Independents:Steve MellorAndrew HuntBrian MarickDave Thomas

Essential ReadingThe Agile Manifesto

http://www.agilealliance.org/Agile Software Development, by Alistair CockburnAvailable 21 December 2001Draft available athttp://members.aol.com/humansandt/crystal/game/getasddraft.htmNo Silver Bullet: Essence and Accident in Software Design, by Fred Brooks

Reprinted in the 20th Anniversary Edition of The Mythical Man Monthhttp://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.htmlThe Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas


The XP Book SeriesExtreme Programming Explained: Embrace Change, by Kent BeckExtreme Programming Installed, by Ron Jeffries, Ann Anderson, and Chet HendricksonPlanning Extreme Programming, by Kent Beck and Martin FowlerExtreme Programming in Practice, by James Newkirk and Robert Martin

Extreme Programming Explored, by William WakeExtreme Programming Examined, by Giancarlo Succi and Michele MarchesiExtreme Programming Applied: Playing to Win, by Ken Auer and Roy Miller (available 12 October 2001)


Other Relevant ReadingWhat is Software Design?, by Jack W. Reeves

http://gosh.exeter.ac.uk/~cs98abh/archive/documents/what_is_software_design.htmlAdaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James HighsmithAgile Software Development with SCRUM, by Mike Beedle and Ken Schwaber (available 15 October 2001)DSDM: The Method in Practice, by Jennifer StapletonRefactoring: Improving the Design of Existing Code, by Martin FowlerSoftware Craftsmanship: The New Imperative, by Pete McBreenThe Deadline, by Tom DeMarco

A novel about project management.


That information again is Speaker:

Glenn VanderburgDelphi Consultants, [email protected]

North Texas XP Interest Group:

http://groups.yahoo.com/group/ntxp/

This talk:

http://www.delphis.com/Java/Talks/XProundtable/


I have experienced SE methods on projects for which they were ill suited.Plus, Im not alone in what Im saying, and many who say the same thing have experienced these things.Copyright 2000 Delphi Consultants, LLC. ALL RIGHTS RESERVEDThis is admittedly something of a straw man. Many in the SE field are more savvy than this, as you can see by looking at any of the journals or conference proceedings. But it is a good characterization of what industry perceives to be the mainstream of software engineering---the things that are taught to undergraduates, pushed by management and process consultants, and supported by tools.

This characterization encompasses well-known processes like TSP, PSP, and Cleanroom.Copyright 2000 Delphi Consultants, LLC. ALL RIGHTS RESERVEDThe XP Gang:Scrum:Adaptive:Kent BeckMike BeedleJim HighsmithWard CunninghamKen SchwaberMartin FowlerJeff SutherlandJames GrenningRon JeffriesRobert C. Martin

FDD:DSDM:Crystal and MPP:Jon KernArie van BennekumAlistair Cockburn

Schlaer/Mellor:Independents:Steve MellorAndrew HuntBrian MarickDave Thomas


xp and agile processes

Documents