Q: How do you get to Carnegie Hall?
A: Practice, practice, practice!
I want to help you master the art of Agile development.
Agile development, like any team-based approach to software development, is a fundamentally human art, 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 art? Practice!
First and foremost, this book is a how-to guide. It’s a detailed description of one way to practice Agile development. It’s based on Extreme Programming, but it also brings in ideas and practices from Scrum, Kanban, DevOps, Lean Software Development, Lean Startup, and more. Ultimately, it’s a practical guide that will allow you to successfully bring Agile development to your team and organization—or it will help you discover that Agile isn’t a good choice for your situation.
Second, this book exists to help you master the art of Agile development. Mastering agility means going beyond a cookbook of practices. Software development is too context-sensitive for one approach to be a perfect fit, and too nuanced for any book to teach you how to master it. Mastery comes from within: from experience and an intuitive understanding of the ripples caused by a pebble of a choice.
I can’t teach you how your choices will ripple throughout your organization. I 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 repeat. What was the same? What was different? Why? Then do it again. And again.
At first, you may struggle to understand how to apply each practice. They can look easy on paper, but putting some practices into action will be difficult. Keep practicing until they’re easy.
As Agile becomes easier, you’ll discover that some of my advice doesn’t work for you. In the beginning, you won’t be able to tell if the problem is in the instructions I provide or in the way you’re following them. Keep practicing until you’re certain. When you are, break the rules. Modify my guidance to work better for your specific situation. Every practice has an “Experiments and Alternatives” section with ideas to explore.
One day, rules will no longer hold any interest for you. After all, Agile isn’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 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. I take my years of experience with Agile development and distill them down into a single, clearly defined, comprehensive approach.
That allows me to use plain, straightforward language. I include a lot of practical tips. I candidly describe when my approach won’t work, and what alternatives to consider when it doesn’t. Chapter 2 will help you get started.
There’s a downside to discussing just one approach: no single approach is appropriate for everyone. My advice may not be appropriate for your team or organization. Read Chapters 4 and 5 to understand the overall conditions needed for success, and check the “Prerequisites” section of each practice for specifics.
But don’t just assume a particular practice won’t work for you. Some of the practices 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 with how they work in your environment, then change them.
I’ve been putting these ideas into practice for more than 20 years. In the right environment, they really work. Agile development has been more fun, and more successful, than any other approach to software development I’ve tried. Come join the ride.
This second edition of The Art of Agile Development is a complete, ground-up rewrite of the first edition. It retains the down-to-earth, practical approach of the first edition, along with most of the first edition’s practices. But nearly all of them have been rewritten to take advantage of 14 years of advancements in Agile practice—not to mention 14 more years of experience on my part.
I’ve completely restructured the book to allow for incremental adoption and to better reflect teams’ real-world Agile usage. The principles and customization discussed in Part III of the first edition have been distributed among the practices to make them more prominent and accessible, and I’ve expanded every practice with suggestions for experimentation.
Notable additions include:
An in-depth guide to adopting Agile and customizing your adoption to your company’s needs, based on the Agile Fluency1 Model I created with Diana Larsen.
A new chapter on scaling Agile, based on my experience helping companies large and small.
A new chapter on DevOps, with new content about working with operations and security, as well as DevOps-inspired updates throughout the rest of the book.
Guidance on making Agile work with remote teams; many new practices, stories, and ideas; and too many other improvements and changes to mention.
This book is for everyone who works with an Agile team, or hopes to do so in the future. That includes programmers, of course, but it also includes managers, executives, domain experts, testers, product managers, project managers, architects, operations, security, designers, and business analysts. Agile teams are cross-functional; this book reflects that fact.
The book is designed to be used as a reference as well as read cover-to-cover. Each practice in Parts II through IV is designed to be read on its own. The “Ally” boxes in the margins of the print edition and the hyperlinks in the ebook edition will help you cross-reference. The print edition is additionally designed to pick up and browse. Flip through the book and stop to read more deeply when a callout grabs your attention.
If you’re a manager or executive who wants to understand how Agile can or should work in your company, read Part I. If you’re a team-level manager, add “Management”, and possibly the other practices in Chapter 10.
If you’re a team member or manager interested in bringing Agile to your company, or improving the way Agile is practiced at your company, read the whole book from cover to cover. Part I will help you understand how to introduce Agile ideas. The remainder of the book will help you understand how to put Agile into practice.
If you’re part of an Agile team and just want to learn enough to do your job, you can focus on the practices in Parts II and III. Start with Chapter 1 to get an overview, then read through the practices your team uses. If your team uses practices that aren’t listed in the table of contents, check the index. They could be under a different name.
If you’re not part of an Agile team, but you’re working with one, ask them for suggestions about what to read. Product managers, product owners, and designers, start with Chapter 8 and “Purpose”. Security and operations, check out “Build for Operation”, “Blind Spot Discovery”, and “Incident Analysis”. Testers, take a look at Chapter 16.
If you’re merely curious about Agile development, start by reading Chapter 1. Afterward, take a look at Parts II, III, and IV. Start with the practices that look most interesting. You can read them in any order.
I’m fortunate to have several notable collaborators for this edition. Gitte Klitgaard wrote “Safety”, expertly covering the topic of psychological safety. Diana Larsen wrote “Team Dynamics” and “Impediment Removal”, bringing in her decades of experience in organizational and team development. Shane Warden, my coauthor for the first edition, wasn’t able to contribute new material to this edition, but he remained a valuable sounding board, and our work on the first edition formed the basis for this edition.
Gitte Klitgaard is an Agile coach, trainer, and mentor focusing on helping organizations implement psychological safety, responsibility, and accountability. Gitte is authentic; she will cut to the chase and help people become themselves, thereby reaching success.
Her community contributions include organizing coach camps and speaking at conferences, where she highlights topics such as mental health and psychological safety and makes them accessible. She creates safe and respectful environments at work and outside. She listens to and engages the more silent voices and minority groups.
In her spare time, Gitte collects LEGO and Yodas and keeps in touch with friends from all over the globe, including some she considers her second family.
Gitte is owner of Native Wired and has led change at companies such as LEGO, Spotify, and Mentimeter.
For over 20 years, Diana Larsen has contributed to the foundations and extensions of Agile thought and to the practice of cultivating and enabling skilled teams. Diana coauthored Agile Retrospectives, Liftoff, 2nd ed., Five Rules for Accelerated Learning, two new books in process, and The Agile Fluency Model: A Brief Guide to Success with Agile ebook. Serving as a principal coach, consultant, facilitator, speaker, and mentor, she continues her contributions and lives up to her Agile Fluency Project title, Chief Connector. Diana lives in Portland on the US upper left coast.
Shane Warden is an engineering leader and writer, notably the coauthor of The Art of Agile Development (1st edition) and Masterminds of Programming. When he’s not working, he helps give animals good homes.
The following typographical conventions are used in this book:
Audience boxes identify the target audience for each Agile practice.
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant widthUsed for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width boldIndicates code additions in running code examples.
Constant width strikethroughRepresents code deletions in running code examples.
Supplemental material is available for download at https://www.jamesshore.com/v2/books/aoad2.
Please send an email to bookquestions@oreilly.com if you have a technical question or a problem using the material.
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “The Art of Agile Development by James Shore (O’Reilly). Copyright 2022 James Shore and Big Blue Marble LLC, 978-1-492-08069-5.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com.
For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit http://oreilly.com.
Please address comments and questions concerning this book to the publisher:
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/art-of-agile-dev-2e.
Email bookquestions@oreilly.com to comment or ask technical questions about this book.
For news and information about our books and courses, visit http://oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://youtube.com/oreillymedia
This book collects inspiration from too many sources to count. I’ve acknowledged as many as I could throughout the book, but I undoubtedly have forgotten some. (Please accept my apologies.) I particularly want to recognize Kent Beck, Ron Jeffries, and Ward Cunningham for their creation of Extreme Programming, which got me started on my Agile journey. Alistair Cockburn and his Software Roundtable was an important guide during the beginning of that journey, as was the vigorous debate and discussion on Ward Cunningham’s C2 Wiki. Thank you also to Diana Larsen, whom I’ve worked with for many years, and whose perspective balances mine so well. And, of course, Martin Fowler, whose thoughtful writing has inspired me for many years.
O’Reilly’s support for this edition has been nothing short of exemplary. I owe a huge thank you to Gary O’Brien, my development editor, who provided constant feedback and support. Thanks also to Melissa Duffield, who helped shepherd the book to success; Ryan Shaw, who convinced me it was time for a second edition; Deborah Baker, who prepared the book’s Early Release editions; Suzanne Huston, who helped make sure people knew about the book; Nick Adams and the O’Reilly Tools team, who built the production pipeline and dealt with my esoteric and picky formatting demands; Christopher Faucher, who oversaw the transformation from “raw manuscript” to “completed book;” Tonya Trybula and Stephanie English, who fixed my grammatical quirks; Kate Dullea, who converted my hand-drawn sketches into figures you can actually understand; and Estalita Slivoskey, who made sure you could find everything in the index.
Speaking of feedback, a special round of thanks goes to my reviewers. The review was conducted in the open, and dozens of people contributed over 700 feedback emails. Nearly every one was insightful and useful, and they resulted in a better book. Thanks also to the people who responded to my specific requests for feedback. All together, thank you to: Adrian Sutton, Anthony Williams, Avi Kessner, Bas Vodde, Benjamin Muskalla, Bill Wake, Brad Appleton, C. Keith Ray, C.J. Jameson, Christian Dywan, David Poole, Diana Larsen, Diego Fontdevila, Emily Bache, Erik Peterson, “Evan M,” Franz Amador, George Dinwiddie, Gojko Adzic, Jason Yip, Jeff Grigg, Jeff Patton, Jeffrey Palermo, Johan Aludden, Ken Pugh, Krishna Kumar, Liz Keogh, Luiza Nunes, Marcelo Lopez, Markus Gaertner, Martin Fowler, Michal Svoboda, Nicolas Paez, Paul Stephenson, Peter Graves, Reuven Yagel, Ricardo Mayerhofer, Ron Jeffries, Ron Quartel, Sarah Horan Van Treese, Steve Bement, Thomas J. Owens, Todd Little, and Ward Cunningham.
Extra thanks to the reviewers who went above and beyond, reading and commenting on nearly every part of the book: Bas Vodde, Bill Wake, Ken Pugh, Martin Fowler, and Thomas J. Owens.
The first edition also benefited from an open review process, and those benefits accrued to this edition. Thank you 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, and to Brian Marick, Ken Pugh, and Mark Streibeck for their comments on the completed draft.
Finally, thank you to my wife, Neeru, once again. This time, you knew what you were in for, and still your support never wavered. I couldn’t do it without you.
1 “Agile Fluency” is a registered trademark of Agile Fluency Project LLC.