Preface
Q: How do you get to Carnegie Hall?
A: Practice, man, practice!
We want to help you master the art of agile development.
Agile development, like any approach to team-based software development, is a fundamentally human art, one subject to the vagaries of individuals and their interactions. To master agile development, you must learn to evaluate myriad possibilities, moment to moment, and intuitively pick the best course of action.
How can you possibly learn such a difficult skill? Practice!
First and foremost, this book is a detailed description of one way to practice agile development: Extreme Programming (XP). Its a practical guide that, if followed mindfully, will allow you to successfully bring agile development in the form of XP to your teamor will help you decide that its not a good choice in your situation.
Our second purpose is to help you master the art of agile development. Mastering agility means going beyond our cookbook of practices. Agile development is too context-sensitive for one approach to be entirely appropriate, and too nuanced for any book to teach you how to master it. Mastery comes from within: from experience and from an intuitive understanding of ripples caused by the pebble of a choice.
We cant teach you how your choices will ripple throughout your organization. We dont try. You must provide the nuance and understanding. This is the only way to master the art. Follow the practices. Watch what happens. Think about why they worked... or didnt work. Then do them again. What was the same? What was different? Why? Then do it again. And again.
At first, you may struggle to understand how to do each practice. They may look easy on paper, but putting some practices into action may be difficult. Keep practicing until theyre easy.
As XP gets easier, you will discover that some of our rules dont work for you. In the beginning, you wont be able to tell if the problem is in our rules or in the way youre following them. Keep practicing until youre certain. When you are, break the rules. Modify our guidance to work better for your specific situation.
Parts I and II of this book contain our approach to XP. Part I helps you get started with Extreme Programming; Part II provides detailed guidance for each of XPs practices. Parts I and II should keep you occupied for many months.
When youre ready to break the rules, turn to Part III. A word of warning: there is nothing in Part III that will help you practice XP. Instead, its full of ideas that will help you understand XP and agile development more deeply.
One day youll discover that rules no longer hold any interest for you. After all, XP and agile development arent about following rules. Its about simplicity and feedback, communication and trust, youll think. Its about delivering valueand having the courage to do the right thing at the right time. Youll evaluate myriad possibilities, moment to moment, and intuitively pick the best course of action.
When you do, pass this book on to someone else, dog-eared and ragged though it may be, so that they too can master the art of agile development.
For the Pragmatists
What if you dont want to master a so-called art? What if you just want to develop good software?
Dont worrythis book is for you, too. Parts I and II are just what you need. We took our years of experience with agile development and Extreme Programming and distilled them into a single, clearly defined, comprehensive approach.
This approach allows us to use plain, straightforward language without caveats or digressions. We get to include a lot of practical tips. We candidly describe when our approach wont work and what alternatives to consider when it doesnt.
Theres a downside to discussing just one approach: no single methodology is appropriate for everyone. Our advice may not be appropriate for your team or situation. Be sure to read before putting our advice into practice.
You may be able to adopt part of XP even if you cant adopt all of it. The Contraindications section of each practice in Part II describes when a practice is inappropriate. If this applies to your situation, the Alternatives section will help you decide what to do instead.
Dont go too far and automatically assume that a particular practice wont work for you. Some of the ideas in this book are counterintuitive or just dont sound like fun. Most of them work best in concert with the others. If you can, try the practices as written for a few months, gain some real-world experience on how they work in your environment, and then change them.
Weve been putting these ideas into practice for years. In the right environment, they really work. Agile development has been more fun, and more successful, than any other approach to team software development weve tried. Come join the ride.
Who Should Read This Book
This book is for anyone who is, will be, or wants to be part of an agile team. That includes programmers, of course, but it also includes domain experts, testers, projects managers, architects, designers, and business analysts. Agile teams are cross-functional; this book reflects that fact.
If youre a leader or youre interested in bringing agile development to your team or organization, you should read the whole book from cover to cover. Part I introduces agile concepts and describes how to adopt XP. Part II describes each of XPs practices in detail. Part III goes beyond XP, looking at the principles that allow you to create your own agile method by customizing XP to your particular situation.
If you just want to learn enough to do your job, you can focus primarily on Part II. Start with in Part I to get an overview, then read through the practices in Part II that apply to your work. Each practice starts with a description of the audience it applies to, such as Programmers, Customers, or Testers.
If youre merely curious about agile development, start by reading Part I. Again, provides a good introduction. Afterwards, take a look at the practices in Part II. Start with the ones that look most interesting; you can read them in any order.
About the tudes
Have you ever heard a musician playing scales? Thats an tude (if a boring one). An tude teaches mastery through precise and careful repetition. Eventually, the tude is abandoned, but the skills remain.