in 99 words
We want you to master the art of agile development.
Mastery comes from within; we can't teach it. It requires experience and intuition. You must learn to evaluate myriad possibilities and pick the best course of action. To do so, practice and experiment; follow the rules, then break them; pay attention to what works and what doesn't.
To help, we provide this cookbook. It's a practical guide for all members of the agile team. Our cookbook gives you rules to follow and guidance in breaking them. You can read it cover to cover or use it as a reference.
snow falls once again
a year of practice and thought
mastery is yours
Behind the Scenes
Download this poster!
The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.
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 of 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. 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 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 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.
For the Pragmatists
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 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 Adopting XP 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 is true for 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 out 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.
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, project managers, architects, designers, and business analysts. Agile teams are cross-functional; this book reflects that fact.
If you're a leader or 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 XP's 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 Chapter 3 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 you're merely curious about agile development, start by reading Part I. Again, Chapter 3 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? That's an étude (if a boring one). An étude teaches mastery through precise and careful repetition. Eventually, you'll change your practices, but the underlying principles will remain.
Extreme Programming is our étude for software development. We hope that practicing Extreme Programming week after week will help you master agile development. Eventually, you'll change your practices, but the underlying principles will remain.
Besides the overarching étude of Extreme Programming, we've included a mini-étude for each major theme of agile development. Beginning agile teams may use the études to refine their practice of agile development. As you gain experience, look deeper; use the études to help connect Part II's detailed practices to Part III's general principles.
These études are also useful for teams not currently practicing XP.
Either way, the études require thought to be effective. Each étude provides information, but it doesn't tell you how to act on that information. Think about it. What did you learn from the étude? What was frustrating or exciting? How does that information affect your work? What will you do about it? Without attention and reflection—that is, mindfulness—the études are just games.
It's no coincidence that you need mindfulness to master the art of agile development as well. You have to think about more than XP's practices for it to be effective.
Like musical études, our mini-études work best when you repeat them. We've designed them to take half an hour, so you can (and should) practice them every day for a week or more. Unlike musical études, these agile exercises work best when you include your whole team. The more you all understand about the process and where everyone fits in, the better you will work together.
To start, you need a quiet work area capable of holding everyone in your team comfortably. There should be a whiteboard or wall where you can hang or post index cards between meetings. There must also be sufficient space to break into small groups of two or three people to talk softly without disturbing other groups.
We've found it valuable to use a timer, whether a stopwatch or a kitchen timer, to keep the session moving. Each étude has a few parts of five to ten minutes. Although that time will seem to flow quickly on your first attempts, respect the time limits. You'll perform the étude again tomorrow, so it's okay if you don't finish everything.
Choose one member of your team to facilitate the étude by watching the time (perhaps calling out "one minute remaining" when appropriate) and promoting discussion. Again, the first session may be hard, but a good facilitator can encourage everyone to continue.
At the end of each étude, we recommend spending a few minutes debriefing. What did you learn? Are there questions and ideas you can follow up on during your regular work? If you've been trying this exercise for more than a week, are you still getting valuable results?
If you're new to XP and agile development, we recommend strongly that you perform each étude while you study the related chapter as a team. Besides exploring one particular theme in agile development, each étude can illuminate an aspect of how your team works together on your agile project.
We speak in first-person singular rather than first-person plural in the rest of this book. (We say "I", not "we".) We include a lot of personal anecdotes and experiences,te and the singular form worked better as a result. However, this book is unquestionably the result of a partnership between two authors and our use of the word "I" is merely a convenience.
We owe a debt of gratitude to Elisabeth Hendrickson for her contribution of the Exploratory Testing section. Her expertise and writing skill made the material sparkle. For more of Elisabeth's writing, visit http://www.testobsessed.com/.
We stole good ideas wherever we could find them. Kent Beck, Ron Jeffries, and Ward Cunnningham each had a hand in the ideas that led to XP, and we stole liberally from those. In addition to XP itself, Kent Beck introduced us to the idea of XP practices as études. Ward Cunningham introduced us to the notion of technical debt, a concept we use heavily. Brian Marick's series of essays, "Agile Testing Directions"1 influenced our thoughts on agile testing and the role of testers on agile teams.
James had the opportunity to work with Joshua Kerievsky on an Industrial XP (IXP)2 project for half a year. He learned a lot from that project; the Vision practice in particular was inspired by IXP's Project Chartering practice. David Schwartz and Amy Schwab of True North pgs, Inc.3 provided the specific vision format that we use, as well as the term project community. Their Mastering Projects workshop is excellent; take it when you have the opportunity.
Thank you to our editor, Mary Treseler O'Brien, for providing vision (where necessary), trust (where appropriate), and deadlines (where frightening). This book would not be what it is without you gently nudging us in directions different from our original ideas.
Thanks also to our army of reviewers, who provided over one thousand comments and suggestions on our mailing list. In particular, thanks to Adrian Howard, Adrian Sutton, Ann Barcomb, Andy Lester, Anthony Williams, Bas Vodde, Bill Caputo, Bob Corrick, Brad Appleton, Chris Wheeler, Clarke Ching, Daði Ingólfsson, Diana Larsen, Erik Petersen, George Dinwiddie, Ilja Preuß, Jason Yip, Jeff Olfert, Jeffery Palermo, Jonathan Clarke, Keith Ray, Kevin Rutherford, Kim Gräsman, Lisa Crispin, Mark Waite, Nicholas Evans, Philippe Antras, Randy Coulman, Robert Schmitt, Ron Jeffries, Shane Duan, Tim Haughton, and Tony Byrne for their extensive comments. Special thanks to Brian Marick, Ken Pugh, and Mark Streibeck for their comments on the completed draft.
Every work builds on what came before. I was fortunate to have not just one, but many giants to stand upon. Without the inspired work of Kent Beck, Alistair Cockburn, Ward Cunningham, Tom DeMarco, Martin Fowler, Ron Jeffries, Timothy Lister, Steve McConnell, and Gerald Weinberg, I wouldn't have anything close to the understanding of software development that I have today. It's thanks to their example that this book exists. In particular, thanks to Alistair Cockburn for generously inviting me to his roundtable and introducing me to the agile community.
If giants enabled me to contribute to this book, then Kim Eaves and the Denali team brought the stepladder. Without their enthusiastic support, I never would have been able to try that crazy XP thing. Thanks also to Rob Myers for his ever-friendly consideration of my rants.
I also gratefully acknowledge my coauthor and friend, Shane Warden. This project morphed from a little 100-page second edition to a 400-page monster. You didn't complain once. Thanks for putting up with me. (And hey! Nice book.)
Finally, thank you, Neeru, my loving and patient wife. I used to think authors thanking their families was cliché. Now I understand. I couldn't have finished this book without your support.
Thanks to Jim for arguing with me while writing the first version of this book (it's better for it) and for convincing me that the second edition was worth doing.
Thanks to Allison and Andrew for the tools we used to write this book.
Thanks to my family for supporting me (and not grumbling too much while I sat upstairs and wrote very slowly), and to my friends for dragging me out of my house once in a while.
Thanks also to the other contributors to Parrot and Perl 6 for being unwitting collaborators, examples, and victims of some of the ideas in this book. The work we do continually amazes me.