Agile Software Development

Description

• Copyright 2002
• Edition: 1st

• Book
• ISBN-10: 0-201-69969-9
• ISBN-13: 978-0-201-69969-2

"Coming of age for software developers means understanding that software is a cooperative effort, not something individuals do in isolation. This is a book that teams of software developers can thrive upon, full of sensible advice for a cooperative development approach."

--Tom DeMarco, The Atlantic Systems Guild

Software development paradigms are shifting. The development group's "team" ability, and the effects of the individual developer, become more important as organizations recognize that the traditional approach of increasing process pressure and overworking team members is not meeting getting the job done. The pioneers of Agile methodologies question the preconceived processes within which development teams work. Rather than adding to the burden of the individual developer, Agile asks "how can we change the process so that the team is more productive, while also improving quality?" The answer is in learning to play the "game."

Written for developers and project managers, Agile Software Development compares software development to a game. Team members play the game knowing that the ultimate goal is to win--always remembering what they have learned along the way, and always keeping in mind that they will never play the same way twice. Players must keep an open mind to different methodologies, and focus on the goal of developing quality software in a short cycle time.

Based on a decade's work and research, and interviews with software project teams, this book presents sound advice for bringing difficult projects to successful conclusion with a minimum of stress. It includes advice on:

• The principals behind agile methodologies
• Which methodologies fit different projects--including appendixes to select the appropriate methodology on a project
• New vocabulary for describing methodologies
• Just-in-time methodology tuning
• Managing the incompleteness of communication
• Continuous methodology reinvention
• The manifesto for agile software development

Today's software developers need to recognize that they have a number of methodologies to choose from. With this book as a guide, they can break free of nonproductive habits, move beyond old routines, and clear a new path to success.

0201699699B09142001



Extras

Related Article

Internationally Agile



Sample Content

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



Updates

Submit Errata

