Terms and Conditions:

James Shore wrote:This is a copyrighted material. You're welcome to make a single printout for your personal use, but you may not republish this material in any way.

Book Summary:

This book helps reader mastering the art of agile development.

Agile development, like any approach to team-based software development, is a fundamentally human art, one subject to the vagaries of individuals and their interactions. To master agile development, one must learn to evaluate myriad possibilities, moment to moment, and intuitively pick the best of course of action.

How to possibly learn such a difficult skill? Practice.

Most of this book is an étude. An étude is a piece of music that's also a teaching tool. Études help the artist learns difficult technical skills. The best études are also musically beautiful.

Agile étude in this book serves two purposes. First and foremost, it's a detailed description of one way to practice agile development. It's a practical guide that, if followed mindfully, will allow reader to successfully bring agile development to a software development team - or help to decide that it isn't a good choice in the team's situation in the first place.

The second purpose is to help reader mastering the art of agile development. Team software development is too nuanced for any book to teach how to master it. Mastery comes from within: from experience and an intuitive understanding of ripples caused by the pebble of a choice.

At first, it's a struggle to understand how to do each practice. They will look easy on paper, but putting each practice into action will sometimes be difficult. The more practice the easier it will be.

As it gets easier, some of the rules will be discovered as unworkable. In the beginning, it's not easy to tell if the problem is in the rules or in the way the team is following them. More practice will make it easier to decide which rules to follow and which ones to break.

When the team is ready to break the rules, turn to Part III. A word of warning: there is nothing in Part III that will help reader practice agile development. Instead, it's full of ideas that will help reader break rules.

Intended Audience:

This book provides practical applications for the whole software development team, including project managers, leaders, coaches, programmers, designers, architects, product managers, business analysts, domain experts, interaction designers, testers and quality assurance.

This book should also be useful even for those who doesn't want to learn the so-called art of agile development, those who just want to develop good software. Parts I and II are exactly what they need. This book took years of experience with agile development and distilled them into a single, clearly defined, approach to agile development. This allowed the book to use plain, straightforward language without caveats or digressions. This book includes a lot of practical tips. It describes when the approach won't work and what alternatives to consider when it doesn't.

Further Reading(s):

• How To Build An App Using Agile Development, at fueled.com.