Praise for Extreme Programming Explained, Second Edition

“In this second edition of Extreme Programming Explained, Kent Beck orga-nizes and presents five years’ worth of experiences, growth, and change revolv-ing around XP. If you are seriously interested in understanding how you andyour team can start down the path of improvement with XP, you must readthis book.”

—Francesco Cirillo, Chief Executive Officer, XPLabs S.R.L.

“The first edition of this book told us what XP was—it changed the way manyof us think about software development. This second edition takes it fartherand gives us a lot more of the ‘why’ of XP, the motivations and the principlesbehind the practices. This is great stuff. Armed with the ‘what’ and the ‘why,’we can now all set out to confidently work on the ‘how’: how to run ourprojects better, and how to get agile techniques adopted in our organizations.”

—Dave Thomas, The Pragmatic Programmers LLC

“This book is dynamite! It was revolutionary when it first appeared a few yearsago, and this new edition is equally profound. For those who insist on cook-book checklists, there’s an excellent chapter on ‘primary practices,’ but I urgeyou to begin by truly contemplating the meaning of the opening sentence inthe first chapter of Kent Beck’s book: ‘XP is about social change.’ You shoulddo whatever it takes to ensure that every IT professional and every IT man-ager—all the way up to the CIO—has a copy of Extreme ProgrammingExplained on his or her desk.”

—Ed Yourdon, author and consultant

“XP is a powerful set of concepts for simplifying the process of softwaredesign, development, and testing. It is about minimalism and incrementalism,which are especially useful principles when tackling complex problems thatrequire a balance of creativity and discipline.”

—Michael A. Cusumano, Professor, MIT Sloan School of Management, andauthor of The Business of Software

“Extreme Programming Explained is the work of a talented and passionatecraftsman. Kent Beck has brought together a compelling collection of ideasabout programming and management that deserves your full attention. Myonly beef is that our profession has gotten to a point where such common-sense ideas are labeled ‘extreme.’ . . .”

—Lou Mazzucchelli, Fellow, Cutter Business Technology Council

“If your organization is ready for a change in the way it develops software,there’s the slow incremental approach, fixing things one by one, or the fasttrack, jumping feet first into Extreme Programming. Do not be frightened bythe name, it is not that extreme at all. It is mostly good old recipes and com-mon sense, nicely integrated together, getting rid of all the fat that has accu-mulated over the years.”

—Philippe Kruchten, UBC, Vancouver, British Columbia

“Sometimes revolutionaries get left behind as the movement they started takeson a life of its own. In this book, Kent Beck shows that he remains ahead ofthe curve, leading XP to its next level. Incorporating five years of feedback, thisbook takes a fresh look at what it takes to develop better software in less timeand for less money. There are no silver bullets here, just a set of practical prin-ciples that, when used wisely, can lead to dramatic improvements in softwaredevelopment productivity.”

—Mary Poppendieck, author of Lean Software Development: An Agile Toolkit

“Kent Beck has revised his classic book based on five more years of applying andteaching XP. He shows how the path to XP is both easy and hard: It can bestarted with fewer practices, and yet it challenges teams to go farther than ever.”

—William Wake, independent consultant

“With new insights, wisdom from experience and clearer explanations of theart of Extreme Programming, this edition of Beck’s classic will help many real-ize the dream of outstanding software development.”

—Joshua Kerievsky, author, Refactoring to Patterns, and Founder, IndustrialLogic, Inc.

“XP has changed the way our industry thinks about software development. Itsbrilliant simplicity, focused execution, and insistence on fact-based planningover speculation have set a new standard for software delivery.”

—David Trowbridge, Architect, Microsoft Corporation

Extreme ProgrammingExplained

Second Edition

The XP SeriesKent Beck, Series Advisor

Extreme Programming, familiarly known as XP, is a discipline of the businessof software development that focuses the whole team on common, reachablegoals. Using the values and principles of XP, teams apply appropriate XP prac-tices in their own context. XP practices are chosen for their encouragement ofhuman creativity and their acceptance of human frailty. XP teams producequality software at a sustainable pace.

One of the goals of XP is to bring accountability and transparency to softwaredevelopment, to run software development like any other business activity.Another goal is to achieve outstanding results—more effective and efficientdevelopment with far fewer defects than is currently expected. Finally, XP aimsto achieve these goals by celebrating and serving the human needs of everyonetouched by software development—sponsors, managers, testers, users, andprogrammers.

The XP series exists to explore the myriad variations in applying XP. While XPbegan as a methodology addressing small teams working on internal projects,teams worldwide have used XP for shrink-wrap, embedded, and large-scaleprojects as well. The books in the series describe how XP applies in these andother situations, addressing both technical and social concerns.

Change has come to software development. However, change can be seen asan opportunity, not a threat. With a plan for change, teams can harness thisopportunity to their benefit. XP is one such plan for change.

Titles in the Series

Extreme Programming Applied: Playing to Win, Ken Auer and Roy Miller

Extreme Programming Explained, Second Edition: Embrace Change, Kent Beck with Cynthia Andres

Extreme Programming Explored, William C. Wake

Extreme Programming for Web Projects, Doug Wallace, Isobel Raggett, and Joel Aufgang

Extreme Programming Installed, Ron Jeffries, Ann Anderson, and Chet Hendrickson

Planning Extreme Programming, Kent Beck and Martin Fowler

Testing Extreme Programming, Lisa Crispin and Tip House

For more information, check out the series Web site at www.awprofessional.com/series/XP

Extreme ProgrammingExplainedSecond Edition

Embrace Change

Kent Beckwith Cynthia Andres

Boston

The author and publisher have taken care in the preparation of this book, but make no expressed orimplied warranty of any kind and assume no responsibility for errors or omissions. No liability isassumed for incidental or consequential damages in connection with or arising out of the use of theinformation or programs contained herein.

Publisher: John WaitEditor in Chief: Don O’Hagan Acquisitions Editor: Paul PetraliaManaging Editor: John FullerProject Editors: Julie Nahil and Kim Arney MulcahyCompositor: Kim Arney MulcahyManufacturing Buyer: Carol Melville

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases orspecial sales, which may include electronic versions and/or custom covers and content particular toyour business, training goals, marketing focus, and branding interests. For more information, pleasecontact:

U. S. Corporate and Government Sales(800) 382-3419corpsales@pearsontechgroup.com

For sales outside the U. S., please contact:

International Salesinternational@pearsoned.com

Visit us on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data

Beck, Kent.extreme programming explained: embrace change / Kent Beck with Cynthia Andres. — 2nd ed.

p. cm.Includes bibliographical references and index.ISBN 0-321-27865-8 (alk. paper)1. Computer software—Development. 2. eXtreme programming. I. Title.

QA76.76.D47B434 2004005.1—dc22

2004057463

Text copyright © 2005 Pearson Education, Inc.

Inside cover art copyright © 2004 by Kent Beck

All rights reserved. Printed in the United States of America. This publication is protected by copyright,and permission must be obtained from the publisher prior to any prohibited reproduction, storage in aretrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying,recording, or likewise. For information regarding permissions, write to:

Pearson Education, Inc.Rights and Contracts DepartmentOne Lake StreetUpper Saddle River, NJ 07458

Many of the designations used by manufacturers and sellers to distinguish their products are claimed astrademarks. Where those designations appear in this book and we were aware of a trademark claim, thedesignations have been printed in initial caps or all caps.

ISBN 0-321-27865-8Text printed in the United States on recycled paper at Courier in Stoughton, Massachusetts.

Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.

Tenth printing, January 2012

To CindeeWithout you, this book would still be about programmers hiding in acorner. Without you, I would still be one of those programmers.

This page intentionally left blank

Note To ProgrammersEven programmers can be whole people in the real world. XP is anopportunity to test yourself, to be yourself, to realize that maybe you’vebeen fine all along and just hanging with the wrong crowd.

This page intentionally left blank

xi

Contents

Foreword to the Second Edition ......................................................... xv

Foreword to the First Edition .......................................................... xvii

Preface ........................................................................................... xxi

Chapter 1 What is XP? ..................................................................1

Section 1 Exploring XP ........................................................9

Chapter 2 Learning to Drive ........................................................11

Chapter 3 Values, Principles, and Practices ...................................13

Chapter 4 Values .........................................................................17Communication ..................................................................18Simplicity ............................................................................18Feedback ............................................................................19Courage ..............................................................................20Respect ...............................................................................21Others ................................................................................21

Chapter 5 Principles ....................................................................23Humanity ...........................................................................24Economics ..........................................................................25Mutual Benefit ....................................................................26

xii Contents

Self-Similarity ......................................................................27Improvement ......................................................................28Diversity .............................................................................29Reflection ...........................................................................29Flow ...................................................................................30Opportunity .......................................................................30Redundancy ........................................................................31Failure ................................................................................32Quality ...............................................................................32Baby Steps ..........................................................................33Accepted Responsibility ......................................................34

Chapter 6 Practices .....................................................................35

Chapter 7 Primary Practices ........................................................37Sit Together ........................................................................37Whole Team .......................................................................38Informative Workspace ........................................................39Energized Work ..................................................................41Pair Programming ...............................................................42Stories ................................................................................44Weekly Cycle ......................................................................46Quarterly Cycle ..................................................................47Slack ...................................................................................48Ten-Minute Build ...............................................................49Continuous Integration ......................................................49Test-First Programming ......................................................50Incremental Design .............................................................51

Chapter 8 Getting Started ...........................................................55

Chapter 9 Corollary Practices ......................................................61Real Customer Involvement ................................................61Incremental Deployment ....................................................62Team Continuity .................................................................63Shrinking Teams .................................................................64Root-Cause Analysis ...........................................................64Shared Code .......................................................................66Code and Tests ...................................................................66Single Code Base ................................................................67

Contents xiii

Daily Deployment ...............................................................68Negotiated Scope Contract .................................................69Pay-Per-Use ........................................................................69

Chapter 10 The Whole XP Team ..................................................73Testers ................................................................................74Interaction Designers ..........................................................75Architects ............................................................................75Project Managers ................................................................76Product Managers ...............................................................77Executives ...........................................................................78Technical Writers .................................................................80Users ..................................................................................81Programmers ......................................................................81Human Resources ...............................................................81Roles ..................................................................................82

Chapter 11 The Theory of Constraints ..........................................85

Chapter 12 Planning: Managing Scope ........................................91

Chapter 13 Testing: Early, Often, and Automated ........................97

Chapter 14 Designing: The Value of Time ...................................103Simplicity ..........................................................................109

Chapter 15 Scaling XP ..............................................................111Number of People .............................................................111Investment ........................................................................113Size of Organization .........................................................113Time .................................................................................114Problem Complexity .........................................................115Solution Complexity .........................................................115Consequences of Failure ....................................................116

Chapter 16 Interview ................................................................119

Section 2 Philosophy of XP ............................................123

Chapter 17 Creation Story .........................................................125

Chapter 18 Taylorism and Software ............................................131

xiv Contents

Chapter 19 Toyota Production System .........................................135

Chapter 20 Applying XP ...........................................................139Choosing a Coach ............................................................143When You Shouldn’t Use XP ............................................144

Chapter 21 Purity .....................................................................145Certification and Accreditation ..........................................146

Chapter 22 Offshore Development ..............................................149

Chapter 23 The Timeless Way of Programming ...........................153

Chapter 24 Community and XP ................................................157

Chapter 25 Conclusion ..............................................................159

Annotated Bibliography .................................................................161

Index ............................................................................................175

xv

Foreword tothe Second Edition

Wow—the second edition. I cannot believe that five years have alreadypassed since the appearance of the first edition. When Kent pinged meto write a foreword to the second edition I asked him for a manuscriptversion with change bars. What a silly request—the book is a fullrewrite! In the second edition of XP Explained Kent revisits XP andapplies the XP paradigm—stay aware, adapt, change—to XP itself. Kenthas revisited, cleaned-up, and refactored every bit of XP Explained andintegrated many new insights. The result is XP Explained even betterexplained!

This is an excellent opportunity to reflect on how XP has influencedmy own software development. Shortly after the first edition of XPExplained I became involved in the Eclipse project and it is nowabsorbing all my software energy. Eclipse isn’t run under the pure XPflag. We follow agile practices; however, the XP influences are easy tospot. The most obvious one is that we have encoded several XP prac-tices directly into our tool. Refactoring, unit testing, and immediatefeedback as you code are now an integral part of our toolset. Moreover,since we are “eating our own dog food” we use these practices in ourday-to-day development. Even more interesting are the XP influencesone can spot in our development process. Eclipse is an open sourceproject and one of our goals is to practice completely transparent devel-opment. The rationale is simple; if you don’t know where the project isgoing you cannot help out or provide feedback. XP practices help us toachieve this goal.

xvi Foreword to the Second Edition

Here is how we apply some of these practices:

✧ Testing early, often and automated—To get a green check markfor our latest builds more than 21,000 unit tests have to pass.

✧ Incremental design—We invest in the design every day, but we havethe additional constraint that we need to keep our APIs stable.

✧ Daily deployment—Components deploy their code at least onceper day and develop on top of the deployed code to get immedi-ate feedback and to catch problems early.

✧ Customer involvement—We are lucky to have an active user com-munity that isn’t shy and provides us with continuous feedback.We listen and do our best to be responsive.

✧ Continuous integration—The latest code is built every night. Thenightly builds provide us with insights about cross-componentintegration problems. Once per week we do an integration buildwhere we ensure integrity across all components.

✧ Short development cycles—Our cycles are longer than the XP-sug-gested one week cycles, but the goals are the same. Each of our sixweek cycles ends in a milestone build which have become theheartbeat of our project. The goal of each milestone build is toshow progress (which keeps us honest) and to deliver it with ahigh enough level of quality that our community can really use itand provide feedback (which keeps us even more honest).

✧ Incremental planning—After a release we develop an embryonicoverall plan which we evolve throughout the release cycle. Thisplan is posted on our website early so that our user communitycan join the dialog. The exception is the milestones, which arefixed in the first planning iteration since they define the heartbeatof our project.

Despite the fact that we have not adopted XP in its entirety, we aregetting a lot out of the above XP practices. In particular, they help us toreduce our development stress! All these practices, underpinned by astrong team committed to shipping quality software on time, are ourkeys to hitting the projected milestones and ship dates with precision.

Foreword to the Second Edition xvii

Kent is continuing to challenge my views on software development.While reading the book I’ve discovered several practices that I will addto my try-list. I suggest you do the same and accept the XP invitationto improve the way you develop software and to create outstandingsoftware.

Erich GammaSeptember 2004

This page intentionally left blank

xix

Foreword tothe First Edition

Extreme Programming (XP) nominates coding as the key activitythroughout a software project. This can’t possibly work!

Time to reflect for a second about my own development work. Iwork in a just-in-time software culture with compressed release cyclesspiced up with high technical risk. Having to make change your friendis a survival skill. Communication in and across often geographicallyseparated teams is done with code. We read code to understand new orevolving subsystem APIs. The life cycle and behavior of complex objectsis defined in test cases, again in code. Problem reports come with testcases demonstrating the problem, once more in code. Finally, we con-tinuously improve existing code with refactoring. Obviously our devel-opment is code-centric, but we successfully deliver software in time, sothis can work after all.

It would be wrong to conclude that all that is needed to deliver soft-ware is daredevil programming. Delivering software is hard, and deliv-ering quality software in time is even harder. To make it work requiresthe disciplined use of additional best practices. This is where Kent startsin his thought-provoking book on XP.

Kent was among the leaders at Tektronix to recognize the potentialof man in the loop pair programming in Smalltalk for complex engineer-ing applications. Together with Ward Cunningham, he inspired much ofthe pattern movement that has had such an impact on my career. XPdescribes an approach to development that combines practices used bymany successful developers that got buried under the massive literature

xx Foreword to the First Edition

on software methods and process. Like patterns, XP builds on best prac-tices such as unit testing, pair programming, and refactoring. In XPthese practices are combined so that they complement and often controleach other. The focus is on the interplay of the different practices, whichmakes this book an important contribution. There is a single goal todeliver software with the right functionality and hitting dates. WhileOTI’s successful Just In Time Software process is not pure XP, it hasmany common threads.

I’ve enjoyed my interaction with Kent and practicing XP episodes ona little thing called JUnit. His views and approaches always challengethe way I approach software development. There is no doubt that XPchallenges some traditional big M approaches; this book will let youdecide whether you want to embrace XP or not.

Erich GammaAugust 1999

xxi

Preface

The goal of Extreme Programming (XP) is outstanding software devel-opment. Software can be developed at lower cost, with fewer defects,with higher productivity, and with much higher return on investment.The same teams that are struggling today can achieve these results bycareful attention to and refinement of how they work, by pushing ordi-nary development practices to the extreme.

There are better ways and worse ways to develop software. Goodteams are more alike than they are different. No matter how good orbad your team you can always improve. I intend this book as a resourcefor you as you try to improve.

This book is my personal take on what it is that good software devel-opment teams have in common. I’ve taken things I’ve done that haveworked well and things I’ve seen done that worked well and distilledthem to what I think is their purest, most “extreme” form. What I’mmost struck with in this process is the limitations of my own imagina-tion in this effort. Practices that seemed impossibly extreme five yearsago, when the first edition of this book was published, are now com-mon. Five years from now the practices in this book will probably seemconservative.

If I only talked about what good teams do I would be missing thepoint. There are legitimate differences between outstanding teams’actions based on the context in which they work. Looking below thesurface, where their activities become ripples in the river hinting at

xxii Preface

shapes below, there is an intellectual and intuitive substrate to softwaredevelopment excellence that I have also tried to distill and document.

Critics of the first edition have complained that it tries to force themto program in a certain way. Aside from the absurdity of me being ableto control anyone else’s behavior, I’m embarrassed to say that was myintention. Relinquishing the illusion of control of other people’s behav-ior and acknowledging each individual’s responsibility for his or herown choices, in this edition I have tried to rephrase my message in apositive, inclusive way. I present proven practices you can add to yourbag of tricks.

✧ No matter the circumstance you can always improve.✧ You can always start improving with yourself.✧ You can always start improving today.

AcknowledgmentsI would like to thank my most excellent group of reviewers, each ofwhom spent considerable time reading and commenting on the manu-script: Francesco Cirillo, Steve McConnell, Mike Cohn, David Ander-son, Joshua Kerievsky, Beth Andres-Beck, and Bill Wake. The SiliconValley Patterns Group also provided valuable feedback on drafts: ChrisLopez, John Parello, Phil Goodwin, Dave Smith, Keith Ray, RussRufer, Mark Taylor, Sudarsan Piduri, Tracy Bialik, Jan Chong, RiturajKirti, Carlos Mc Evilly, Bill Venners, Wayne Vucenic, Raj Baskaran, TimHuske, Patrick Manion, Jeffrey Miller, and Andrew Chase. Thanks tothe production staff at Pearson: Julie Nahil, Kim Arney Mulcahy, andMichelle Vincenti. Paul Petralia, my editor, saw me through difficulttimes with humor and understanding. He taught me lessons in thevalue of relationships. Erich Gamma, my pair programming partner,provided conversation and feedback. The owners and staff of BluestoneBakery and Cafe kept the hot chocolate and broadband flowing. JoëlleAndres-Beck edited copy and collected garbage. All of my children;Lincoln, Lindsey, Forrest, and Joëlle; spent many hours at Bluestonewhile we edited. Gunjan Doshi provided thought-provoking questions.

Finally, I cannot possibly give sufficient thanks to my wife, develop-mental editor, friend, and intellectual colleague Cynthia Andres.

1

Chapter 1

What is XP?

Extreme Programming (XP) is about social change. It is about lettinggo of habits and patterns that were adaptive in the past, but now get inthe way of us doing our best work. It is about giving up the defensesthat protect us but interfere with our productivity. It may leave us feel-ing exposed.

It is about being open about what we are capable of doing and thendoing it. And, allowing and expecting others to do the same. It isabout getting past our adolescent surety that “I know better thaneveryone else and all I need is to be left alone to be the greatest.” It isabout finding our adult place in the larger world, finding our place inthe community including the realm of business/work. It is about theprocess of becoming more of our best selves and in the process ourbest as developers. And, it is about writing great code that is reallygood for business.

Good relationships lead to good business. Productivity and confi-dence are related to our human relationships in the workplace as well asto our coding or other work activities. You need both technique andgood relationships to be successful. XP addresses both.

Prepare for success. Don’t protect yourself from success by holdingback. Do your best and then deal with the consequences. That’sextreme. You leave yourself exposed. For some people that is incredi-bly scary, for others it’s daily life. That is why there are such polarizedreactions to XP.

2 Extreme Programming Explained: Embrace Change

XP is a style of software development focusing on excellent applica-tion of programming techniques, clear communication, and teamworkwhich allows us to accomplish things we previously could not evenimagine. XP includes:

✧ A philosophy of software development based on the values ofcommunication, feedback, simplicity, courage, and respect.

✧ A body of practices proven useful in improving software develop-ment. The practices complement each other, amplifying theireffects. They are chosen as expressions of the values.

✧ A set of complementary principles, intellectual techniques fortranslating the values into practice, useful when there isn’t a prac-tice handy for your particular problem.

✧ A community that shares these values and many of the samepractices.

XP is a path of improvement to excellence for people coming togetherto develop software. It is distinguished from other methodologies by:

✧ Its short development cycles, resulting in early, concrete, and con-tinuing feedback.

✧ Its incremental planning approach, which quickly comes up with anoverall plan that is expected to evolve through the life of the project.

✧ Its ability to flexibly schedule the implementation of functionality,responding to changing business needs.

✧ Its reliance on automated tests written by programmers, custom-ers, and testers to monitor the progress of development, to allowthe system to evolve, and to catch defects early.

✧ Its reliance on oral communication, tests, and source code tocommunicate system structure and intent.

✧ Its reliance on an evolutionary design process that lasts as long asthe system lasts.

✧ Its reliance on the close collaboration of actively engaged individ-uals with ordinary talent.

✧ Its reliance on practices that work with both the short-term instinctsof the team members and the long-term interests of the project.

Chapter 1 What is XP? 3

The first edition of Extreme Programming Explained: EmbraceChange had a definition of XP with the advantage of clarity: “XP is alightweight methodology for small-to-medium-sized teams developingsoftware in the face of vague or rapidly changing requirements.” Whilethis statement was true about the origin and intent of XP, it doesn’t tellthe whole story. In the five years since the publication of the first edi-tion teams have pushed XP much further than the original definition.XP can be described this way:

✧ XP is lightweight. In XP you only do what you need to do to cre-ate value for the customer. You can’t carry a lot of baggage andmove fast. However, there is no freeze-dried software process.The body of technical knowledge necessary to be an outstandingteam is large and growing.

✧ XP is a methodology based on addressing constraints in softwaredevelopment. It does not address project portfolio management,financial justification of projects, operations, marketing, or sales.XP has implications in all of these areas, but does not addressthese practices directly. Methodology is often interpreted to mean“a set of rules to follow that guarantee success.” Methodologiesdon’t work like programs. People aren’t computers. Every teamdoes XP differently with varying degrees of success.

✧ XP can work with teams of any size. Five years ago, I did not wantto claim too much. Others have since put XP to use in a widerange of projects and have had success with both large and smallprojects and teams. The values and principles behind XP are appli-cable at any scale. The practices need to be augmented and alteredwhen many people are involved.

✧ XP adapts to vague or rapidly changing requirements. XP is stillgood for this situation, which is fortunate because requirementsneed to change to adapt to rapid shifts in the modern businessworld. However, teams have also successfully used XP whererequirements don’t seem volatile, like porting projects.

XP is my attempt to reconcile humanity and productivity in my ownpractice of software development and to share that reconciliation. I hadbegun to notice that the more humanely I treated myself and others,

4 Extreme Programming Explained: Embrace Change

the more productive we all became. The key to success lies not in self-mortification but in acceptance that we are people in a person-to-per-son business.

Technique also matters. We are technical people in a technical field.There are better ways and worse ways of working. The pursuit of excel-lence in technique is critical in a social style of development. Techniquesupports trust relationships. If you can accurately estimate your work,deliver quality the first time, and create rapid feedback loops; then youcan be a trustworthy partner. XP demands that participants learn a highlevel of technique in service of the team’s goals.

XP means giving up old habits of working for new ways tailored totoday’s reality. The habits, attitudes, and values of our early yearsworked then; but may not be our best choices in the current world ofteam software development. Good, safe social interaction is as neces-sary to successful XP development as good technical skills.

One example is the concept that vulnerability is safety. The old habitof holding something back in order to be safe doesn’t really work.Holding back that last 20% of effort doesn’t protect me. When myproject fails, the fact that I didn’t give my all doesn’t actually make mefeel better. It doesn’t protect me from a sense of failure that I couldn’tmake the project work. If I do my very best writing a program and peo-ple don’t like it, I can still feel justly good about myself. This attitudeallows me to feel safe no matter the circumstance. If how I feel is basedon an accurate read on whether I did my best, I can feel good aboutmyself by doing my best.

XP teams play full out to win and accept responsibility for the conse-quences. When self-worth is not tied to the project, we are free to doour best work in any circumstance. In XP you don’t prepare for failure.Keeping a little distance in relationships, holding back effort eitherthrough underwork or overwork, putting off feedback for anotherround of responsibility diffusion: none of these behaviors have a placeon an XP team.

You may have enough time, money, or skills on your team or you maynot; but it is always best to act as if there is going to be enough. This“mentality of sufficiency” is movingly documented by anthropologistColin Turnbull in The Mountain People and The Forest People. He con-trasts two societies: a resource-starved tribe of lying, cheating backstab-bers and a resource-rich, cooperative, loving tribe. I often ask developers

Chapter 1 What is XP? 5

in a dilemma, “How would you do it if you had enough time?” You cando your best work even when there are constraints. Fussing about theconstraints distracts you from your goals. Your clear self does the bestwork no matter what the constraints are.

If you have six weeks to get a project done, the only thing you con-trol is your own behavior. Will you get six weeks’ worth of work doneor less? You can’t control others’ expectations. You can tell them whatyou know about the project so their expectations have a chance ofmatching reality. My terror of deadlines vanished when I learned thislesson. It’s not my job to “manage” someone else’s expectations. It’stheir job to manage their own expectations. It’s my job to do my bestand to communicate clearly.

XP is a software development discipline that addresses risk at all lev-els of the development process. XP is also productive, produces high-quality software, and is a lot of fun to execute. How does XP addressthe risks in the development process?

✧ Schedule slips—XP calls for short release cycles, a few months atmost, so the scope of any slip is limited. Within a release, XP usesone-week iterations of customer-requested features to create fine-grained feedback about progress. Within an iteration, XP planswith short tasks, so the team can solve problems during the cycle.Finally, XP calls for implementing the highest priority features first,so any features that slip past the release will be of lower value.

✧ Project canceled—XP asks the business-oriented part of the teamto choose the smallest release that makes the most business sense,so there is less to go wrong before deploying and the value of thesoftware is greatest.

✧ System goes sour—XP creates and maintains a comprehensive suiteof automated tests, which are run and rerun after every change(many times a day) to ensure a quality baseline. XP always keepsthe system in deployable condition. Problems are not allowed toaccumulate.

✧ Defect rate—XP tests from the perspective of both programmerswriting tests function-by-function and customers writing testsprogram-feature-by-program-feature.

✧ Business misunderstood—XP calls for business-oriented people tobe first-class members of the team. The specification of the project

6 Extreme Programming Explained: Embrace Change

is continuously refined during development, so learning by thecustomer and the team can be reflected in the software.

✧ Business changes—XP shortens the release cycle, so there is lesschange during the development of a single release. During arelease, the customer is welcome to substitute new functionalityfor functionality not yet completed. The team doesn’t even noticeif it is working on newly discovered functionality or featuresdefined years ago.

✧ False feature rich—XP insists that only the highest priority tasksare addressed.

✧ Staff turnover—XP asks programmers to accept responsibility forestimating and completing their own work, gives them feedbackabout the actual time taken so their estimates can improve, andrespects those estimates. The rules for who can make and changeestimates are clear. Thus, there is less chance for a programmer toget frustrated by being asked to do the obviously impossible. XPalso encourages human contact among the team, reducing theloneliness that is often at the heart of job dissatisfaction. Finally,XP incorporates an explicit model of staff turnover. New teammembers are encouraged to gradually accept more and moreresponsibility, and are assisted along the way by each other and byexisting programmers.

XP assumes that you see yourself as part of a team, ideally one withclear goals and a plan of execution. XP assumes that you want to worktogether. XP assumes that change can be made inexpensive using thismethod. XP assumes that you want to grow, to improve your skills, andto improve your relationships. XP assumes you are willing to makechanges to meet those goals.

Now I’m ready to answer the question posed by this chapter: whatis XP?

✧ XP is giving up old, ineffective technical and social habits in favorof new ones that work.

✧ XP is fully appreciating yourself for total effort today.✧ XP is striving to do better tomorrow.

Chapter 1 What is XP? 7

✧ XP is evaluating yourself by your contribution to the team’sshared goals.

✧ XP is asking to get some of your human needs met through soft-ware development.

The rest of this book explores what to do to effect these changes andspeculates about why they work, personally and economically. Thebook is divided into two sections. The first is practical, describing a wayof doing and thinking about software development that both assumesand satisfies human needs, including the need for relationships. Thesecond section covers the philosophical and historical roots of XP andplaces XP in today’s context.

There are as many ways of reading this book and applying XP asthere are of getting into a cool pool on a hot day: one toe at a time,walking steadily down the steps, the cannonball, the racing dive. Theyall meet the goal of getting into the water. Your choice may be basedon style, speed, efficiency, or fear. Only you can decide which is rightfor you. I hope that in reading and applying this book you will come toa deeper understanding of why you are involved in software develop-ment and how you can find satisfaction from this work.

This page intentionally left blank

175

Index

AAbundant living, 167Accepted responsibility, 4, 165Accomplishment, as human need, 24Accountability

community and, 158executive role and, 78

Accounting, for expense vs. invest-ment, 113

Accreditation, XP, 146–147Action, reflection following, 30Adopting XP. See XP, applyingAlexander, Christopher, 153–154Analysis, decision making, 172Andres-Beck, Beth, 104Anxiety, accompanying change, 57Application development. See Soft-

ware developmentArchitects, team roles, 75–76Architecture

design and, 154–155fluidity, 128tests and, 75–76

Architecture, of buildings, 162, 163Artifacts, of development, 66–67Attitude, bibliographic references,

162–163

Auditing, projects prior to release, 116

Authoritymisalignment of authority and

responsibility, 141Automated builds, 49Automated tests, 100–101, 171awareness, of need for change,

56–57

BBaby steps, 33, 53Belonging

human needs, 24team approach and, 39

Beta testing, 101Bibliography, 161–174

attitudes, 162–163emergent processes, 163–164people, 165–168philosophy, 161–162programming, 171–174project management, 168–171systems, 164–165

Big bang integration, 30, 87Big deployments, 63Biology, in 21st Century, 155

176 Index

Boehm, Barry, 52Bottlenecks

coach noticing, 143identifying, 47, 86–87Theory of Constraints and, 85–86

Brand, Stewart, 104, 174Breaks, in work day, 41–42Budgets, 94–95Business

business interests dominating development, 154

business interests sharing responsi-bility with programmers, 155

paradigm shifts and, 166relationships, 1

CCapability Maturity Model, 150Capital expenditures, 113Certification, XP, 146–147Change

accountability and, 158adapting to, 11awareness of need for, 56–57baby steps and, 33changing one thing at a time, 55costs of, 52deciding what to change first, 56factors in rapid change, 142feedback and, 19opportunities for, 30–31people and, 155speed of, 56starting with yourself, 57strategies for, 168

Chaos theory, 164Charts, in Informative Workspace,

41Chrysler Smalltalk project, 125–129

estimation, 127–128incremental design, 127

success of, 128–129team creation, 126–127trouble indicators, 126

Clarity, bibliographic reference, 161Coach, selecting, 143–144Code

code and tests, 66–67, 101–102communicating through, 171defect levels and, 98eliminating duplication of, 108future users, 26as key in software development, xixprofitability of, 173sharing responsibility for, 66single code base vs. multiple code

streams, 67–68team approach to, 17test-first programming and, 50traceability of changes to, 116–117trust and, 51waste and, 137

Code Complete (McConnell), 104Coe, Bob, 126Cohesion, of code, 50Collective ownership, 66. See also

ResponsibilityComics, 166Commitment, waste created by over-

commitment, 48Communication

between business and technical people, 172

courage and, 21credibility and, 48documentation and, 146drawings as, 174embracing as a value, 146feedback and, 20listening skills vs. talking skills, 157multi-site development and, 149nonviolent, 167

Index 177

product managers encouraging, 78programming as form of, 173project managers responsibility for,

76–77simplicity and, 19as value guiding development, 18

Community, XP, 157–160Computing, in 21st Century, 155Conflict

community and, 158diversity and, 29

Conquer-and-divide, 112Consensus, in project management,

170Constraints. See Theory of

ConstraintsContinuous improvement, 141–142Continuous integration

collective ownership and, 66as primary practice, 49–50

Contracts, ongoing negotiation of scope, 69

Contributing to Eclipse (Gamma),51

Controlfallacy of working longer to regain,

41illusion of being able to control

others, xxiiof people, 166quality and, 32, 169scope as basis of, 33

Cooperation, 18, 93Costs

changes, 52code development, 173defects, 97finding defects early and, 99options pricing, 174project management and, 92redundancy, 31

software development, 173variable in zero-sum model,

161–162Coupling, of code, 50–51Courage

balancing with other values, 21executive role and, 78multi-site development and, 149as value guiding development, 20–21

Credibility, 48Customers

development artifacts of value to, 66–67

driving system content, 12evolutionary delivery and, 169features controlled by, 128interaction designers working with,

75involvement of, xvi, 61–62technical writers and, 80Whole Team practice and, 39

DDaily deployment, xvi, 68–69, 143Daily focus, of incremental design,

103Database design strategy, 107–108,

172DCI (Defect Cost Increase), 98–99Deadlines, business concerns domi-

nating, 154Decision making

analysis decisions, 172design decision, 172in difficult situations, 165

Defect Cost Increase (DCI), 98–99Defects, 119–121

acceptable levels of, 97–98defect rate in Smalltalk project,

128incremental design and, 52

178 Index

Defects, continuedmetrics for defects after

deployment, 79redundancy and, 31root cause analysis, 64–65tests for reducing rate of, 5values and, 14

Deming, W. Edwards, 167Deployment

daily, 68–69, 143incremental approach to, 62–63incremental design and, 109metrics for defects after, 79

Design. See also Incremental designAlexander’s principles, 162common language for decision

making, 172database design strategy, 107–108,

172patterns and, 108, 173small scale, 171

Developers. See ProgrammersDevelopment. See Software

developmentDisney, 163Diversity principle, 29Documentation

code and tests as basis of, 66communication and, 146“Rosetta Stone” document,

114–115technical publications, 80–81of tests, 26Unified Process document driven

basis, 169Double-checking, defect testing,

98–100Drawings. See ImagesDrawings, as communication

medium, 174

DSDM (Dynamic Systems Develop-ment Method), 170

Dynamic Systems Development Method (DSDM), 170

EEclipse project, xv–xviEconomics

principles in XP, 25quality and, 33

Ego, thinking and, 165Emergent processes, bibliographic

references, 163–164Emotions, fear as barrier to perfor-

mance, 167Employees. See StaffingEnergized work

map of, 58as primary practice, 41–42

Ernst, Michael, 51, 173Estimation

benefit of early estimation, 44–45creating believable estimates,

127–128planning and, 92, 93–94real time estimates, 168values and, 14

Execution, separating from planning in social engineering, 132

Executive, as team role, 78–79Executive sponsorship

crucial to success of XP, 90, 119–121

finding, 140Expenses. See CostsExperience, design process and, 107“An Experimental Evaluation of

Continuous Testing During Development” (Saff and Ernst), 51, 173

Index 179

FFacilities. See WorkspaceFailure

dealing with consequences of, 116–117

learning from, 143as principle in XP, 32

Featurescustomer control of, 128tracking projects by, 169

Feedbackfrom continuous testing, 173Eclipse project and, xvfinding defects and, 99measuring software projects, 169pay-per-use, 69–70reflection combined with doing,

30types of, 20as value guiding development,

19–20Flow

principles in XP, 30team approach and, 73–74

The Forest People (Turnbull), 4Fowler, Martin, 95, 126Fractals, 27

GGamma, Erich, 51Gannt, Henry, 131Gilbreth, Frank, 131Gilbreth, Lillian, 131Gladwell, Malcolm, 39Global software development, 151Goals

executive role and, 78planning and, 91XP goals for software develop-

ment, xxi

Graphics. See ImagesGroup dynamics, 143Growth, as human need, 24

HHealth, pair programming and, 43Hendrickson, Chet, 128High-cost base areas, compared with

low-cost base areas, 150Hiring, 81–82History, practice of, 167Hopelessness, overcoming, 163How Buildings Learn (Brand), 104Human resources, reviews and hir-

ing, 81–82Humanity

fear as barrier to performance, 167principle in XP, 24–25Sit Together practice and, 38workspace and, 40

Hunt, Andy, 140Hygiene, 43

IIllnesses. See SicknessesImages

communicating with drawings, 174

communicating with graphs and pictures, 174

Improvementexecutive role and, 78noncontinuous nature of, 142principles in XP, 28

Incremental deployment, 62–63, 169

Incremental design, 103–110daily focus of, 103database design strategy, 107–108deciding when to design, 105–107

180 Index

Incremental design, continuedEclipse project and, xviimprovement as focus of, 28investing in, 172Once and Only Once heuristic,

108as primary practice, 51–53simplicity of design, 109–110Smalltalk project, 127timing of design decisions, 109weakness of physical-based meta-

phors for, 103–104Industrial engineering, 131Informative workplace, 39–41

charts, 41human needs and, 40–41story cards, 40

Insight, 41Integration, continuous integration

practice, 49–50Integrity, 159Interaction designers, as team role,

75Investments

measuring investment-to-return, 79

XP as expense or investment, 113Iterations

feedback cycles and, 7, 94planning frequency of, 121removing constraints or limita-

tions, 168story implementation and, 127

JJAD (Joint Application Develop-

ment), 171Jeffries, Ron, 126Jensen, Brad, 119–121Jobs, offshore development and,

150

Joint Application Development (JAD), 171

Judgement, communication and, 168

JUnit, xiv, 171, 173Just In Time Software process,

xiii–xiv

LLeadership, 143Learning

applying new skills, 141conflict and disagreement and, 158by example, 143from failures, 32, 143reflection as basis of, 30

Life cycle models, 116Listening skill

community and, 157listening to feedback, 80, 141planning and, 93

Load tests, 101Low-cost base areas, compared with

high-cost base areas, 150MMaintenance

applying XP to, 170project management and, 170

Managementexecutives, 78–79product managers, 78project managers, 76–77, 92,

113–114Scientific Management and, 131self-organizing systems as meta-

phor for management, 164Manual testing, 101Manuals, 80–81. See also

DocumentationMargins, in software development,

165

Index 181

Mathematics, programming as, 172McConnell, Steve, 104–105, 173Meetings, weekly cycles, 46Metaphors

chosen by interaction designers, 75code names and, 26driving XP, 12physical-based impose limits on

software development, 104Scientific Management, 131self-organizing systems as meta-

phor for management, 164thinking and, 162Unified Process emphasis on, 170

Metricsawareness and, 56feedback and, 169graphing, 174for health of XP team, 79measuring progress with tests, 102for XP, 145

Micro-optimization, 88Mistakes. See FailureModernism, 161Money. See also Costs

pay-per-use and, 69–70time value of, 25

The Mountain People (Turnbull), 4Multi-site development, 149–152

global software development, 151high-cost base areas compared

with low-cost base areas, 150practices and, 150principles and, 150reasons for, 149values and, 149

Mutual benefit, as principle in XP, 26

NNames, coding style and, 26Negotiated scope contract, 69

OOffshore development. See Multi-site

developmentOhno, Taiichi, 136, 174Once and Only Once, heuristic for

incremental design, 108Online communities, XP, 158Opportunity, as principle in XP,

30–31Option value, of systems and teams,

25Organizations

reducing team sizes, 150reverting to old habits, 140scaling XP and, 113–114

Overall throughput, vs. micro-opti-mization, 88

Overproduction, as waste, 136Overwork, holding back effort

through, 6Ownership, collective, 66. See also

Responsibility

PPain, as factor in quick change, 142Pair programming

benefits of, 42–43continuous integration and, 50personal space and, 43–44as primary practice, 42–43reasons for applying, 35teamwork and, 66technical collaboration and, 57XP building on, xiv

Paradigms, 166Partitioning systems

architect’s responsibility for, 76scaling XP and, 112

Patternsdesign process and, 108, 173XP and, xiv

182 Index

Pay-per-release, 70Pay-per-use, 69–70People

bibliographic references, 165–168change and, 155communication between business

and technical people, 172as component of problems, 38scaling XP and, 111–112

Perfection, 28Performance, fear as barrier to, 167Performance tuning, 93, 125Permaculture, 103, 162Personal space, 43–44Philosophy

bibliographic references, 161–162of XP, 123

Physical environment. See WorkspacePlanning, 91–95

Chrysler Smalltalk project, 127deciding what to change first, 56estimation and, 92, 93–95goals and, 91incremental, xviproject managers responsibility for,

77quarterly cycles and, 47–48scope as basis of, 92separating from execution in

Taylorism, 132team cooperation in, 93technical details of, 168timescales and, 92–93weekly cycles and, 46–47

Politics, of offshore development, 150

Postmodernism, 161Practices

based on values, 14compared with values, 14–15defined, 13

implementing primary before corollary, 61

ineffectiveness of dictating, 57learning by example, 143mapping, 58–59multi-site development and, 150overview of, 35–36social relationships and, 154win-win-win, 26

Practices, corollary, 61–73code and tests, 66–67customer involvement, 61–62daily deployment, 68–69incremental deployment, 62–63negotiated scope contract, 69pay-per-use, 69–70root cause analysis, 64–66shared code, 66shrinking teams, 64single code base, 67–68team continuity, 63–64

Practices, primary, 37–54continuous integration, 49–50energized work, 41–42incremental design, 51–53informative workplace, 39–41pair programming, 42–43quarterly cycles, 47–48sit together, 37–38slack, 48stories, 44–45ten-minute build, 49test-first programming, 50–51weekly cycles, 46–47whole team approach, 38–39

Predictability, as value, 22Principles, 23–36

baby steps, 33defined, 15diversity, 29economics, 25

Index 183

failure, 32flow, 30humanity, 24–25improvement, 28learning by example, 143multi-site development and, 150mutual benefit, 26opportunity, 30–31overview of, 23quality, 32–33redundancy, 31–32reflection, 29–30responsibility, 34self-similarity, 27–28social relationships and, 154

Priorities, 109aligning, 55–57business, 67economics of, 25funding, 129implementing highest priority first,

7–8product managers and, 77

Problemscomplexity in scaling XP, 115as opportunity for change, 30–31people-oriented solutions, 38resolving in flow-based environ-

ment, 30steps for working with big, 112

Product development, 170Product managers, 77–78Productivity

Energized Work principle and, 41Scientific Management and, 131TPS, 136

Programmersglobal demand, 151sharing responsibility with business

interests, 155as team role, 81

tests, 100working with sponsors and users,

154Programming

art of writing, 166balancing human interests, 153–155bibliographic references, 171–174continuous integration practice,

49–50pair programming principle, 42–43for and by people, 168pragmatic programmers, 140short-cycle, 169social and technical networks, 164test-first programming, 50–51,

141, 143Project management

bibliographic references, 168–171Taylorist perspective, 170

Project managerspresenting information to organi-

zations, 113–114story cards and, 95as team role, 76–77

Projectscancellations, 5feedback and, 169tracking projects by features, 169trouble indicators, 126

Pull, model of development, 87–88Push, model of development, 87–88

QQuality

principles in XP, 32–33project management and, 92quality control in Deming’s model,

167social engineering and, 132–133variable in zero-sum model,

161–162

184 Index

Quality-of-life, 22Quarterly cycles, 47–48, 114

RRedundancy principle, 31–32Refactoring, xiv, xv, 172Reflection principle, 29–30Regression testing, 65Relationships

business relationships, 1community, 157fostering strong, 154improving, 146mutual benefit as basis of, 26relational skills of programmers,

81separating intimate relationships

from work setting, 43in societies of abundance and scar-

city, 167undermined by misalignment of

authority and responsibility, 141

Release cycle, reducing, 6Requirements

gathering, 137misused terminology in develop-

ment, 44Resources, in societies of abundance

and scarcity, 167Respect

multi-site development and, 149in Ohno’s management approach,

174as value guiding development, 21

Responsibilityaccepted, 4, 165vs. control by others, xxiimisalignment undermines trust,

141as principle in XP, 34

shared code and, 66sharing between programmers and

business interests, 155Revenue, measuring investment-to-

return, 79Review, of human resources, 81–82Rewards, as control mechanism, 166Risk

big deployments and, 63daily deployment and, 68economic, 26of error, 49of failure, leading to success, 32management, 73, 116, 169negotiated scope contract and, 69not asking others to take risks you

are not willing to take, 141partitioning and, 112silence as sound of risk piling up,

79XP addresses at all levels, 7

Risk, in development process, 5–6Roles flexibility, in XP programming,

82–83Root cause analysis, 64–66“Rosetta Stone” document, 114–115

SSabre Airline Solutions, 119–121Sadalage, Pramod, 107Safety

human needs, 24Sit Together practice and, 38as value, 22

Saff, David, 51Scaffolding, incremental deploy-

ment, 63Scaling XP, 111–117

consequences of failure, 116–117investments, 113organization size, 113–114

Index 185

overview of, 111people, 111–112problem complexity and, 115solution complexity and, 115–116time, 114–115

Schedules, slipping, 5Scientific Management, 131–132,

174Scope

business concerns dominating, 154as control mechanism, 33ongoing negotiation of, 69planning as means of managing, 92variable in zero-sum model,

161–162Scope creep, 50Seasons, as organizational timescale,

47Security

certifiable, 116–117as value, 22

Self-organizing systems, 164Self-similarity principle, 27–28Sexuality, in work environment, 43Shape, self-similarity principle, 27Shared code, 66Shrinking teams, 64Sicknesses, 41Simplicity

bibliographic reference, 161courage and, 21dealing with excess complexity,

115–116feedback and, 20incremental design, 109–110multi-site development and, 149as value guiding development,

18–19Single code base, 67–68, 150Sit together as a practice, 37–38, 145Skiing, 165

Skills, learning and applying, 141Slack, as primary practice, 48Social change, 1Social engineering, 132–133Social relationships

stratification lacking in TPS, 136XP applied in context of, 139

Software developmentadvantages of XP for, 3–4community for, 157–160costs, 173cycles, xvidriving with stories, 169DSDM approach to rapid develop-

ment, 170electrical engineering paradigm,

169global, 151goals of XP and, xxilimitations of Taylor’s model when

applied to, 132low-cost base areas vs. high-cost

base areas, 150margins in, 165overproduction, 136–137push model contrasted with pull

model, 87–88risk in, 5–6shortcomings of Taylorist

approach, 166team-driven process, 12Theory of Constraints and, 168utility vs. technical virtuosity, 154values guiding, 18

Software engineering, 49Solution complexity, 115–116Sponsors

executive sponsorship, 90, 119–121, 140

working with developers and users, 154

186 Index

Staffingmanaging turnover, 6scaling, 112needs of good developers, 24worker responsibility in TPS,

135–136Static verification, 101Stories

breaking into tasks, 47deciding what to change first, 56driving development from, 169interaction designers writing, 75planning and, 91, 93–95as primary practice, 44–45product managers writing, 77–78project completion time and, 127slack time and, 48weekly cycles and, 46

Story cardsexample, 45in informative workplace, 40in planning process, 96presenting information to organi-

zations, 113–114Stress tests, 101Subscription model, software mar-

keting, 70Success

as goal, 146XP and, 4

Survival, problem solving and, 31Systems

bibliographic references, 164–165self-organizing, 164

TTalking skills, 157Tasks, breaking stories into, 47Taylor, Frederick, 131–133, 150,

165, 167, 170

TDD (Test-Driven Development), 171

Team. See also Whole team practiceapproach to coding style, 17balancing individual needs with

team needs, 24certification and accreditation, 146common factors in good software

development teams, xxi–xxiicommunication as basis of cooper-

ation, 18continuity, 63–64Disney’s, 163diversity, 29models, 66orientation in XP, 6reducing size (shrinking) of, 64respect as key value to working of,

21reverting to old habits, 140scaling XP and, 112sexuality complicating working of,

43sharing power, 155size thresholds, 39software development as team-

driven process, 12things that can go wrong, 168undermined by misalignment of

authority and responsibility, 141

Team continuity, 63–64Teamwork models, 66Technical aspects

communication between business and technical people, 172

excellence in, 4technical fixes must be comple-

mented by people-oriented solutions, 38

Index 187

Technical collaboration, 57Technical employment, 150Technical publications, 80–81Technical writers, as team role,

80–81Technique, as basis of practices, 13Ten-minute build, as primary prac-

tice, 49Test-Driven Development (TDD),

171Test-first programming, 50–51, 141,

143, 171Testers, as team role, 74–75Tests, 97–102

automating, 100–101code and test cycle, 66–67,

101–102DCI, 98–99defect rates, 5defect reduction, 97–98documenting, 26double-checking, 100early and often, xvifeedback from continuous testing,

173frequency of, 100JUnit, 171learning from failures, 32measuring progress with, 102regression testing, 65static verification, 101system architecture, 75–76ten-minute build, 49test-first programming, 50–51,

141, 143unit tests, 173weekly cycles and, 46, 74

Theory of Constraints, 85–90bottlenecks and, 85–86identifying constraints, 86–87

overall throughput vs. micro-optimization, 88

push model of development con-trasted with pull model, 87–88

software development and, 168statement of theory, 86understanding systems, 164XP shifting constraints to non-

software development areas, 89–90

Thinkingego and, 165linear vs. nonlinear, 174metaphors and, 162

Thomas, Dave, 140ThoughtWorks, 107Throughput, 88, 164Time

long-running projects and, 114–115

planning and, 92–93project management and, 92quarterly cycles and, 47–48seasons and, 47time value of money, 25variable in zero-sum model,

161–162weekly cycles and, 46

The Tipping Point (Gladwell), 39Toyota Production System (Ohno),

137Toyota Production System (TPS),

135–138parallels to software development,

136–137production process, 136social stratification lacking in, 136waste reduced, 135–136worker responsibility in, 135–136

Tracking, projects by features, 169

188 Index

Trustdefects and, 97–98undermined by misalignment of

responsibility, 141Turnbull, Colin, 4

UUnderwork, holding back effort

through, 6Unit tests, xiv, xv, 173UP (Unified Process), 170User-interface design, 166Users. See also Customers

as team role, 81technical writers and, 80

Users, continuedtests based on perspective of, 102working with developers and spon-

sors, 154

VValues, 17–22

based on what really matters, 17change and, 56communication, 18compared with practices, 14–15courage, 20–21defined, 14feedback, 19–20guiding development, 18improvement and, 142integrity and, 159learning by example, 143multi-site development and, 149not using XP when organization

values at odds with XP values, 144

other important, 22respect, 21simplicity, 18–19

WWabi-Sabi, 161Waste

customer involvement in reduc-ing, 61

eliminating, 28overcommitment and, 48overproduction and, 136–137planning as necessary waste, 46–47redundancy and, 32Toyota success in eliminating,

135–136Waterfall process, 87, 146Weekly cycles, 46–47, 74Whole team practice, 73–83

architects, 75–76customers, 61–62executives, 78–79failure to work together,

73–74human resources, 81–82interaction designers, 75overview of, 38–39product managers, 77–78programmers, 81project managers, 76–77role flexibility and, 82–83technical writers, 80–81testers, 74–75users, 81

Win-win-win practices, 26Work hours

balancing with other human needs, 24

energized work principle and, 41Workspace

design of, 163–164informative workspace practice,

39–41sit together practice, 38

Index 189

XXP, applying, 139–144

coach selection, 143–144executive sponsorship, 119–121,

140improvements, 142learning and applying skills, 141organization reverting to old hab-

its, ways of doing things, 140social relationships and, 139staring with yourself, 140–141when not to apply XP, 144

XP, getting started, 55–59awareness of need for change,

56–57change starts with yourself, 57changing one thing at a time, 55deciding what to change first, 56mapping practices and, 58–59

XP, overviewaspects of, 2benefits of, 3business relationships and, 1certification and accreditation,

146–147constraints shifted to non-

software development areas, 89–90

defined, iv, 6–7distinguishing characteristics, 2metrics for, 145–146risk in development process and,

5–6social change and, 1success and, 4

ZZero-sum model, 161–162