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). It’s a practical guide that, if followed mindfully, will allow you to successfully bring agile development in the form of XP to your team—or will help you decide that it’s 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 can’t teach you how your choices will ripple throughout your organization. We don’t 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 didn’t 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 they’re easy.
As XP gets easier, you will discover that some of our rules don’t work for you. In the beginning, you won’t be able to tell if the problem is in our rules or in the way you’re following them. Keep practicing until you’re 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 XP’s practices. Parts I and II should keep you occupied for many months.
When you’re 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, it’s full of ideas that will help you understand XP and agile development more deeply.
One day you’ll discover that rules no longer hold any interest for you. After all, XP and agile development aren’t about following rules. “It’s about simplicity and feedback, communication and trust,” you’ll think. “It’s about delivering value—and having the courage to do the right thing at the right time.” You’ll 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.
What if you don’t want to master a so-called art? What if you just want to develop good software?
Don’t worry—this 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 won’t work and what alternatives to consider when it doesn’t.
There’s 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 Chapter 4 before putting our advice into practice.
You may be able to adopt part of XP even if you can’t 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.
Don’t go too far and automatically assume that a particular practice won’t work for you. Some of the ideas in this book are counterintuitive or just don’t 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.
We’ve 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 we’ve tried. Come join the ride.