As we have extended adaptive practices beyond our initial "skunkworks" group into the larger IT organization at our company, people have been asking about books that can help them get up to speed on concepts, practices, and tools. They're finding hundreds and hundreds of books that purport to teach the reader about adaptive or Agile practices. Not all these books are equally useful. Worse yet, some books are based on a faulty understanding of adaptive development, and encourage predictive methods while making a show of using terminology that has become popularized due to the Agile movement. Here are a few general guidelines for choosing books:
It's a basic principle of the Agile approach to question everything, so let's begin by questioning the question, "Which book should I buy?" There's no simpler solution to any problem than to redefine it away. The simplest solution to the problem of choosing books is to redefine the question. What are you really looking for, a book or information?
Most likely, you're looking for information. Everything you ever wanted to know about adaptive software development is available online, free for the clicking. Start by reading websites, blogs, and discussion boards. As you gain basic knowledge of adaptive principles, you will accumulate enough information to judge the merit of books - if you still want them.
Besides that, conventional wisdom in the Agile community is that the best way to learn adaptive practices is to work on an adaptive software development project. Through IPMs, pairing, stand-ups, writing tests first, participating in brainstorming sessions, and all the rest of it, you will quickly internalize concepts, methods, and best practices. No book can teach you these things as effectively as hands-on experience on a real project, guided by Agile practitioners.
If you still want a book after all that, then maybe the following tips will help you sift through the mountain of available titles.
If you are looking for books about adaptive development, it's a pretty safe assumption that you're already a practicing software professional. You already know a lot, and you only need to learn about a few unfamiliar ideas. Use what you already know to make judgments about the claims made about a book by its author, publisher, and reviewers.
Example: The book, Prefactoring, by Ken Pugh, purports to offer an improved way to approach refactoring on development projects. However, the publisher's description of the book raises questions. It reads, in part, "More often than not, developers will stop a large project in the middle of the build stage to rethink and recode the software design so it's cleaner and more efficient. Known as 'refactoring,' this process eats up valuable time and money. To help offset refactoring, this book presents a new process called "prefactoring," the premise of which states that you're better off considering the best possible design patterns before you even begin your project."
If you know a little about refactoring and adaptive development already, then this statement should raise a red flag. It sounds as if the author does not properly understand how, when, and why refactoring is used in an adaptive software devleopment process. No one "stops" to refactor; refactoring is a routine, everyday practice. We don't need to "offset" refactoring, we need to use it aggressively throughout the development process to improve code quality and deliver high value to customers. The term, "build stage," implies process-oriented thinking and a "waterfall" mindset. It sounds as if the book is suggesting a predictive approach to software design: Determine the design in advance and then don't "stop" to refactor anymore. That is not adaptive development.
It's normal in an adaptive project for the team to brainstorm the initial architecture and design of the solution; this is, for all practical purposes, "prefactoring." It's already part and parcel of adaptive development, and does not represent any sort of breakthrough thinking. Based on a little knowledge of adaptive development, you can quickly dismiss this book and continue your search.
Online booksellers like Amazon usually present one or more reviews by readers, to help customers judge which books they would like to buy. Read all the reviews carefully.
Example: Kent Beck's book, Test-Driven Development By Example sounds like a winner. The author is one of the thought leaders of the Agile movement, an accomplished practitioner, a respected author and speaker, and an active participant in the Agile community. The title makes it sound as if the book will provide a practical, no-nonsense, step-by-step guide to TDD; a practical guidebook written by someone who knows what he is talking about. All good, right? Not so fast!
The review by R. Williams gives one pause. He liked the first part of the book, in which Beck works through an example step by step. However, "[a]t the end of it, there's a great moment when Beck acknowledges the importance of metaphor, claiming that he'd done the same exercise a number of times, though this time, he had picked a better metaphor and it subsequently went a lot faster. I have to laugh at this. This is a case of obiter dicta (giving away the key to something in passing). But the funny thing is that Beck doesn't notice how important it is. He proceeds to just meander through the rest of the book. Then, the book just goes down the rathole...The section on patterns is abominable...his snide little sideswipes throughout this book on everything from the open-closed principle to the idea of doing specifications...are really laughable."
Ultimately, the book sounds like a waste of trees. Beck's opinions are already available on his website and on any number of discussion forums. No need to spend money for opinions and "snide little sideswipes" when what we really want is a practical reference.
You may find conflicting opinions among the reviewers. Ask yourself why they conflict. If the reviewer's background is similar to your own, then you will probably like the same books. If the reviewer's background is different from your own, then he/she may have different needs than you have.
Example: Consider Amazon's presentation of the book, Refactoring to Patterns, by Joshua Karievsky. Reviews by wiredweird and Michael Cohn give the book high praise. Several other reviews take the general position that the book is just what they have been looking for, but it does not provide sufficiently detailed code examples. They want complete before and after code, and "not just snippets."
This tells you something about their technical background and experience. The first two reviewers are obviously very comfortable with the concepts and can easily relate "snippets" to real-world code. The latter reviewers are obviously somewhat less experienced, and need complete examples to understand what is really being done when the code is refactored. You should match your own experience to that of the reviewers (to the extent that is possible just from reading their comments) and choose a book that is recommended by people whose background is similar to your own. This book seems to be geared toward people who already practice refactoring and already think about code in terms of patterns. If that describes you, then the book sounds like a winner. If you need more hand-holding just now, then keep searching for an appropriate book.
Typically, a few people get involved with reviewing books and posting their comments on booksellers' websites. Read their profiles and as many of their reviews as you can. When you buy a book they have recommended, use your personal assessment of the book as a way of judging the usefulness of the reviewer's opinion for your purposes. If you both found a book useful, then it's likely you will appreciate other books recommended by the same reviewer. If you found a book disappointing, then it's likely that reviewer's opinions will not serve you as a guide to future purchases (although they might serve another reader quite well).
Example: I agreed with Michael Cohn's opinion of the book, Refactoring to Patterns, and noticed that he also recommends eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility, by Douglas DeCarlo. I bought it based on that recommendation, and was not disappointed.