The Art of Agile Development contains practical, down-to-earth guidance for anyone involved in or considering the agile method—and Extreme Programming in particular—to build reliable software. Agile development methods have become increasingly popular because too many software projects have failed to meet expected release dates, deliver the required features, or to match projected costs. This book provides no-nonsense advice on agile planning, development, delivery, and management taken from the authors' many years of experience.
Review By: Tim Dugan 06/23/2010The Art of Agile Development by James Shore and Shane Warden is the most definitive description of Agile development that I have seen. It is ultimately very readable and very detailed. It's quite obvious that the authors put a lot of experience and research into developing this practical guide to agile development.
The book is organized into three major sections, "Getting Started," "Practicing XP," and "Mastering Agility." Each section builds successively on the previous to give the reader deeper understanding. The first two sections are useful to those just wishing to adopt some agile practices. The final sections is oriented toward fine tuning an organization that has lept fully onto the agile bandwagon.
For those familiar with previous publications on XP [Extreme Programming Explained, Beck] and Scrum [Agile Software Development with SCRUM, Schwaber & Beedle], the authors provide an interesting table mapping between the ideas and practices in those books and this one. This is a particularly good mechanism for demonstrating the completeness of this treatise.
And quite complete it is.
You will find information about XP practices, such as pair programming, informative workspace, stand-up meetings (i.e., Scrum meetings), "done-done," and so on. For the more seasoned team, there are descriptions on how to eliminate waste, deliver more value, and improve your processes.
For those not familiar with agile, it is worthwhile to start with the Agile Manifesto, extracted from the text in the form of these four value statements:
1. Value individuals and interactions over processes and tools.
2. Value working software over comprehensive documentation.
3. Value customer collaboration over contract negotiation.
4. Value responding to change over following a plan.
In conjunction with these values is a set of agile principles, too long to list here, but the first is "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (I'll leave it to the reader to learn the remaining nine in the text.) Most every practice described in the text derives in some degree from these values and principles. As such, the text is principle-centered and focused to a particular end: good software development through agile development.
I liked a lot of the things I read in this book, and, as such, it's hard to pick a particularly good example. But one section that I just re-read is the one on "Trust". It suggests various strategies for building team trust. One example, "A good way to improve team cohesiveness is to eat together"—if employers are willing to foot the bill once a week to feed their team, they are likely to reap some benefits by developing a team with a higher level of trust.
Given all this praise, I have to admit, I am not whole-heartedly convinced of every aspect of agile as described in this text. Case in point: how to conduct retrospectives. This may be a little nit-picky, but activities like "mute mapping" tend to be dominated by certain personality types and, as such, not very democratic. And the practice of letting people have five votes to choose from the topics derived from the mute mapping seems to go against any fair scheme of voting I've seen…better would be to ask people to rank the catories or at least a top five.
Even though I see a lot of value in pair programming, I also have doubts about doing it all the time—as some coding tasks are so mundane and ghastly dull that to occupy two peoples' time with this code seems more like punishment than anything else. There has to be some acceptance that different personality types can handle differing levels of paired activities, and that certain types people probably cannot pair well with other types.
All in all, though, I have to say that this is an exceptional book and I recommend it to anyone who wants to be a modern developer of quality software.
Review By: Janet Kennedy 06/23/2010"The Art of Agile Development" can be used by people who have never been previously exposed to XP or Agile methodologies, and it can be used as a reference for those who wish to refresh themselves on a particular aspect of the methodology. This book is ostensibly about Agile Development and, specifically, second generation Xtreme Programming (XP), yet it incorporates best team practices that can be applied to more than just software development. One of the key concepts of Agile/XP is that the players (customers, developers, testers) need to be physically located together and that they must work as a team with a common purpose instead of as adversaries, which, while not usually stated, is the way many product development groups behave. Anyone who is part of such a divided team should read this book.
This book offers both specific and conceptual ideas for delivering useful software applications. The concepts are not revolutionary but they are presented with facts and examples that explain how to do something, why it is important to do it that way, and what the consequences of not doing it that way may be. It always offers alternatives if your situation does not allow the ideal process to be followed. Simple examples include keeping build time as short as possible so that frequent builds can be released with workable code every few hours which allows required changes to be highlighted more readily.
The design of the book is excellent with clear fonts, succinct headings, and chapter footings that make it easy to find the section you are looking for. Part one of the book, "Getting Started," gives background information and helps the reader determine if this is really the methodology they want to use. Part two, "Practicing XP," is the core of the book. Part three, "Mastering Agility," summarizes the material with another three-part organization: Principle, In Practice, and Beyond the Practice.
The writing style is readable and progresses logically. I particularly like the sidebars for "Audience" and "Ally." Audience tells you whom the section is addressing and Ally is a quick cross-reference to other techniques that can supplement and support the section you are currently reading. For developers there are specific coding examples. For the whole team, there are specific examples of how to organize the work area, including how and when to offer measures and reports. For project managers there are specific examples of the reports to produce for management and recommendations on how to keep management informed so that they will let the team get on with the work. As Brian Marick said of this book, I, too, "will leave a copy of this book with every team I visit."