Customer Reviews

The Art of Agile Development

5 star:		(31)
4 star:		(5)
3 star:		(2)
2 star:		(0)
1 star:		(2)

 

 

The Art of Agile Development is one of my best purchases in a long time. I've read a lot of Extreme Programming and Agile Software Development books and this one really nails it. Many are too theoretical, vague, or just plain developer-centric. This book however is of real practical value to everyone in the team: customers/business analysts, testers, and developers alike.

The book builds around 37 agile development practices in five categories: Thinking, Collaborating, Releasing, Planning, and Developing. Respective examples of practices are: Energized Work, Ubiquitous Language, No Bugs, Vision, and Incremental Design & Architecture. It's obvious that the authors are experienced practitioners as the text is littered with symptoms of common problems and remedial advice. Each practice has a clear explanation, answers to common questions, results you should expect to see, and when to and when not to adopt the practice given your current environment.

As a developer I'm finding this book invaluable. It's helped me think and communicate far more succinctly and effectively - even for material I was intimately familiar with. It's also a book that's accessible to everyone in and outside the team. In short, this is a great book.

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!

I've been working through this book for the last five or six weeks and have been loving it. Usually I do a deep skim read of most books -- the kind of reading you do in college where you need to get the gist of a book and some of the pearls -- but this one's grabbed me into an intense period of reading, reflecting, and re-reading parts.

Warden and Shore have written a fantastic work here. The book covers all aspects of Agile from planning to delivery, and each aspect is broken down into sensible sections. It reads like a series of great articles on very granular components of Agile such as Refactoring, 10-Minute Build, or Stand Up Meetings, but it's so well-written that all the articles mesh together perfectly leaving a smooth path through the book.

Each article (and that's my description, not theirs) lays out a specific practice or component of Agile, walks you through the benefits of it, details how that practice fits in the larger picture, shows you how to implement that practice, and discusses how to identify when you might need to implement or rework the practice. Each article is extremely well done and approaches its topic from a very pragmatic view. There are also cross-references to other practices elsewhere in the book that can help you solve related issues. Additionally, there are great references to other books, articles, and web posts.

Overall the book's just terrific. It's easy to read, it's pragmatic and practical, and it's thought-provoking. Art of Agile Development can be used by newcomers interested in moving into Agile practices, but it's also absolutely applicable to Agile pros looking to improve their own system. It certainly got me fired up with a number of ideas on how to improve our process even more. Perhaps that's the best endorsement of this book.

I just can't stand reading this book. Being an SCM manager I am familiar with the good ideas and the problems of agile development. I am also familiar with the managers who like to use catch phrases to motivate and fix every issue with development.

This book is great training if you want to just spit out a bunch of buzzwords in agile programming but not really understand them. The first 200 pages of the book are literally a maelstrom of agile "buzzwords" broken up into recommendations of XP (extreme programming).

One thing that is repeated for every single XP practice is the following "THIS_PRACTICE is a prerequisite for agile (or XP) but if you can not THIS_PRACTICE you can still be effective... and here are alternatives... contraindications.." Ok, first off, if you have an idea or set of practices to improve programming, stick to you guns. With all the alternatives and wishy washy commitment in the writing of this book, I would conclude that the idea of XP is not that good in the first place.

The structure of the book is painfully chopped up into small pieces and the exact same concepts, practices and advice are repeated over, and over, and over!!!! Its maddening. Each chapter is also padded with all of the "if you can't do this..." sub-chapters which like most of the book just repeats the same conceits. There are many good points in the book but its simply not interesting to read. It reads more like a huge power point presentation. Touching on hundreds of ideas and highlighting them. The treatement of each individual practice is simply too shallow to be thought provoking or entertaining in any way. I know programming practice is not sexy but it can certainly be engaging.

The best parts of this book are short anecdotes about the anthers experience and nods to other, much better reading material like "The Mythical Man-Month". I admit I could not suffer the entire book but I did read some of the later chapters and the writing style is just as fractured and annoying as 10 or so chapters I did read. The authors do appear to have a good understanding of agile practice but they are not that familiar with writing a well structured book.

My advice would be to look at other books on the subject of programming and managing software projects. This will give you a good background. This book is just a primer on XP and a poorly written one at that.

I highly recommend this book for anyone who wants to try to install agile development process in your organization.

Installing agile development is more than installing a set of coding practices in your team, you have to take care of the product managers, the stake holders, the testers, the end users, etc., in order for your effort to go through. This book has covered those topics very well, which is extremely rare among agile development books. I know that because several times I was able to refer to the chapters in this book as references and was able to answer questions the best way that I could by myself.

If you know how difficult it is to install agile development process sometimes, or are already in such a situation, then you should definitely grab a copy. You can just flip through the chapters and find the ones that interests you, and you will like it right away.

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.

In my opinion, this is the best book for someone starting to implement XP. Before this book, other two books on XP practice were "XP applied" and "XP installed".
Book by James Shore and Shane Warden provides more broad coverage, then previous books, and contains a lot of good advice, what to do, what not do, and how to do what should be done, while going to the path of Agility.

Presentation is based on the XP, but book also shows a more wide perspective, and contains comparison with SCRUM

What I really like in the book
- Pragmatic approach to XP - In this book, you will not see approach XP as a holy grail - do it either this way, or you are wrong. Instead, authors expand the original definition of the XP from XP Explained by the practices, which they found to work well in real world
- Its practical focus - It contains a lot of the practical tips (for example, how to implement continuous integration successfully, how to do test-driven development, what is the real meaning of the user stories etc..)
- Balanced presentation - for each practice there is Q&A section, contraindications and alternative practices.
- Live style - book is written in clear and engaging language

Quality of book is very high, and I would recommend it to my friends as a best book to read on working in agile/XP style

We began using scrum and have had significant success with it alone. Doing additional research we've found that eXtreme Programming (XP) would complement our efforts and improve our development practices. I picked up this book and started reading it the first moment I had it in my hands, since then I've not been able to put it down.
The reading is engrossing, empowering and exciting. This is one of the best technical books I've ever read.
This book and others have convinced me that the agile methodologies are the only way to develop software and the future will only bring enhancements to both Scrum and XP.
I strongly recommend this as required reading for anyone that develops software for a living in any environment. I also recommend this book to anyone involved in software development from the business perspective as it describes how agile practices benefit and bring value to businesses and helps understand how software development does not have to be and obscure trait that cannot be measured, controlled or be consistent.
The structure the author has chosen for the book is very useful and practical. It starts with a detailed explanation of the subject and gives excellent examples where appropriate; it then goes through a FAQ sections answering common questions about the described subject; it also includes situations to avoid and problems that could be applicable.
XP practices rely on each other in subtle ways and the author does a wonderful job of relating each one as the reading progresses through the use of small "ally" boxes on the outer sides of the pages.

I could go on for a while longer, but the conclusion would be the same:
Buy the book, read it, use it to implement agile practices and return to it frequently.

I bought this book after I saw James Shore speak at a local Agile conference. The book is a great reference for anybody who wants to start using Agile principles within their group. It includes sections where you can refute objections and it backs the principles up with studies and data. Overall, I think this is a great book with which to start your Agile journey.

First, the complaints. This book should have been titled, "The Art of Agile Development with XP." It is not a book about Agile development in general, but rather an overview of extreme programming practices. Also, the authors generally take an all-or-nothing approach to XP. There is little (one page, to be exact) on implementing XP partially or gradually. I understand that XP's practices are largely mutually supporting, but considering that their philosophy is to build software incrementally, I'd have thought they'd be at least sympathetic to the notion of incremental change in development methods. After all, they readily admit that XP can induce culture shock in a team or individual new to XP.

That said, the book gives a thorough description of each XP practice (37, in all) including situations in which a given practice may not be appropriate and possible alternatives, if any. Each section includes a list of books or articles referenced, or which expand on the topics presented. These are really helpful in knowing where to turn next or just building a "future reading" list.

I haven't read any of Part III yet. I'm saving it for after I've had a chance to try out some of the techniques in the book.

Despite some flaws, the book still earns 4-stars.