Online Sample Chapter
Agile Software Development: Forming Teams that Communicate and Cooperate
Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
cockburnch3.pdf
Table of Contents
List of Figures.
List of Stories.
Preface.
Introduction: Unknowable and Incommunicable.
The Problem with Parsing Experience.
The Impossibility of Communication.
Three Levels of Listening.
So, What Do I Do Tomorrow?
Chapter 1: A Cooperative Game of Invention and Communication. Software and Poetry.
Software and Games.
A Second Look at the Cooperative Game.
What Should This Mean to Me?
2. Individuals. Them's Funky People.
Overcoming Failure Modes.
Working Better in Some Ways than Others.
Drawing on Success Modes.
What Should I Do Tomorrow?
3. Communicating, Cooperating Teams. Convection Currents of Information.
Jumping Communication Gaps.
Teams as Communities.
Teams as Ecosystems.
What Should I Do Tomorrow?
4. Methodologies. An Ecosystem That Ships Software.
Methodology Concepts.
Methodology Design Principles.
XP under Glass.
Why Methodology at All?
What Should I Do Tomorrow?
5. Agile and Self-Adapting. Light but Sufficient.
Agile.
Becoming Self-Adapting.
What Should I Do Tomorrow?
6. The Crystal Methodologies. Shaping the Crystal Family.
Crystal Clear.
Crystal Orange.
Crystal Orange Web.
What Should I Do Tomorrow?
Appendix A. The Agile Software Development Manifesto. The Agile Alliance.
The Manifesto.
Supporting the Values.
Appendix B. Naur, Ehn, Musashi. Peter Naur, Programming as Theory Building.
Pelle Ehn, Wittgenstein's Language Games.
Musashi.
Appendix C. Books and References. Index. 0201699699T09252001
Preface
Is software development an art, a craft, science, engineering, or something else entirely? Does it even matter?
Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct.
The main thing is this: You want your software out soon and defect free, but more than that, you need a way to examine how your team is doing along the way.
Purpose
It is time to reexamine the notions underlying software development.
The trouble is that as we look at projects, what we notice is constrained by what we know to notice. We learn to distinguish distinct and separable things in the extremely rich stream of experience flowing over us, and we pull those things out of the stream for examination. To the extent that we lack various key distinctions, we overlook things that are right in front of us.
We anchor the distinctions in our memories with words and use those words to reflect on our experiences. To the extent that we lack words to anchor the distinctions, we lack the ability to pull our memories into our conversations and the ability to construct meaningful strategies for dealing with the future.
In other words, to reexamine the notions that underlie software development, we have to reconsider the distinctions that we use to slice up our experience and the words we use to anchor our memories.
This is, of course, a tall order for any book. It means that some of the earlier parts of this book will be rather abstract. I see no way around it, though.
The last time people constructed a vocabulary for software development was in the late 1960s, when they coined the phrase software engineering, as both a wish and a direction for the future.
It is significant that at the same time the programming-should-be-engineering pronouncement was made, Gerald Weinberg was writing The Psychology of Computer Programming. In that book, software development doesn't look very much like an engineering discipline at all. It appears to be something very human-centric and communication-centric. Of the two, Weinberg's observations match what people have reported in the succeeding 30 years, and software engineering remains a wishful term.
In this book, I will
- Build distinctions and vocabulary for talking about software development
- Use that vocabulary to examine and anchor critical aspects of software projects that have been pushed to the sidelines too often
- Work through the ideas and principles of methodologies as "rules of behavior"
- Merge our need for these rules of behavior with the idea that each project is unique, and derive effective and self-evolving rules
I hope that after reading this book, you will be able to use the new vocabulary to look around at your project, notice things you didn't notice before, and express those observations. As you gain facility, you should be able to
- Discuss Extreme Programming, the Capability Maturity Model, the Personal Software Process, or your favorite process
- Determine when each process is more or less applicable
- Understand people who have differing opinions, abilities, and experience
Audience
Each person coming to this book does so with a different experience level, reading style, and role. Here's how you might read the book to use it to your greatest advantage: by experience, by reading style, or by role.
By Experience
This book is written for the more experienced audience. The book does not contain procedures to follow to develop software; in fact, core to the book is the concept that every technique has limitations. Therefore, it is impossible to name one best and correct way to develop software. Ideally, the book helps you reach that understanding and then leads you to constructive ideas about how to deal with this real-world situation.
If you are an intermediate practitioner who has experience with software-development projects, and if you are now looking for the boundaries for the rules you have learned, you will find the following topics most helpful:
- What sorts of methodologies fit what sorts of projects
- Indices for selecting the appropriate methodology category for a project
- The principles behind agile methodologies
Being an intermediate practitioner, you will recognize that you must add your own judgement when applying these ideas.
If you are an advanced practitioner, you already know that all recommendations vary in applicability. You may be looking for words to help you express that. You will find those words where the following topics are presented:
- Managing the incompleteness of communication
- Continuous methodology reinvention
- The manifesto for agile software development
A few topics should be new even to advanced software developers: the vocabulary for describing methodologies and the technique for just-in-time methodology tuning.
By Reading Style
The earlier chapters are more abstract than the later chapters.
If you enjoy abstract material, read the book from beginning to end, watching the play of abstract topics to see the resolution of the impossible questions through the course of the book.
If you want concrete materials in your hands as quickly as possible, you may want to skip over the early chapters on the first read and start with Chapter 4, "Methodologies." Return to the sections about "Cooperative Games" and "Convection Currents of Information" to get the key parts of the new vocabulary. Dip into the introduction and the chapters about individuals and teams to fill in the gaps.
By Role
People who sponsor software development can get from this book an understanding of how various organizational, behavioral, and funding structures affect the rate at which they receive value from their development teams. Project sponsors may pay less attention to the details of methodology construction than people who are directly involved in the projects. They should still understand the consequences of certain sorts of methodology decisions.
Team leads and project managers can see how seating, teaming, and individuality affect their project's outcome. They can also learn what sorts of interventions are more likely to have better or worse consequences. They will need to understand the construction and consequences of their methodology and how to evolve their methodology--making it as light as possible, but still sufficient.
Process and methodology designers can examine and argue with my choice of terms and principles for methodology design. The ensuing discussions should prove useful for the field.
Software developers should come to know this material simply as part of being in the profession. In the normal progression from newcomers to leaders, they will have to notice what works and doesn't work on their projects. They will also have to learn how to adjust their environment to become more effective. "Our methodology" really means "the conventions we follow around here," and so it becomes every professional's responsibility to understand the basics of methodology construction.
Organization of the Book
The book is designed to set up two nearly impossible questions at the beginning and derive answers for those questions by the end of the book:
- If communication is fundamentally impossible, how can people on a project manage to do it?
- If all people and all projects are different, how can we create any rules for productive projects?
To achieve that design, I wrote the book a bit in the "whodunit" style of a mystery. I start with the broadest and most philosophical discussions: "What is communication?" and "What is software development?"
The discussion moves through still fairly abstract topics such as "What are the characteristics of a human?" and "What affects the movement of ideas within a team?"
Eventually, it gets into more concrete territory with "What are the elements and principles of methodologies?" This is a good place for you to start if you are after concrete material early on.
Finally, the discussion gets to the most concrete matter: "What does a light, sufficient, self-evolving methodology look like?" and "How does a group create a custom and agile methodology in time to do the project any good?"
The two appendixes contain supporting material. The first contains the "Agile Software Development Manifesto," signed by 17 very experienced software developers and methodologists.
The second appendix contains extracts from three pieces of writing that are not as widely read as they should be. I include them because they are core to the topics described in the book.
Heritage of the Ideas in This Book
The ideas in this book are based on 25 years of development experience and 10 years of investigating projects directly.
The IBM Consulting Group asked me to design its first object-oriented methodology in 1991. I looked rather helplessly at the conflicting "methodology" books at the time. My boss, Kathy Ulisse, and I decided that I should debrief project teams to better understand how they really worked. What an eye-opener! The words they used had almost no overlap with the words in the books.
The interviews keep being so valuable that I still visit projects with sufficiently interesting success stories to find out what they encountered, learned, and recommend. The crucial question I ask before the interview is, "And would you like to work the same way again?" When people describe their experiences in words that don't fit my vocabulary, it indicates new areas in which I lack distinctions and words.
The reason for writing this book now is that the words and distinctions finally are correlating with descriptions of project life and project results. They are proving more valuable for diagnosis and intervention than any of the tools that I used previously.
The ideas in this book have been through dozens of development teams, eight methodology designs, and a number of successful projects on which I participated.
Agility
I am not the only person who is using these ideas:
- Kent Beck and Ward Cunningham worked through the late 1980s on what became called Extreme Programming (XP) in the late 1990s.
- Jim Highsmith studied the language and business use of complex adaptive systems in the mid-1990s and wrote about the application of that language to software development in his Adaptive Software Development.
- Ken Schwaber and Jeff Sutherland were constructing the Scrum method of development at about the same time, and many project leaders made similar attempts to describe similar ideas through the same years.
When a group of us met in February 2001 to discuss our differences and similarities, we found we had a surprising number of things in common. We selected the word agile to describe our intent and wrote the Agile Software Development Manifesto (Appendix A).
We are still formulating the principles that we share and are finding many other people who could have been at that meeting if they had known about it or if their schedules had permitted their presence.
Core to agile software development is the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules.
Agility implies maneuverability, a characteristic that is more important now than ever. Deploying software to the Web has intensified software competition further than before. Staying in business involves not only getting software out and reducing defects but tracking continually moving user and marketplace demands. Winning in business increasingly involves winning at the software-development game. Winning at the game depends on understanding the game being played.
The best description I have found for agility in business comes from Goldman (1997):
"Agility is dynamic, context-specific, aggressively change-embracing, and growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride out fearsome competitive 'storms.' It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share, and customers in the very center of the competitive storms many companies now fear." The Agile Software Development Series
Among the people concerned with agility in software development over the last decade, Jim Highsmith and I found so much in common that we joined efforts to bring to press an Agile Software Development Series based around relatively light, effective, human-powered software-development techniques.
We base the series on these two core ideas:
- Different projects need different processes or methodologies.
- Focusing on skills, communication, and community allows the project to be more effective and more agile than focusing on processes.
The series has these three main tracks:
- Techniques to improve the effectiveness of a person who is doing a particular sort of job. This might be a person who is designing a user interface, gathering requirements, planning a project, designing, or testing. Whoever is performing such a job will want to know how the best people in the world do their jobs. Writing Effective Use Cases (Cockburn 2001c) and GUIs with Glue (Hohmann, forthcoming) are two individual technique books.
- Techniques to improve the effectiveness of a group of people. These might include techniques for team building, project retrospectives, decision making, and the like. Improving Software Organizations (Mathiassen 2002) and Surviving Object-Oriented Projects (Cockburn 1998) are two group technique books.
- Examples of particular, successful agile methodologies. Whoever is selecting a base methodology to tailor will want to find one that has already been used successfully in a similar situation. Modifying an existing methodology is easier than creating a new one and is more effective than using one that was designed for a different situation. Crystal Clear (Cockburn, forthcoming) is a sample methodology book. We look forward to identifying other examples to publish.
Two books anchor the Agile Software Development Series:
- This one expresses the thoughts about agile software development using my favorite vocabulary: that of software development as a cooperative game, methodology as conventions about coordination, and families of methodologies.
- The second book is Highsmith's forthcoming one, Agile Software Development Ecosystems. It extends the discussion about problems in software development, common principles in the diverse recommendations of the people who signed the Agile Software Development Manifesto, and common agile practices. Highsmith's previous book, Adaptive Software Development, expresses his thoughts about software development using his favorite vocabulary, that of complex adaptive systems.
You can find more about Crystal, Adaptive, and other agile methodologies on the Web. Specific sites and topics are included in the References at the back. A starter set includes these sites:
http://www.crystalmethodologies.org www.AdaptiveSD.com www.AgileAlliance.org My home site,
http://members.aol.com/acockburn
0201699699P09252001
Index
A
Accuracy 124
Activities 117
adapting 155
bottleneck 156-158, 172
exploratory 155
optimizing 155
Actors-Goals list 126, 128
Adaptive Software Development xxi, 54, 100, 134, 203, 206, 215, 218
Agile 178-184, 195
Alliance 213, 216
methodology 217, 220
Allen, T. 88
Amicability 72, 101-102, 161, 218
Arett, K. 161, 259
Argh-minutes xxiv, 79
Auer, K. 135, 168
B
Bach, J. 33
Beck, K. xxi, 17, 32, 44, 48, 52, 59, 127, 135, 146, 148, 165, 215, 239
Beedle, M. 215
Bennekum, A. van 215
Boeing 102
Booch, G. 123
Boredom 253
Bottleneck activities 156, 157, 158, 172
Brooks, F. 29, 160
Burns, C. 57
Byrne, R. 55
C
C3 Project 35, 36, 37, 69
Cameron 62, 63
Capability Maturity Model 17, 53
Caves and common 60, 88, 89, 168
Central Bank of Norway 107, 151, 163
Ceremony 123, 151
Cisco Systems 65
Citizenship 102
Cleanroom 53
Coad, P. 215
Cockburn, A. 215
Code quality 150
Coding standards 54
Coetzee, V. 61
Collaboration 179
Colocated teams 88, 168
Communication
cost 77, 95, 161
face-to-face 80, 148, 158, 167, 221
high-bandwidth 172
load 162
osmotic 91, 149, 158, 167, 169
warm vs. cool 95-96, 149, 172
Communities 72, 99, 218
Conceptual terms 123-125
accuracy 124
ceremony 123
methodology size 123
methodology weight 123
precision 124, 128-129
problem size 123, 150-151
project size 123, 151, 160-162
relevance 124
scale 124
stability 124, 129-134
system criticality 123, 151-153, 162-163
tolerance 124
visibility 124
Concrete 55
Concurrent development 129, 132-134, 156-158
Conflict 101-102
Consistency 52
Constantine, L. 59, 105
Convection currents 77-91
Conway, J. 25
Cooperative Game principle 31-38, 175
Cooperative games 26, 201
Copy and alter 58, 136
Cray, S. 66
CRC cards 15, 17, 57, 117
Creativity 249, 252
Criticality 123, 152-153, 162-163
Cross-modality timing 92
Crystal Clear 87, 89, 100, 146, 163, 200, 202-204
and colocation 88
described to a Level 3 listener 16
Crystal methodologies 197-211
Crystal Orange 88, 163, 204-206
Crystal Orange Web 206-211
Crystal Yellow 163
Csikszentmihalyi, M. 27, 60
Cultural variation 45-46
Cultures 105
Cunningham, W. xxi, 52, 215, 222
Curriculum for education 171
Curtis, B. 84
Customer collaboration 217
D
Dandelions 62
Dawkins, R. 79
Declaration milestone 119-120
Deduction 55
Deliverables
intermediate 153
meaning of 118
DeMarco, T. 41, 60, 89
Design by doing 250, 252
Development
distributed 182
incremental 186, 189
iterative 185
multisite 181
offshore 181
open-source 37-38, 183-184
Different cities 78
Dilbert 62
Discipline 154, 155, 167
Cleanroom 53
Extreme Programming 53
high-discipline methodology 53
Personal Software Process 53
Discipline and Tolerance 53
Distractions 150
Distributed development 182
Dixon, N. 54, 102
Documentation 25, 154, 168, 240, 246, 252
recommendations for 25, 177
Drafts 82, 83, 90
Drinking together 187
DSDM 203, 215, 218
Duration of accountability 169
E
eBucks.com 61, 87, 159, 206, 210
Ecosystems 109
Efficiency, expendable 158
Eggs over easy 19
Ehn, P. 7, 28, 33, 56, 225, 241-254
Embellishment 142, 211
Emergent 221
Engineering 29
Equivocality 13
Erg-seconds xxiv, 79-81, 91
applying formula to communication 81
Evant 78, 86, 97
Expert-in-Earshot strategy 59, 83
Exploratory activities 155
Extreme Hour 139
Extreme Programming. See XP.
F
Face-to-face communication 80, 148, 149, 167, 221
Failure modes 48-55
Fear 142, 146
Feature-Driven Design 215
Feedback 66, 167, 179
Fingerhut 161
Flow 27, 60
Focus time 209, 211
Fowler, M. 84, 85, 215
Fox, C. 51, 221
Fox, R. 17
Frakes, C. 51, 221
G
Games 25, 241
competitive 26
cooperative 26, 201
Cooperative Game principle 31-38, 175
infinite 37
language 244-245
non-zero-sum 25
playing amicably 241
positional 25
types of 25-26
winning 255
zero-sum 25
Gas-dispersion 79
Gates, B. 183
Glass, R. 29, 55, 58
Goel, V. 7
Gold Rush strategy 133, 158, 159
Goldplating 62
Goldratt, E. 156
Golf clubs 63
Good at looking around 67
Good citizenship 102
Graham, I. 135
Grenning, J. 215
Gries, D. 15, 44, 52
Guindon, R. 45
H
Hammer, M. 82
Heat-dispersion 79
Heroes 71
Herring, R. 83
Heuristic methodologies 119
High-bandwidth communication 172
Highsmith, J. xxi, xxiii, 54, 67, 120, 134, 136, 146, 154, 164, 199, 203, 215, 223
Hill, A. 62
Hock, D. 70, 223
Hodgson, R. 110, 115
Hohmann 57
Hohmann, L. xxiii, 13, 104
Holistic Diversity strategy 205-206
Homesteading the Noosphere 183
Hostile XP 103
Hovenden, F. 109
Human strengths 67-72, 167
Humphrey, W. 15, 52, 148
Hunt, A. 15, 215
I
IBM 136
Inconsistency 52
Incremental development 48-49, 186, 189
Increments 179
Industrial Logic 87
Informance 57, 140
Information
radiators 84, 93, 167
received 10
sticky 159
value of 164
Information flow 77-91, 167
Ingrid Project 186
Instability 133
Intermediate deliverables 153
Intermediate work products 34, 168
Intolerance 141
Invent-Here-Now Imperative 51, 108
Iterations 165
Iterative development 48, 185
itself 36
J
Jacobson, I. 30
Jeffries, R. 52, 87, 135, 165, 215
Johnson-Laird, P. 55
Jordaan, M. 210
K
Kelly, J. 90
Kern, J. 215
Kinesthetics 92
Knuth, D. 15
Kohn, A. 63
Kruchten, P. 199
L
Language games 7, 33, 244-245, 250
Larman, C. 199
Laubacher, R. 65
Lave, J. 55, 59
Learning, stages of 14-18
Legal liability, as priority 163, 171
Leuf, B. 79
Level 3 listening 14-18, 249
Light methodologies 163
Line-of-Sight learning 59
Lister, T. 41, 60
Lockheed 90
M
Maier, M. 119
Malleable 69
Malone, T. 65
Marick, B. 215
Martin, R. 135, 215
Mathiassen, L. xxiii, 32
Maturana, H. 9
McCarthy, J. 82
Mellor, S. 215, 220
Memes 79, 84
Merel, P. 139
Metaphor 239
Methodologies 113-172
activities 117
applying 197
conceptual terms 123
Crystal 54, 197-211
elements of 116-119
heavy 142, 151, 164, 216
heuristic 119
high-discipline 167
importance of xx, 170-171
light 155, 163
milestones 118
normative 119
participative 119
process 117
quality 118
rational 119
roles 116
scope 120-122
skills 117
standards 118
team values 118
teams 117
techniques 117
tolerant 54
waterfall 163
work products 117
Methodology
agile 217, 220
design principles 148-165, 188, 201
size 123
weight 123, 150
Micro-touch intervention 99, 258-259
Milestones 118, 119
declarations 119
publications 119
reviews 119
role-deliverable-milestone chart 120
Mock-ups 33
Modalities in communication 91-93, 95
cross-modality timing 92
kinesthetics 92
physical proximity 91
smell 92
sound 92
three-dimensionality 91
touch 92
trust 93
visuals 92
Modalities, removing 94-95
Model building 30
Morale 255
Multisite development 181
Musashi, M. 225, 254-259
N
NASA 72
Naur, P. 28, 32, 176, 225-240
Newkirk, J. 135
NIH. See Not-Invented-Here syndrome
NIHBIDIA award 51
Norges Bank 107
Normative methodologies 119
Not-Invented-Here syndrome 50
O
O'Dell, J. 59
Object Modeling Technique 143
Observing reflectively 256
Office layouts 80, 89-91
Offshore development 181
OMT 143
OPEN Process Specification 135
Open-source development 37-38, 183-184
Opportunity cost, lost 77, 81, 82
Optimizing activities 155
Osmotic communication 81-84, 91, 149, 158, 167, 169, 221
P
Pair programming 31, 53, 59, 77
benefits of 166
information exchange with 80
photo of 78
Parsing Patterns 3-8
Participation 251, 252
Participative methodologies 119
Participatory design 252
Personal prowess 117
Personal Software Process 52, 53, 148
Personality, effects of 45, 60
Physical proximity 91
Pi 124
Piattelli-Palmarini, M. 49
Planning game 169
Precision 124, 128-129
Pride
in accomplishment 64
in contribution 65
in work 63, 167
Private offices 60
Problem size 123, 150-151
Process 117
Process miniature 139, 140
Program modification, cost of 232
Programming in pairs. See Pair programming.
Project interviews 185, 195
Project managers 142
skills of 117
traits of 116
Project map 128
purpose of 126
sample 125
Project plan 125
Project retrospectives 117, 192-194
Project size 123
Projects
C3 48, 69
geographically distributed 81
Ingrid 186
post-mortem 66, 192
priority chart 100
Udall 159
Winifred 158, 180, 206, 220
Promissory notes 153
Props 33
PSP (Personal Software Process) 53, 201
Publication 119
Q
Quality 118
R
Radical colocation 82
Rational methodologies 119
Rational Unified Process 172, 199
Raymond, E. 183
Real-time question-and-answer 93
Rechtin, E. 119
Reenskaug, T. 48
Reflection workshops 67, 87, 190, 195, 208
sample 87
sample poster 193
technique for 193
Reflective practice 255
Relevance 124
Responsibility-Collaborations diagram 127
Responsibility-Driven Design 127
Reviews 119
Rewards 62
Rework 158
Rich, B. 90
Rituals 93
Rock climbing 26
Role descriptions
samples 137
Role-deliverable-milestone chart 120, 135
RoleModel Software 89, 90
Roles 116
Russian programmers 97
S
Satisfice 33
Sawyer, J. 31
Scale 124
Schrage, M. 101
Schwaber, K. 203, 215
Screen flow diagram 126
Scrum xxi, 203, 206, 215, 218
Sears 162
Self-Adapting 184-195
Self-organization 70
Serial development 131
figure of 131
strategy 131
Shannon, C. 8
Shared experience 11, 12
Shu-Ha-Ri 17-18, 194, 249, 254, 255
Simon, H. 33
Skill 117, 154, 155, 161, 241, 242-254, 255
Skunk Works 90
Smalltalk 58, 134
Smell 92
Software development
as engineering 29
as invention 28
Software engineering xviii, 29
Sound 92
Spontaneous behavior 70
Stability 124, 129, 132
Standards 171
definition of 118
high-ceremony 168
Status display 85
Stevens, W. 144
Stickiness 97-99, 159
Strategies
concurrent development 132
Early and Regular Delivery 64
Expert-in-Earshot 59, 83
Gold Rush 133, 158
Holistic Diversity 82, 205
serial-development 131
simplest first, worst second 64
worst-things-first 64
Sufficiency 30, 176-177
Sullivan, K. 164
Sully, P. 46
Sutherland, J. xxi, 215
Sweet spots 178-180, 221
T
Tacit knowledge 136, 154, 168, 169, 227, 240
Taking initiative 70
Talent 61, 72
Tangible 56
Team values 118
Teams 117
building 104
colocated 168
culture of 105
ecosystem in 109
geographically separated 133
morale in 118
personality traits of 116
self-organizing 221
Teamwork 161
Technical Lead 68
Technique guides 136
Techniques 117, 257
Temperature of communication channels 95-96
Texas Instruments 51
Theory building 32, 227-240
Thomas, Dave "Pragmatic" 215
Thomas, Dave A. 43, 215, 221
Thoughtworks 78, 79, 84, 85, 86
Three-dimensionality 91
Tolerance 53, 124, 141, 142, 201
Torvalds, L. 38, 183
Touch 92
Trust 93, 147
U
Unified Process 172
Use cases 126
User interface designer 116, 117
User story 165
V
Value
of flexibility 165
of information 164
Varela 9
Varela, F. 9
Videotape
as documentation 95, 149
short clips 177
Virtual teams 180-184
and distributed development 182
and multisite development 181
and offshore development 181
and open-source development 183
VISA clearing program 70
Visibility 124
Visible progress 171
Visuals 92
W
Warm communication channels 172
Waterfall methodology 163
Web cameras 83
Webb, D. 53
Weick, K. 64, 105
Weinberg, G. xviii, 41, 88
Wenger, J. 55, 59
Whiteboards 59, 92, 166, 177
printing 149, 203
Wiegers, K. 52
Wilkinson, B. 44, 52
Wine 3
Winifred Project 34, 88, 180, 206, 220
Wirfs-Brock, R. 127, 146
Wittgenstein, L. 241-254
Wooden, J. 61
Work examples, copying and modifying 136
Work products 117
X
XP 17, 53, 59, 66, 89, 98, 118, 134, 143, 163, 164, 165-169, 176, 201, 203, 206, 215, 239
caves and common room layout 60
coaching 54
consistency 167
courage 167
discipline 167
hostile 103
refactoring 167
values 166
Y
Yourdon, E. 102