The Art of Agile Development contains practical guidance for anyone considering or applying agile development for building valuable software. Plenty of books describe what agile development is or why it helps software projects succeed, but very few combine information for developers, managers, testers, and customers into a single package that they can apply directly.

This book provides no-nonsense advice on agile planning, development, delivery, and management taken from the authors' many years of experience with Extreme Programming (XP). You get a gestalt view of the agile development process, including comprehensive guidance for non-technical readers and hands-on technical practices for developers and testers.

The Art of Agile Development gives you clear answers to questions such as:

• How can we adopt agile development?
• Do we really need to pair program?
• What metrics should we report?
• What if I can't get my customer to participate?
• How much documentation should we write?
• When do we design and architect?
• As a non-developer, how should I work with my agile team?
• Where is my product roadmap?
• How does QA fit in?

The book teaches you how to adopt XP practices, describes each practice in detail, then discusses principles that will allow you to modify XP and create your own agile method. In particular, this book tackles the difficult aspects of agile development: the need for cooperation and trust among team members.

Whether you're currently part of an agile team, working with an agile team, or interested in agile development, this book provides the practical tips you need to start practicing agile development. As your experience grows, the book will grow with you, providing exercises and information that will teach you first to understand the rules of agile development, break them, and ultimately abandon rules altogether as you master the art of agile development.

"Jim Shore and Shane Warden expertly explain the practices and benefits of Extreme Programming. They offer advice from their real-world experiences in leading teams. They answer questions about the practices and show contraindications - ways that a practice may be mis-applied. They offer alternatives you can try if there are impediments to applying a practice, such as the lack of an on-site customer.

--Ken Pugh, Author of Jolt Award Winner, Prefactoring

"I will leave a copy of this book with every team I visit."

--Brian Marick, Exampler Consulting

Rating:

Rating:

Rating:

Cookbook on Agile,  May 19 2009
Submitted by George Romaniuk   [Respond | View]

My encounter with agile took place in 2004 when my company wanted to formalize the entire product development process. We took this opportunity to learn more about agile and apply it our software development.

I read few short articles and a book about agile but there was not enough practical information to convince us that we will be safe embracing agile methodology.

I learned about this book quite recently from practitioners of agile, read the book and also participated in a very interesting discussion club.

The title of this book is in my opinion little misleading – I was expecting to read about some esoteric topics related to agile software development but to my great surprise I found almost a “Manual” or a “Handbook” of agile software development.

The art is being taught in a very well defined environment, little too idealized in my opinion but with clear boundaries and good instructions what to do in case your situation is outside of this environment. I read the book from page one in natural page order and noticed that the book was getting more interesting as I was progressing.

There is a great body of down to earth instructions for beginners, not only related to pure software development but also relevant to setting up the team in your company’s environment.

The book also offers good discussion of product requirements, the role and approach to testing and to some extent - making decisions regarding software architecture.

The book has a phenomenal bibliography and inspired many thoughts about the nature of software development and similarities between software development and industrial mass production environment

I am sure that the book is not going to end the writing career of the authors and a follow-up will be available soon, discussing issues like rewards and compensation in companies practicing agile methodology.



Easy read, VERY practical, great how-to book,  May 19 2009
Submitted by Cindy Margules   [Respond | View]

As a complete novice to Agile, this was my first book. Although there were a few areas that I had to reread for comprehension - it is written in such a way as to provide a complete foundation of understanding, both for the novice and the expert.

The book utilizes not only the practical "how to" but also deals with the different behaviors displayed and how to manage those - which is typically the `sticky point' in any change management effort.

As a 15-year project management veteran, the book was artfully crafted as it employs real world examples, states the relationships between the various principles of XP - and why they are all important, and submits strong cases of why partial implementations fail, and even lists additional alternatives to the typical implementation. I found the book doesn't sell "XP", but does make a solid case for the value systems that XP supports.

It is written in a very easy to read format with etudes, approach, and questions, and has constant cross-references within the book and to outside sources which is extraordinarily helpful. There is a bit of reiteration which can be irritating to some, but also can be reinforcing as it is done in various styles. Overall, a must have for the Agile developer.


A powerful book.,  May 18 2009
Submitted by P Eastwood   [Respond | View]

The Art of Agile Development is a very powerful book. To people like myself who are approaching Agile for the first time it is a compelling and energizing read, completely capturing the spirit of Agile as well as carefully explaining the mechanisms of XP. It is a book that can be used as a reference for experienced practitioners of XP, but I think even those who have read Beck and others will want to read it from cover to cover.

There are a lot of “good sense” aspects to many of the practices of XP and progressing through the first chapters, the reader quickly understands the simplicity and workings of each one of them. But keep reading! The book is full of enlightening moments as the author focuses in on the ties that bind the practices together, explaining the practices’ workings and their sustaining relationships using real world examples.

I highly recommend this book to anyone involved in building technical teams inside or outside of software development.



Recommended Reading,  May 12 2009
Submitted by David Wight   [Respond | View]

The Art of Agile Development is one of a handful of books that should be read by any serious practitioner of agile software development. It complements my other favorite books, with an emphasis on practical implementation of agile practices and the issues and complications that inevitably arise. Although the book focuses on practices derived from XP (eXtreme Programming), I found it to be relevant and applicable to agile development in general, and recommend it to other ScrumMasters and agile proponents. It provides clear explanations, rationales and practical examples of concepts I’ve studied and practiced for years, but still struggle to master.

The authors define the scope and organization of the book in the Preface and then deliver exactly what they promise in a clear and concise way. Part 1 includes a brief but effective summary of agile principles and of XP concepts and practices. I especially liked their opening section describing how an agile approach aligns with success.

After pointing out that agile is no silver bullet and that implementation can be a challenge, the authors discuss the specifics of introducing XP into an organization and present a concrete implementation as a starting point. In Part 2, they present a set of 37 practices that, taken together, form a practical approach for getting started. Their descriptions include practical advice, specific suggestions and potential pitfalls.

Part 3 is intended to provide guidance to experienced agile practitioners as they develop and hone agile practices to fit their specific circumstances. There are really no new ideas presented, but it is a succinct and well organized presentation of values, principals and practices that are critical to successful implementation of any agile methodology. The book concludes with an excellent bibliography.


The Agile Fabric, Clearly Explained,  May 09 2009
Submitted by Scott Killen   [Respond | View]

"The Art of Agile Development" is more than good book; it is also an important book. It weaves many agile concepts in to a thoughtful fabric and extends the body of knowledge in practical ways.

Structurally, the book is divided into three parts; an introductory section, a practices section and a section on mastery. Each part is wholly contained and may be read independently of the others. Although XP is the centerpiece of discussion, clearly Scrum and Lean also strongly influenced content.

There is so much to like about this book that a short review cannot do justice. But I do want to highlight sections of particular value.

To understand the maturity of your agile team, skip the Nokia test and head for the section entitled "Assess Your Agility". Though the test does lean towards measuring XP maturity, each question is carefully crafted to be a point of introspection for thoughtful readers.

The sections on risk and slack are the clearest, most compelling, descriptions I've ever read of the how and why of risk planning and mitigation in an agile project. If you've had difficulty with release planning because of inconsistent velocities, then Shore and Warden open their toolbox for you.

The case for pair programming, perhaps the most controversial of all XP practices, is built brick by brick into a foundational practice. I've not seen such an airtight argument before.

The section on refactoring, including a step-by-step walkthrough, opened my eyes. I thought I understood refactoring until I read this masterful presentation.

Many people confuse the terms "value" and "principle"; incorrectly using them interchangeably. In the mastery section, the authors distinguish the two, and explain how fundamental values lead to the adoption of guiding principles and then to the implementation of tangible practices.

Shore and Warden make a valuable contribution to agile literature with this book. I'm making a list of people I work with that need to read it.


Recommended,  February 24 2009
Submitted by Krzysztof Satola   [Respond | View]

The Art of Agile Development written by James Shore and Shane Warden is about managing a successful eXtreme Programming (XP) team. It reveals many possible ways of leading an agile team through a software project. The book is full of examples, explanations, tips and good practices.

Great deal of issues covered in this book would make it hard to read but the authors made a tremendous work organizing the book's contents. There are cross-links between chapters and topics which help to find solutions to problems. Each topic has uniform structure consisting of subtopics, questions, results, contraindications, alternatives and further reading which helps a lot in finding answers and making decisions during an agile project. I was astonished how much information can be packed on only 400 pages. That is amazing.

Parts I and II of this book contain author's approach to XP. Part I helps to get started with eXtreme Programming and Part II provides detailed guidance for each of XP's practices. Part III is full of ideas that can help to understand XP and agile development more deeply.

I have read this book because I had heard that it is worth reading. I work as a software architect and project manager and I found this book very valuable. It is especially useful for anyone who is, will be or wants to be part of an agile team. This also includes programmers, domain experts, testers, project and product managers, designers and business analysts. It may also be handy for aware customers. If you have anything in common with agile development you should read this book.



So-so... but wait...,  January 13 2009
Submitted by joshSVUG   [Respond | View]

Vigneron mentions at the top of his review: "Good for those transitioning from a conventional process to agile methods." which is absolutely right.

In this context, I think the book deserves "more stars" :) especially because it brings real-world examples and points out when Agile Development (XP in particular here) won’t work for you and your organization.



A treasure. How to apply Agile Development to a real project,  November 19 2008
Submitted by Roger Spooner   [Respond | View]

This book is a treasure. Not only does it explain Agile Development clearly and entertainingly, but it is thoroughly grounded in how it pans out in real organisations. It also covers several business and software engineering issues which I didn't expect, such as unit testing techniques and process improvement.

It is aimed at people who want to start using Extreme Programming on their software development projects. It seems that XP is almost, but not
quite, synonymous with Agile Development. For each of its principles, we learn the concept, what the outcome should be, how it might go wrong, and where to read more. Sometimes there is a short FAQ section. If your existing organisation can't incorporate this principle; sometimes you can make up for it in other ways, or sometimes you can follow the principle while still satisfying your bosses.

The book starts with the thoughtful principles of XP, such as pair programming (continuous review and better design through discussion), energised work (sleep well, be motivated, and focus when in the office), an informative workspace (sharing progress with the team), root cause analysis (ask "why" 5 times, to get to a more substantial answer), retrospectives. The book goes on to collaborating: sit together, real customer involvement, and more. The next part is releasing: continuous integration, weekly iterations, all the follow-on tasks like integration done. Planning includes product vision, release planning, iterations (development cycles), risk, stories (tasks), and estimating. Finally, the principles of development include incremental requirements, test-driven development, refactoring, and simplicity.

The book is designed either to be dipped into, having cross references and a target audience for each section, or to be read cover to cover. It's really all about how to apply Agile Development within a real project. What should you do if some people don't want to join in? How large or small can a team be? What information do you share with stakeholders outside the team itself? Can you manage without a particular principle?

Despite having started with a tone that didn't capture my enthusiasm immediately, the body of the book is engagingly and genuinely plausible. The authors have worked in real companies on real projects, and know how to get Agile to work. Personally however, I tend to feel that Agile development works better with trustworthy, skilled and flexible staff, than with "entry-level" skills. If people don't have the confidence to go from designing to testing to developing to releasing all within the same day, then I think they may find this more challenging than working to a specification.

One of the ideas new to me is the "retrospective". This is a regular meeting, perhaps once after each iteration which should ideally be weekly. The team discusses what went well, and what didn't, then chooses a single topic to improve for the next time. This bright approach to process improvement is in contrast to the procedures, audits and cheeseburger outcomes of some quality management philosophies. The book also explores testing in more detail.

The final section explores ways to improve your results with XP even beyond the textbook methods. Many of the ideas are hinted at throughout the main text, so this might be seen as a kind of conclusion to wrap up the volume.

The whole book is a pleasure to read. Without being jokey, it is fun and informative. It is well printed and laid out with extensive cross references and some summary boxes or quotations. The references to other books make it very well linked within its area of software engineering. Without doubt, the greatest strength of this book is the integrity and experience that shines through the wise responses to real world challenges posed by traditional organisations.


Very good book!,  October 15 2008
Submitted by Vlad GURDIGA   [Respond | View]

I've just finished reading it and I feel almost prepared to get the agile way. Thanks a lot!


So-so,  September 15 2008
Submitted by Vigneron   [Respond | View]

Good for those transitioning from a conventional process to agile methods. Not good for those whose organization already use an existing method that is not XP. Also had a difficult time getting past the use of feminine pronouns for the neuter case. The authors should read Strunk and White's Elements of Style before writing their next book.


Agile for the Real World,  August 02 2008
Submitted by Michał Kosmulski   [Respond | View]

One of this book's main strengths is how it concentrates on "real world" situations. Extreme Programming (XP), which is used throughout the text to illustrate main ideas of Agile Development, sometimes requires (or at least encourages) really extreme changes relative to what many companies do. The authors are aware of this and for each recommended practice they show how it can be introduced into an already existing non-Agile environment or how it can be replaced with something different if that is more appropriate in some particular situation. They also show that being Agile is actually not about following some fixed set of rules, but rather about going for the Agile philosophy, which may mean bending or breaking the rules if that's what leads to better results. Even if you are not going to directly use XP in your project, this book is definitely a worthwhile read.


Great Book!,  March 24 2008
Submitted by Brendon Anderson   [Respond | View]

This book is very well written and gives a great description of many different types of Agile practices. Although the book centers around XP, I think many of the techniques and practices could be brought over to any of the different Agile disciplines. The book also goes into the all important steps of selling agile practices to those with the money: managers, directors, stake holders, and the customers. This is a very important step! The book is also nice in that it doesn’t necessarily have to be read in chapter order. If you need some help on something, it’s easy to pick up the details by just going straight to that section – no need to read everything before it to get caught up. All the information in the book can be applied directly. Many of the concerns related to starting up Agile development in a shop are covered very well.



Agile and XP Grow Up,  December 21 2007
Submitted by Rob Myers   [Respond | View]

This book is very well-timed. Now that agile development practices are "crossing the chasm" towards professionally accepted standards, this book reminds us that "agile" is neither a narrow, prescriptive set of standardized practices, nor a free-for-all smorgasbord of every possible practice.

This book will give teams and their management the information necessary to make informed decisions about the make-up of a software product team, and how it operates. The Art of Agile Development is intelligent, thoughtful, professional, and realistic. It is based on years of varied experiences, and it reveals a well-tested set of recommendations.

Part I

The book starts out with high-altitude answers to "Why?" and "How?" and a satisfying definition of "success." This is followed by a story of a hypothetical XP team. The story is full of dialog revealing the day-to-day functioning of a well-running team as a new hire joins the team. That dialog may seem contrived, but it's likely more of a composite of things heard on various teams. Yes, agile teams do enjoy their work, and people who enjoy their work talk about it as portrayed. I think this portrayal brings forth an important decision for the reader: Do you suspect that your development teams could truly run more smoothly, or are you merely looking for a way to dismiss this weird new "agile movement" and get on with your agonizing career? (Either way, keep reading!)

Part II

The second section of the book is a detailed exploration of the development practices recommended by the authors. There are a number of practices recognizable from XP, with some additional thoughtful practices, some realistic alterations, and some notable replacements. As I said, this is neither a full buffet, nor is it a restrictive diet. This is a menu prepared by two experienced chefs. They talk about contraindications and alternatives for each practice, but they also warn of the pitfalls of removing key ingredients.

Each chapter, or practice, comes with embedded boxes highlighting important points, and "allies," which are the names of other related (and supporting) practices and their page numbers. These allies appear in little grey boxes in the margins. They give you the ability to use the book as a reference, but they also paint an important picture of how the practices fit together.

I have to give special credit to the authors for the chapter they call simply "Trust." Under "alternatives" they state rather clearly that there are none. No replacement for trust! It seems so obvious, and yet teams struggle every day because they don't have it. The authors, thankfully, provide suggestions for establishing lasting trust.

Another noteworthy chapter is "No Bugs." If you're standing in the bookstore trying to decide whether or not to buy the book, turn to this chapter. These practices bring numerous others into focus. Again, if you're thinking "pipe dream," keep reading. If you follow this menu conscientiously and rigorously, you will arrive at the sweet dessert of extremely high-quality code.

Part III

Have you ever had a delicious meal at a friend's house, obtained the recipe, tried it for yourself, and thought "Oh, that didn't turn out well!" What can you do?

It takes experience (and that means real time in the kitchen) before you can comfortably tweak a chef's recipe. You can also go back to your experienced friend and ask for advice or clarification. This book provides the same opportunity. Read Parts I and II, go try it for a while, then come back to Part III.

This section describes the underlying values and principles behind the agile practices, and will help your new process and your team's existing culture work together towards greater and greater success. If a lot of the chapter titles in this section sound like Lean product-development principles, well, I think that's intentional.

It is perhaps difficult to pinpoint what is truly "agile." This book represents true agility without claiming to fully define it, and I hope it helps others on real software projects navigate a successful jump across the chasm.

This is mature, no-nonsense agility, in book form!

See larger cover

On the Art of Agile Development