Review By: Jan A. Scott
06/01/2008Have you wondered about the different agile development methodologies? Have you thought that they sounded fine for a small project at a small company but couldn't possibly fit into a large, corporate environment? If so, you should read this book. Leffingwell provides a clear, easy-to-read description of the most popular agile methods, XP and SCRUM, and of less popular methods RUP, DSDM, and FDD. He describes the similarities and differences between these methods and boils down the essence of agile to the following concepts:

• Small teams of eight to ten are self-directed; management provides leadership and helps remove roadblocks from the team.
• Response to change is more important than conformance to plan.
• Requirements and design are continuous and "emerge" rather than being done as a single effort up front.
• Coding and testing are done iteratively. There is no big, planned system test at the end.
• Code is delivered to production in small chunks, and working code is valued over documentation.
• Each release is time-boxed. The time can't be changed; only the scope can change.

The second section of the book describes seven agile practices that scale and how to scale them. The define-build-test component team is a small agile team, but on a large project there are many of these teams linked into "teams of teams." The book describes how to apply agile practices to manage even remote teams. Iterations of code are considered internal releases and are combined to form an external release. Planning is done around these iterations and releases. The book describes how a company's cycle of releases can shorten but still be driven by marketing requirements. In traditional agile methods, architecture evolves with the code, but this book describes how to implement an "on-purpose" architecture that is required for a large project.

Lastly, Leffingwell describes the organizational changes that need to occur to support agile. These are not trivial, but he leaves the reader with an optimistic sense that this change can happen. Most importantly, management must trust the team and give up a command-and-control mentality to the belief that empowered people will self-organize and do the right thing. Implementation of a full, agile development methodology will require top-down management support. However, if you are a project manager (as I am), there will be take-aways for you in this book. On your next project, try: an iterative approach; pairing developers and testers early; and leading your team in an agile way. This book will provide you with tips to affect small changes in your organization to become, if not agile, at least a little more graceful.