Based on evidence gathered from successful small software development teams, Alistair's Crystal Clear describes an Agile methodology framework with great tolerance for a broad set of practices. Highly recommended for anyone who wants to know how small teams can *deliver* software rapidly, frequently, and successfully.

Sadly I think it is a bit outdated. Agile methods are so new (relatively) that a book a few years old can be dated already. :(

This is a book about the idea, that there should not be a methodology for a company - but a methodology for a project!
Depending on the project size and criticality, you should tailor the process that suits exactly that project. Of course, this isn't true on small projects but any project involving more than 10 developers and taking more than - say - 6 months to build, deserves a fit-for-the purpose methodology.

This book will give you ideas for that. Actually 'Clear' in the name means that the process is for small teams, so this book tries to give a some kind of sugegstions for one purpose, but all the time keeping in mind that you'll have to make the methodology to work for your project not the othe rway round.

Read Chapter 9 - if nothing else.

Recommended to me by a former manager and I'm glad I read it. Common sense approach to running individual development teams that doesn't lean on any methodology apart from how people work. I found myself constantly saying outloud, whilst reading the book, "yes, yes ... exactly that makes sense!".
I could and will read this book many times.

Some aspects of this book were totally awesome. I love the basic methodology, the focus on communications, personal safety, reflection workshops, importance of keeping methods lightweight, etc. Unfortunately, the book suffers from a bit too much of trying to be something for everybody. Huge swaths of material were skimmable at best for me. For instance, examples of requirements documents and design diagrams. I've seen thousands of such examples and seeing new ones in this context provides nothing for me. Another example: reports relating to ISO certification. Another example: encyclopaedic categorization of all the possible work products, indexed by which team member role is supposed to produce them.

One more thing that I find perplexing about this book. The author shows a strong bias against using software tools to manage requirements documents and other work products, manage iterations, etc. I would be a full-on advocate of, for example, using a wiki. It's a searchable storage device on top of being a collaborative documentation tool. I'm constantly going back to old wiki pages and work tickets to look into the details of what was done. This is going to be a royal pain if the only documentation we have are cell phone pictures of what we once drew up on a whiteboard.

My first Agile book, this was a good introduction to the Agile concepts. It drags a little (as technical books do) but the illustrations of the value of Agile are clear and understandable.

decent methodology, but it always comes down to theory vs. practice, doesn't it!?

If selly says so...

Lot's of good ideas, simple and fast to read, goes directly to the point.

7 Properties:
1. Frequenty Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. Technical environment with automated tests, configuration management, and frequent integration.