The Art of Agile Development [Paperback]

After reading a couple of books on Agile, The Art of Agile Development does the best job of presenting all the ideas and concepts needed to start putting it all into practice. Previously I've been left with questions about how to go about implementing certain ideas or mis-understood key concepts, I felt able enough to start putting a lot of Agile and XP concepts into practice straight away.

The material itself is very digestable and written in a great down to earth manner. Rather then being a case of teacher lecturing to their student, it felt a lot like someone who's been there and gone through all the pains before hand, had come round to visit one afternoon to tell you what they had learnt and what they believe works best.

I've recommended this book to nearly all my development friends and work colleagues/bosses in different departments and even offered to buy the skeptical one their own copy.

I received this book then skimmed the authors biographies to see if they are web 2.0 hippies. My experience with the agile method is that is used to excuse sloppy work practises or when a developer wants to avoid boring stuff like documentation, requirements gathering, project planning or testing. I rank it along side similar claims such as graphic designers cannot arrive at work on-time and sober because artistic inspiration only strikes early in the morning in night clubs while talking to beautiful people. In short I don't understand it and it is what the cool people do.

My objectives of reading this book were to

Understand what agile Development really is.
Assess whether adopting agile methods will be of benefit to our team.

This book helped me partially achieve both of them quite easily so I recommend it.

My major reservation is that I'd appreciate more support for the book via a web site. James Shore has a good site but http://jamesshore.com/Agile-Book/
is the only page I could find about the book.

There was a checklist to determine how Agile are the work processes are that I use at the moment. I'd like this to be provided on a website and to be interactive.
The provision of more code examples and templates would be also useful.

The art of agile development does not evangelise or attempt to hard sell Agile. The case studies given seem contrived but are used by the authors give a warts and all account of Agile development. On finishing reading this book I feel I am much more aware of the potential benefits and risks of this approach but not confident it's the right way to go.

This book plays the role of an honest consultant rather then a salesman. James Shore and Shane Warden are skilful writers and have covered a technical subject with élan. If you are anyway involved in software production and considering Agile, then buy it.

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.