"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:
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.
Click below for Sample Chapter related to this title:
List of Figures.
List of Stories.
Introduction: Unknowable and Incommunicable.
The Problem with Parsing Experience.
The Impossibility of Communication.
Three Levels of Listening.
So, What Do I Do Tomorrow?
Software and Poetry.
Software and Games.
A Second Look at the Cooperative Game.
What Should This Mean to Me?
Them's Funky People.
Overcoming Failure Modes.
Working Better in Some Ways than Others.
Drawing on Success Modes.
What Should I Do Tomorrow?
Convection Currents of Information.
Jumping Communication Gaps.
Teams as Communities.
Teams as Ecosystems.
What Should I Do Tomorrow?
An Ecosystem That Ships Software.
Methodology Design Principles.
XP under Glass.
Why Methodology at All?
What Should I Do Tomorrow?
Light but Sufficient.
What Should I Do Tomorrow?
Shaping the Crystal Family.
Crystal Orange Web.
What Should I Do Tomorrow?
The Agile Alliance.
Supporting the Values.
Peter Naur, Programming as Theory Building.
Pelle Ehn, Wittgenstein's Language Games.
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.
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
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
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.
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:
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:
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.
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.
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.
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:
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.
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.
I am not the only person who is using these ideas:
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."
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:
The series has these three main tracks:
Two books anchor the Agile Software Development Series:
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